Sollte man in C++ 'NULL' oder '0' für Pointer-initialisierungen nehmen?

@ Dravere
Also ich hab mir deine hier gepostete Klasse mal angeguckt und finde sie gut, jedoch hab ich folgendes Problem:

// win32:

HANDLE handle = nullptr; // Kein Problem

if (handle != nullptr) // Error
{
    CloseHandle (handle);
    handle = nullptr;
}

Ich bekomme folgende Fehlermeldung:
error: no match for 'operator!=' in 'handle != nullptr'

Wie kann man die Operatoren noch am elegantesten hinzufügen?

Danke euch vielmals und viele liebe Grüße

Nexus

Mit einer globalen Operatorüberladung sollte das gehen. Allerdings müsste die Klasse dann einen Namen haben (ich hab mal nullptr_t gewählt), ist vielleicht blöd weil man dann Instanzen bilden kann...

Wahrscheinlich gibts eine bessere Lösung, hier trotzdem mal der Operator, bei dem du dann intern auf NULL überprüfen kannst:

bool operator !=(HANDLE h, nullptr_t n);
bool operator !=(nullptr_t n, HANDLE h);

Dravere

C++'ler schrieb:

@ Dravere
Also ich hab mir deine hier gepostete Klasse mal angeguckt und finde sie gut, jedoch hab ich folgendes Problem:

Ist nicht meine Klasse, ich fand sie nur extrem gut.

Und dein Problem kann ich mit meinem Compiler nicht nachvollziehen. Es funktioniert bei mir perfekt.
Bei mir gab es nur Probleme mit den Boost.SharedPtr, da reichte es die Sache umzudrehen:

// Aus:
if(x != nullptr)

// Wird:
if(nullptr != x)

Welchen Compiler benutzt du denn?

Grüssli

@ Dravere
Den zu Letzt erschienenden DevC++ von Bloodsheed.

Viele liebe Grüße

Dravere

C++'ler schrieb:

@ Dravere
Den zu Letzt erschienenden DevC++ von Bloodsheed.

Viele liebe Grüße

Wieso verwenden immer so viele den DevC++?
DevC++ wird nicht mehr weiterentwickelt und gilt als deprecated. Hol dir lieber Code::Blocks oder VS 2008 Express Edition. Würde mich nicht erstaunen, wenn es daran liegen könnte.

Grüssli

Nexus

Dravere schrieb:

Wieso verwenden immer so viele den DevC++?

Das wird wohl daran liegen, dass diese IDE vor allem für den Anfang einfach zu handhaben ist. Ich hab anfangs auch mit Dev-C++ gearbeitet. Man hat z.B. auch den Vorteil, nicht für jede kleine Datei gleich ein neues Projekt anzulegen.

Als Anfänger sagen einem natürlich IntelliSense, Debugger und moderne Projektverwaltung auch nicht besonders viel. Doch es hilft einem wirklich enorm, deshalb kann ich Dravere nur beipflichten. Code::Blocks kenn ich jetzt nicht, aber VS lohnt sich auf jeden Fall.

Wieso verwenden immer so viele den DevC++?

Genau aus dem gleichen Grund, warum einige noch C mit Klassen programmieren.

sothis_

Bulli schrieb:

Genau aus dem gleichen Grund, warum einige noch C mit Klassen programmieren.

ja, weil es c++ erlaubt. etwas schlimmes it dennoch nicht daran.

nochmal zu 0 vs NULL...ich meine gelesen zu haben dass der präprozessor eigetnlch nur noch für die c jünger in c++ vorhanden ist...und eigentlich nicht mehr wirklcih verwendet werden sollte.. wäre damit dann NULL nicht schon ausgeschlossen?
das mit foo(int) und foo(void*) ist ein schönes beispiel aber is das nicht irgendwie theoretisch? spricht das nicht villeicht für nen design fehler? und wenn mans doch so machen will warum sollte man der foo(void*) funktion ausgerechnet nen 0-pointer direkt übergeben?? ich behaupte mal die funktion kann damit nicht wirklich was anfangen und wenn man variablen übergibt dann isses doch eindeutig welche funktion aufgerufen wird da die variable ja dann entweder vom typ int oder ein pointer ist bzw sein sollte fragen über fragen ich benutze seit langem nur 0 und nie NULL und hatte damit noch nie probleme das musste einfach mal gesagt werden....

drakon

ich meine gelesen zu haben dass der präprozessor eigetnlch nur noch für die c jünger in c++ vorhanden ist...und eigentlich nicht mehr wirklcih verwendet werden sollte.

Das ist Mist.
Der Präprozessor ist eine nützliche Sache richtig eingesetzt. Und das gilt auch für (fast) alle Sprachmittel, dass sie schon ihre Berechtigung haben und richtig eingesetzt sind sie Gold Wert.

