3. Der this-Zeiger im if

Der this-Zeiger im if


  • Danke euch. Das leuchtet mir durchaus ein, wenngleich ich der Meinung bin, dass die Vorteile nicht ganz so groß sind, wie der Aufriss, der hier im Thread gemacht wird 😃

    0

  • ...

    0
  • N

    It0101 schrieb:

    Das leuchtet mir durchaus ein, wenngleich ich der Meinung bin, dass die Vorteile nicht ganz so groß sind, wie der Aufriss, der hier im Thread gemacht wird 😃

    Ist das gleiche wie mit std::array oder RAII: Du hast Null Kosten, wenn du nullptr benutzt -- nur Vorteile. Es wäre dumm, bei einem C++11-kompatiblen Compiler noch 0 oder NULL für Zeiger einzusetzen.

    0
  • V

    It0101 schrieb:

    Danke euch. Das leuchtet mir durchaus ein, wenngleich ich der Meinung bin, dass die Vorteile nicht ganz so groß sind, wie der Aufriss, der hier im Thread gemacht wird 😃

    Jo, ich hatte noch nie einen Fehler wegen 0 zu suchen.
    Also der Aufriß im Sinne von "Nehmt sofort nurnoch nulltptr, sonst werden wir alle serben!" ist sicher übertrieben.
    Vielleicht folgt bald im Thread "Würdest Du an wirklich großen Projekten arbeiten, dann wärst Du meiner Meinung.". Dann wird es religiös.

    Aber da wir nullptr schonmal haben, sollte man ihn auch nehmen, weil kostet ja nix und könnte irgendwann mal ein Viertel Stündchen sparen.
    Öhm. Nö, dann muss man das Mehr an Tipparbeit rechnen und 0 ist besser.
    Anderer Grund: Man muss sich nullptr angewöhnen, weil sich die deutlich überwiegende Mehrheit der Gemeinde es auch angewöhnt. Dadurch kann man Fragen mit Querllcode posten, ohne daß der Thread reflexartig fünf bis acht wohlmeinende Hinweise auf nullptr fängt und die Hauptfrage fast untergeht.

    0

  • Ich muss gar nichts. Ich arbeite mit memset, damit bin ich bei 90% der Member ohnehin unten durch. Den nullptr werde ich trotzdem verwenden, weil es ja in der Tat nichts kostet.

    0
  • V

    It0101 schrieb:

    Ich muss gar nichts. Ich arbeite mit memset, damit bin ich bei 90% der Member ohnehin unten durch.

    Jo. Das sagt, daß Du Dir seit Jahren Dein Compilat nicht mehr angeschaut hast.
    Der optimierende Compiler erkennt memsettende Schleifen von selber und optimiert genau gleich wie intrinsisches memset.

    0
  • L

    volkard schrieb:

    Also der Aufriß im Sinne von "Nehmt sofort nurnoch nulltptr, sonst werden wir alle serben!" ist sicher übertrieben.

    Solange ich mir aussuchen darf wo ich lebe werde ich auch Serbe.

    0
  • V

    LordJaxom schrieb:

    volkard schrieb:

    Also der Aufriß im Sinne von "Nehmt sofort nurnoch nulltptr, sonst werden wir alle serben!" ist sicher übertrieben.

    Solange ich mir aussuchen darf wo ich lebe werde ich auch Serbe.

    Ein albaner Witz. 🤡

    0
  • C
    Mod

    beispiellos schrieb:

    Eine Referenz auf 0 ist nicht per se UB, erst wenn auf sie irgendwie zugegriffen wird.

    Das ist ein bisschen unpräzise. Die Dereferenzierung von 0 ist erlaubt, der Begriff Referenz aber hier fehl am Platz, denn natürlich ist es UB, einen so dereferenzierten Nullzeiger zum Initialisieren einer Referenz zu verwenden (weil es eben keine Initialisierung mit einem Objekt ist).

    0

  • volkard schrieb:

    Der optimierende Compiler erkennt memsettende Schleifen von selber und optimiert genau gleich wie intrinsisches memset.

    Bei memset muss ich weniger tippen und ich spar mir ne Schleife die den Code unnütz verunstaltet. Gleiches gilt für memmove, memcmp, memcpy, etc ...

    Aber so viele Anwendungsfälle gibt es ja dafür ohnehin nicht, weil die Menge an PODs bei mir seit einiger Zeit rückläufig ist 😃

    0
  • A

    volkard schrieb:

    It0101 schrieb:

    Danke euch. Das leuchtet mir durchaus ein, wenngleich ich der Meinung bin, dass die Vorteile nicht ganz so groß sind, wie der Aufriss, der hier im Thread gemacht wird 😃

    Jo, ich hatte noch nie einen Fehler wegen 0 zu suchen.

    Du glücklicher... Mich hat dies einmal mehrere Tage gekostet, einen solchen Fehler zu finden und zu verstehen (Damals war mir die Problematik noch nicht so bewusst).

    Wenn der Compiler hier nullptr unterstützen würde, wäre es bei uns sicherlich eine feste Regel, diesen statt 0 zu verwenden. Nicht weil der Fehler unbedingt häufig wäre, aber die "Kosten" wenn dieser mal auftritt recht hoch sein können.

    Nur weil etwas bisher noch kein Problem gemacht hat, würde ich dennoch eine sichere Variante, wenn vorhanden, immer vorziehen.

    0
  • J

    SeppJ schrieb:

    3. Noch schlimmer als 0 war NULL

    Hat allerdings den Vorteil, dass -sofern niemand totalen Mist macht und NULL für was anderes als Pointer verwendet- man mit einem replace schnell alle NULLs durch nullptrs ersetzen kann.

    0
  • V

    Mir scheint, memset mag keine mmx-Befehle benutzen.

    0
  • C

    Die bringen bei einer 64-bit .exe auch eher wenig bei sowas, wie ich feststellen musste.

    0

  • volkard schrieb:

    Mir scheint, memset mag keine mmx-Befehle benutzen.

    Und das hat noch mal genau welche Nachteile?

    0
  • D

    volkard schrieb:

    Der optimierende Compiler erkennt memsettende Schleifen von selber und optimiert genau gleich wie intrinsisches memset.

    Kann man eigentlich den Compiler (gcc) irgendwie dazu überreden, ein std::fill() auch im Debug-Modus zu optimieren? Ich bin neulich erst darüber gestolpert, daß std::fill() im Debug-Build etwa um Faktor Hundert langsamer war als memset() (aufgerufen auf std::vector<int> und std::vector<float>). Da ich mit einer Embedded-Plattform arbeite, deren Rechenleistung ich ohnehin schon ganz gut ausnutze, war das ein echtes Problem.
    Kann ich also ausnahmsweise memset() benutzen, ohne dafür Haue zu bekommen, oder gibt es eine schönere Lösung?

    0
  • ?

    dooooomi schrieb:

    Kann ich also ausnahmsweise memset() benutzen, ohne dafür Haue zu bekommen, oder gibt es eine schönere Lösung?

    Was ist denn mit neuen Vektor erstellen und swappen?

    std::vector<float> f;
  // ...
  std::vector<float>(32, 4.5).swap(f);

    Könnte schneller sein, muss aber nicht...

    0

  • Wobei ich auf Performanceerkenntnisse aus dem Debug-Modus nicht so unbedingt viel geben würde. Es kann maximal als Hinweis auf mögliche Probleme genommen werden.

    Memset ist aufjeden Fall ganz schlecht! Nur totale Greenhorns, die ihr Compilat lange nicht angeschaut haben, verwenden sowas. Tu es nicht, sonst wirst du so wie ich! 😃
    Und nachher findest du noch raus dass es noch mehr Befehle gibt, die mit "mem" anfangen und wirst deinen STL-Funktionen untreu 😃

    Meine ehrliche Meinung ( die hier im Forum auf wenig Gegenliebe stößt )

    Erlaubt ist, was:
    a) den Coderichtlinien des Unternehmens nicht widerspricht
    &&
    b) funktioniert
    &&
    c) wartbar und lesbar ( im Sinne von Verständnis ) ist

    0
  • P

    dooooomi schrieb:

    Kann man eigentlich den Compiler (gcc) irgendwie dazu überreden, ein std::fill() auch im Debug-Modus zu optimieren?

    Entweder du optimierst, oder du optimierst nicht. std::fill zu optimieren, den Rest aber nicht, wird nicht gehen. Debuginfos bei optimiertem Code bekommst du mit gcc -g -On , wobei n den grad der Optimierung beschreibt. Aber nicht schreien, wenn Debugging damit kein Vergnügen mehr ist 😉

    0
  • V

    dooooomi schrieb:

    Kann ich also ausnahmsweise memset() benutzen, ohne dafür Haue zu bekommen, oder gibt es eine schönere Lösung?

    Klar. Schreib in Deine Sig, daß Du für embedded Geräte programmierst. Dann wird Dich nie mehr jemand wegen mit sowas belästigen.

    0
Anmelden zum Antworten