C++ Gurus



  • Optimizer schrieb:

    Was soll das heißen, man darf? Wenn volkards foreach-loop mir einen Iterator gibt, muss ich den benutzen, um den Wert zu erhalten.

    Der Sinn ist der: ein iterator ist mehr wert als ein direkter Wert, weil er Metainformationen besitzt die uU interessant sein koennen. Ein Java foreach hat das nicht. Da muss man iteratoren nehmen und die sind sicher nicht gratis wie in C++. Das finde ich schon wichtig.

    Das ist halt der Unterschied. In C++ hat man die Moeglichkeit immer iteratoren zu verwenden, ein *i ist nicht schlimm, zumal es ja -> gibt. Eine lokale Referenz zu erstellen ist ja auch kein Problem.

    Und was ich sagen wollte ist, dass ich ein foreach schöner finde, wo man keinen Iterator zu Gesicht bekommt.

    Und was ich sagen wollte: ich finde es mit iterator schoener, weil ich einfach metainformationen gratis bekomme.

    Was das const betrifft: In Java schreibt man oft readonly-wrapper, z.B. für das List-Interface.

    Ich weiss, aber darum geht es nicht.
    Warum kommt dauernd ein "aber in Java macht man es anders" wenn es um C++ geht?

    In C++ hast du einfach ein const um zu zeigen, dass die Collection nicht geaendert wird, oder aber du arbeitest mit const_iteratoren. Vollkommen egal wie man es in Java macht.

    aber prinzipiell ist der Schreibschutz von verschiedenen Collections sehr einfach gebaut

    Stimmt, ein 'const' ist dagegen ja extrem komplex 😉

    Ne, ein const fehlt in Java wirklich, aber sie werden es nie einbauen. Das ist echt ein minuspunkt.

    während ich in C++ bei _jeder_ Klasse viele Methoden mit const überladen muss, einen eigenen Iterator verwenden muss für den const-Zugriff, usw.

    Du argumentierst jetzt nicht wirklich gegen ein const, oder? Das ist doch laecherlich.

    Hat jetzt aber IMHO nicht direkt was mit der foreach-loop zu tun.

    Eben, lass Java aus dem Spiel, das hat hier nix verloren.

    Eine foreach-loop ist für mich konzeptionell eine Aufzählung und eine Aufzählung ist für mich konzeptionell nicht eine Änderung am Container.

    Und? In C++ macht man da const wenn man es nicht aendern will. So einfach ist das.

    Nochmal langsam zum mitschreiben:
    nicht-const: veraenderbar
    const: aenderbar

    passt, doch. In C++ will man keine Beschraenkungen auferlegt bekommen.

    Zusammenfassend wollte ich eigentlich nur feststellen, dass die Sprache IMHO nichts damit zu tun haben dürfte, was eine Aufzählung ist, aber ich bin wie immer abgeschweift. 🙄

    Nein, du hast gesagt wie eine Aufzaehlung in Java ist, in C++ ist es aber anders. Mag sein dass Java 'perfekt' ist, aber in C++ macht man es halt anders.

    Ich kann ja jetzt auch anfangen und sagen: schleifen sind doch doof, konzeptionell sollte es immer eine rekursion sein.

    Ist genauso Begruendet wie "foreach darf container nicht aendern" aber in C++ halt absolut fehl am Platz.



  • 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>()
    

    MfG SideWinder



  • Shade Of Mine schrieb:

    Ist genauso Begruendet wie "foreach darf container nicht aendern" aber in C++ halt absolut fehl am Platz.

    Täusche ich mich, oder läßt std::for_each den Container auch unverändert?



  • 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=CppTest

    Fü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...


Anmelden zum Antworten