Das andere muss nicht soo theoretisch sein. Das kann (ok vlt. Designfehler) vorkommen, wenn man zum Beispiel ein riesiges Projekt hat, wo sehr viele Leute dran arbeiten und nicht alle über alles genau Bescheid wissen. Man sollte sich nicht zu fest auf den Programmierer verlassen, den der programmiert auch, wenn er Müde ist und wenn der Compiler ihm keine Fehlermeldung an den Kopf schmeisst, dann passiert genau so Zeugs.

nichts gegen den präprozessor der hat schon seine vorteile...den verwende ich auch hin und wieder aber nicht um "konstanten" zu definieren...

ja das kann passieren da muss ich dir recht geben aber was ich meine: foo(int) und foo(void*) macht doch nur probleme wenn man das mit foo(0) aufruft oder? und warum sollte man ner funktion nen 0-pointer übergeben? damit wäre es ja garnicht schlimm wenn die foo(int) funktion aufgerufen wird, da foo(void*) vermutlich sowieso nichts sinnvolles machen könnte oder hab ich was übersehen?

Nexus

drakon schrieb:

Der Präprozessor ist eine nützliche Sache richtig eingesetzt. Und das gilt auch für (fast) alle Sprachmittel, dass sie schon ihre Berechtigung haben und richtig eingesetzt sind sie Gold Wert.

Naja, wenn man gewisse Dinge betrachtet, die nur aus Kompatibilität zu C krampfhaft erhalten wurden, fragt man sich von Zeit zu Zeit schon wieder... Oder nur schon die Schlüsselwörter register , auto und goto werden in sauberem Code kaum jemals eingesetzt... Aber du hast ja zum Glück "fast" geschrieben

Ich hab dazu ein passendes Zitat:

Dirk Louis schrieb:

Die Geschichte des PC ist nicht nur eine Geschichte des Fortschritts, es ist auch eine Geschichte von beispielloser Rückwärtsgewandtheit - in Fachkreisen "Abwärtskompatibilität" genannt.

drakon

Naja, wenn man gewisse Dinge betrachtet, die nur aus Kompatibilität zu C krampfhaft erhalten wurden, fragt man sich von Zeit zu Zeit schon wieder... Oder nur schon die Schlüsselwörter register, auto und goto werden in sauberem Code kaum jemals eingesetzt... Aber du hast ja zum Glück "fast" geschrieben

Naja. Was sollen die machen? - Die Mittel einfach verbieten und plötzlich sind Millionen von Zeilen Code ungültig? Denen ist das alles schon bewusst, aber darum wird einfach von gewissen Sprachmitteln abgesagt, aber verbieten können sie es nicht. register und auto sind einfach mittlerweile überflüssig geworden, aber keineswegs unnütz. Und goto. Naja. Das ist ja der berühmte Streifall. Ich sage dazu nur so viel, dass ich es bis jetzt ein einziges mal "wirklich" gebraucht habe. Zugegeben war es da einfach so,dass ich schnell was funktionierendes haben wollte und da hat sich hald goto gerade perfekt angeboten.

Nexus

Ich erwarte keineswegs, dass diese Schlüsselwörter abgeschafft werden. In C++ etwas abzuschaffen kann man sowieso gleich vergessen. Vielleicht wird das der Sprache eines Tages zum Verhängnis werden...

Nein, ich bin mir der Konsequenzen eines "Verbots" von Sprachmitteln schon bewusst. Ich bin nur der Meinung, es gäbe sehr viele Dinge, die entweder niemand braucht oder die sehr unsauber bzw. mühsam sind. Aber mich stört es eigentlich nicht gross, ich kann ja die Dinge nutzen, die ich benötige.

Dravere

ratlosigkeit schrieb:

und warum sollte man ner funktion nen 0-pointer übergeben?

Ist die Frage wirklich ernst gemeint?
Damit kann man eine Option anbringen, ähnlich wie ein true/false, nur dass man es über ein Objektzeiger löst. Bei true ist es nicht nur ein true, sondern man hat gleich noch ein gültiges Objekt dazu. Zum Beispiel könnte man ein Objekt mitgeben, welches mitloggen soll, falls null übergeben wurde, so soll nichts passieren.

Im übrigen lohnt es sich an nullptr zu gewöhnen, wie schon erwähnt wurde, wird nullptr im nächsten C++ Standard enthalten sein, dort dann allerdings als Schlüsselwort.

Klar ist der Fall sehr theoretisch und man kann ihn oft sehr einfach umgehen, trotzdem ist es eine unnötige Einschränkung, welche eigentlich auch aufzeigt, dass etwas fehlt, nämlich das Nullelement des Zeigers.

