C++ Gurus
-
Ich verstehe auch nicht, warum das in C++ so fehl am Platz sein sollte. Man siehe übrigens auch das von HumeSikkins vorgeschlagene foreach:
short array_short[] = {1,2,3}; BOOST_FOREACH( short & i, array_short ) { ++i; } // array_short contains {2,3,4} here
Es ist schließlich keineswegs so, dass man jede for-Schleife durch ein foreach ersetzen können muss. for ist ja gar nicht böse. foreach soll ja ein Spezialfall von for sein und damit auch einen kleineren Anwendungsbereich haben. Natürlich kann es jeder so für sich implementieren wie er will. Der Trend scheint aber in die Richtung zu gehen, den Iterator zu verbergen (auch wenn beim BOOST_FOREACH wohl generell eine Änderung _des Inhalts_ des Containers möglich ist).
-
Ich verstehe auch nicht, warum das in C++ so fehl am Platz sein sollte.
Weil die Sprache uA auch davon lebt keine Einschränkungen zu haben - steht aber bereits in 4 anderen Postings hier
MfG SideWinder
-
Jester schrieb:
Täusche ich mich, oder läßt std::for_each den Container auch unverändert?
for_each geht auf eine range und nicht auf einen container - die idee hier ist wohl eher ein apply statt einem for_each.
Natuerlich kann man aus bequemlichkeit ein foreach mit dereferenziertem iterator anbieten, habe ich bereits gesagt, dass eine referenz nicht weh tut, aber generell _verbieten_ iteratoren zu verwenden spricht nunmal gegen das C++ prinzip. Da kann Java noch so bunt sein.
-
SideWinder schrieb:
HumeSikkins schrieb:
Wer braucht sprechende Namen, wenn wir einfach durchnummerieren können.
Was spricht gegen:
enum MyTestSuite { Test_TuDas, Test_TuDies, Test_TuJenes }; template<> template<> void object::test<MyTestSuite::Test_TuDas>()
Ästhetik und vorallem die menschliche Faulheit (ein Methodennamen muss ich vergeben, aber niemand zwingt mich dazu eine neue Konstante anzulegen statt einfach test<42> zu schreiben).
Natürlich ist eine symbolische Konstante besser als eine Zahl, aber du willst mir doch nicht erzählen, das du diesen HACK wirklich schön findest. Und es gibt imo einen unterschied zwischen "geht" und "ist schön".Ein Unit-Test sollte schnell zu schreiben, leicht zu lesen und überhaupt eine leichtgewichtige Schönheit sein. Ansonsten wird er schlicht nicht geschrieben.
Der einzige Vorteil von TuT gegenüber z.B. CPPUnit ist der, dass man seine Tests nicht registrieren muss. Verwendest du jetzt die Aufzählung oder einen Kommentar oder sonstwas (würde ich auch machen, da eine Zahl als Name völlig indiskutabel ist), dann ist dieser Vorteil verloren. Es macht nämlich keinen Unterschied ob du jedesmal eine neue Konstante in deine Aufzählung schreiben musst oder ob die für jede neue Methode ein
CPPUNIT_TEST(testMethode);
in deine Test-Registrierungs-Map einfügst.
Du hast also letztlich den selben Aufwand, dafür aber eine hässlichere Syntax (jedesmal template <> template<>), weniger Portabilität und weniger Features.Der einzige Vorteil: Du hast voll-geil-Templates benutzt und kannst damit jetzt voll die Bräute beeindrucken
-
kann man zum doppelten template<> irgendwas im internet finden?
-
HumeSikkins schrieb:
Ein Unit-Test sollte schnell zu schreiben, leicht zu lesen und überhaupt eine leichtgewichtige Schönheit sein. Ansonsten wird er schlicht nicht geschrieben.
Kannst du mal dein schönes Framework zeigen?
Ich suche schon ewig nach etwas vernünftigen.Meine Ansätze sind allen an der einfachheit der Verwendung gescheitert
Ich will:
Testdaten automatisch generieren lassen, am besten mit wenig Aufwand, diese dann Testen. Ich will aber auch statische Daten haben können (eben für bestimmte Bugs/Spezialfälle). Tests müssen automatisch ablaufen können.Ob ich einen Test registrieren muss oder nicht, ist egal - hauptsache ich kann einzelne Tests durchlaufen wann ich will. Ich will Tests auch in Gruppen einteilen, so dass ich zB alle Performance Tests laufen lassen will und ein anderes mal "endlos tests" wo einfach immer mehr Daten generiert werden und die Algos diese richtig verarbeiten müssen.
Das alles mit möglichst wenig Aufwand - zB per script oder so. Das ganze muss natürlich auf Linux und Windows laufen...
Soetwas scheint es nicht zu geben
-
Shade Of Mine schrieb:
HumeSikkins schrieb:
Ein Unit-Test sollte schnell zu schreiben, leicht zu lesen und überhaupt eine leichtgewichtige Schönheit sein. Ansonsten wird er schlicht nicht geschrieben.
Kannst du mal dein schönes Framework zeigen?
Ein wirklich schönes Unit-Test-Framework habe ich bisher auch nicht gefunden.
Shade Of Mine schrieb:
Ich will:
Testdaten automatisch generieren lassen, am besten mit wenig Aufwand, diese dann Testen. Ich will aber auch statische Daten haben können (eben für bestimmte Bugs/Spezialfälle). Tests müssen automatisch ablaufen können.Das hört sich für mich nicht mehr unbedingt nach Unit-Tests an. Zumindest nicht im TDD sinne. Dir geht es wohl mehr um Korrektheit, also QA.
Da hilft vielleicht sowas:
http://www.parasoft.com/jsp/products/home.jsp?product=CppTestFür Acceptance-Tests kenne ich nur:
http://fitnesse.org/
-
HumeSikkins schrieb:
Das hört sich für mich nicht mehr unbedingt nach Unit-Tests an. Zumindest nicht im TDD sinne. Dir geht es wohl mehr um Korrektheit, also QA.
Ich sehe zwischen den beiden auch keinen wirklichen Unterschied.
Ich will sicherstellen dass meine 'Units' funktionieren. Aber ich will ja auch sicherstellen dass die gesamte Anwendung funktioniert. Ich will also viele Tests mit vielen Daten für viele unterschiedliche Schichten haben.
Mit Parasoft C++ Test kam ich irgendwie nicht klar, ist aber schon 1 oder 2 Jahre her, dass ich die Demo getestet hatte... Werde mir sie mal wieder ansehen...