Der this-Zeiger im if

Aber zur Sicherheit noch einen catch(...)-Block drumherum!

volkard

Decimad schrieb:

Aber zur Sicherheit noch einen catch(...)-Block drumherum!

Hier die Datei "IchBinEineWaschmaschine.hpp"

#define main real_main
#indlude "IchMagJava.hpp"

Und die "IchBinEineWaschmaschine.cpp"

int main() {
	for(;;)
		try {
			int real_main();
			return real_main();
		} catch(...) {
		}
}

It0101

Nexus schrieb:

Soweit richtig?

Nein. Der Wert von t ist nach den Zuweisungen durch 0 , NULL und nullptr jeweils derselbe. Das Makro NULL ist in C++ gerade als 0 definiert, nullptr ist die typsichere C++11-Variante.[/quote]

Ich nutze das mal als Gelegenheit eine Frage zu stellen:

Was genau bringt "nullptr" für Vorteile gegenüber "NULL" oder "0" ? ( ist ernst gemeint ).

volkard

It0101 schrieb:

Was genau bringt "nullptr" für Vorteile gegenüber "NULL" oder "0" ? ( ist ernst gemeint ).

Irgendwie ist der Typ int da falsch.

#include <iostream>

char const* mySecret="geheim";

template<typename T,typename U>
bool test(T const t,U const u){
    return t==u;
}

int main() {
    using namespace std;
    if(mySecret==0)
        cout<<"no secret\n";
    if(test(mySecret,nullptr))
        cout<<"no secret\n";
    if(test(mySecret,0))//klappt seltsamerweise nicht
        cout<<"no secret\n";
}

SeppJ

Das hat diese Vorteile:
1. Es hebt die Doppeldeutigkeit der 0 auf (auch wenn diese aus Gründen der Abwärtskompatibilität weiterhin besteht, so sollte aber doch zumindest in neuem Code mit 0 immer eine Integer-Konstante gemeint sein).
2. nullptr ist von einem Pointertyp und somit nicht mehr in einen Ganzzahltyp (außer bool) konvertierbar.
3. Noch schlimmer als 0 war NULL, da es sich so anfühlte, als hätte es die Vorteile 1 und 2, aber in Wirklichkeit war das gar nicht so, da NULL in C++ als 0 definiert ist. Daher war folgende verwirrende Überladungsauflösung möglich:

void foo(int);
void foo(void*);
...
foo(NULL); // Ruft foo(int) auf

Das kann mit nullptr nicht passieren.

It0101

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

Swordfish

...

Nexus

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.

volkard

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.

It0101

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.

volkard

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.

LordJaxom

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.

volkard

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.

camper

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).

It0101

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

asc

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.

Jockelx

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.

volkard

Mir scheint, memset mag keine mmx-Befehle benutzen.

cooky451

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

It0101

volkard schrieb:

Mir scheint, memset mag keine mmx-Befehle benutzen.

Und das hat noch mal genau welche Nachteile?