#define NULL 0 ist übrigens noch weit verbreitet, da die WinAPI und MFC dies so verwendet. Sicherlich nicht gerade schön, aber naja ...

Grüssli

Badestrand

Nexus schrieb:

Ich erwarte keineswegs, dass diese Schlüsselwörter abgeschafft werden. In C++ etwas abzuschaffen kann man sowieso gleich vergessen.

Gerade zu einer neuen C++-Version fände ich einen kleinen "Cut" ganz gut. Ein paar alte Sachen rauswerfen, ein paar neue kommen ja auch rein, die Compiler könnten ja per switch nach verschiedenen Versionen kompilieren, dann muss auch kein Code weggeworfen werden. Würde C++ imho ganz gut tun, gerade auch Kleinigkeiten wie die Semikola nach Klassen-Deklarationen nerven mich einfach nur und scheinen so unnütz.

Nexus

Badestrand schrieb:

Nexus schrieb:

Ich erwarte keineswegs, dass diese Schlüsselwörter abgeschafft werden. In C++ etwas abzuschaffen kann man sowieso gleich vergessen.

Gerade zu einer neuen C++-Version fände ich einen kleinen "Cut" ganz gut. Ein paar alte Sachen rauswerfen, ein paar neue kommen ja auch rein, die Compiler könnten ja per switch nach verschiedenen Versionen kompilieren, dann muss auch kein Code weggeworfen werden.

Ja, einige Sachen sind unschön. Mir gefallen aber auch einige Teile der neuen Syntax nicht sehr (z.B. die Initialisierung mit {}, auto-Funktionen mit ->). Ich hab das Gefühl, C++ wird immer schwieriger, komplexer und abstrakter, gleichzeitig wird viel alter, unnötiger Ballast jahrelang mitgeschleppt. Auf Dauer kann so etwas nicht gut gehen. Und gerade Dinge wie decltype werden wohl nicht zu saubererem Code führen. Auch das auto bei Deklarationen ist wahrscheinlich nicht gerade hilfreich für den Programmierstil. Nett ist auch, dass die sonst schon nicht gerade trivialen Operatoren und Schlüsselwörter jetzt noch mehr Bedeutungen erlangen (z.B. operator-> , auto , default , using , delete ). Klar, ich finde auch, es gibt gute Neuerungen in C++0x, aber so wirklich überzeugt bin ich nicht.

Badestrand schrieb:

Würde C++ imho ganz gut tun, gerade auch Kleinigkeiten wie die Semikola nach Klassen-Deklarationen nerven mich einfach nur und scheinen so unnütz.

Ja, aber das Semikolon hat dort schon einen Sinn, die Klasse stellt schliesslich einen abgeschlossenen Typen dar... Sonst müsste man bei Enums, Unions und Array-Initialisierungslisten auch das Semikolon weglassen. Und ausserdem hat das ; den Sinn, dass man auch schreiben kann:

class MyClass
{
   // ...
} Instance;

Badestrand

Nexus schrieb:

Ja, aber das Semikolon hat dort schon einen Sinn, die Klasse stellt schliesslich einen abgeschlossenen Typen dar... Sonst müsste man bei Enums, Unions und Array-Initialisierungslisten auch das Semikolon weglassen. Und ausserdem hat das ; den Sinn, dass man auch schreiben kann:
class MyClass
{
   // ...
} Instance;

Ich finde diese Variablen-Deklarations-Möglichkeit direkt hinter Enum/Union/Struct/Klasse doof, einmal weil ich es nie brauche und andererseits, weil es meiner Intuition entgegen läuft. Ich meine, es steckt schon Logik dahinter, aber hinter Blöcken setze ich ungern Semikola; und eine Klassen-Deklaration ist für mich irgendwo ein Block, anders als z.B. eine Array-Initialisierungsliste.
Apropos Arrays: Die sollten dann auch gleich renoviert werden

Shade Of Mine

Nexus schrieb:

Auch das auto bei Deklarationen ist wahrscheinlich nicht gerade hilfreich für den Programmierstil.

Wenn du schonmal in Sprachen mit Type Inference programmiert hast, wirst du es zu schaetzen wissen. Der Typ von Objekten ist total egal, und gerade bei verschachtelten Templates oder Funktionszeiger, da will ich den Typ ja nicht mal sehen, weil ich sonst gehirnkrebs bekomme.

Ne ne, C++ geht in die richtige Richtung. Type Inference und lambda Funktionen, das ermoeglicht viel schoeneren Code.

das einzige keywords dass wirklich unnuetz ist, ist register.
und kompliziert? imho wird mehr vereinfacht als verkompliziert

Die richtige Antwort lautet 0 (int) für C++, NULL (void* 0) für C und NULL in C++, wenn man mit C-Bibliotheken arbeitet.

Wieso braucht ihr da 5 Seiten, um nichts zu sagen?