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

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?

camper

Die Antwort schrieb:

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?

Unfug.

camper schrieb:

Die Antwort schrieb:

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?

Unfug.

Unfug.

Dravere

Nexus schrieb:

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

Kommt drauf an, wie man es einsetzt. Wie es Shade Of Mine gesagt hat, ist es in den templates extrem praktisch. Ich zeig dir mal ein Beispiel von mir:

// Funktionshilfe (vielleicht mit C++0x auch nicht mehr nötig):
template<typename TNode, typename TIter>
util::CRangeIterator<TIter, CNodeTypeAcceptor<TNode> > create_node_type_iterator(TIter Start, TIter End)
{ return util::CRangeIterator<TIter, CNodeTypeAcceptor<TNode> >(Start, End); }

// Typen:
typedef /* ... */ t_NodeList;
typedef /* ... */ t_Element;

// Variablen:
t_Nodelist const NodeList;

// Verwendung aktuell:
typedef util::CRangeIterator<t_NodeList::const_reverse_iterator, CNodeTypeAcceptor<t_Element> > t_Iter;

t_Iter Iter = create_node_type_iterator<t_Element>(NodeList.rbegin(), NodeList.rend());

// -> WARGH!

// Verwendung mit C++0x:
auto Iter = create_node_type_iterator<t_Element>(NodeList.rbegin(), NodeList.rend());

// -> w00t!

Ich bin vom neuen Standard begeistert. Er geht mir im Gegenteil teilweise noch nicht weit genug. C++ war noch nie eine Anfängersprache und sollte es auch nie werden, dafür sollte sie richtig gute Features für die Fortgeschrittenen bis Profis anbieten.
Klar könnte man noch ein zwei Dinge vielleicht etwas besser machen, aber im gesamten bin ich wirklich begeistert.

Badestrand schrieb:

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 finde das wahnsinnig praktisch. Das ist die Sprachliche Implementation eines Singletons. Man schaue sich zum Beispiel die Klasse von nullptr an, das ist doch genial. Wieso noch einen Namen für die Klasse verschwenden, wenn man sowieso nie mehr als eine Instanz haben wird.
Widersetz dich nicht der Sprachsyntax, sondern werde eins mit ihr

Grüssli

Nexus

Meine Skepsis gegenüber C++0x ist wahrscheinlich auch darauf zurückzuführen, dass ich nur hobbymässig programmiere und weder riesige Projekte noch so komplizierte und lange Bezeichner habe, dass ein typedef ohne auto unübersichtlich wird. Ich kann mir gut vorstellen, dass die neue Syntax gerade professionellen Anwendern sehr helfen kann, möglicherweise werde ich das später auch so sehen

Aber wie gesagt, momentan komme ich eigentlich gut mit der jetzigen Syntax zurecht, und es fehlen mir vielleicht die Anwendungsmöglichkeiten von C++0x (wobei ich einige Dinge auch sehr praktisch finde).

drakon

Widersetz dich nicht der Sprachsyntax, sondern werde eins mit ihr

Komm auf die bös.. ähh gute Seite der Sprache Luke.

Ansonsten denke ich auch, dass mit C++0x vor allem die forgeschrittenen Programmierer an die Reihe kommen. Und nicht direkt eine "vereinfachung" stattfindet. Die Syntax wird wahrscheinlich noch abschrekender, wenn man es nicht kennt.
Nach dem Vortrag von Stroustrup soll aber allgemein auch noch mehr Ausdruck in die Sprache kommen und das finde ich extrem postitiv, dass man sich dann sehr direkt ausdrucken kann.

Die Antwort schrieb:

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?

Ich sehe, du hast mein Buch gelesen! Wenigstens einer in diesem Forum, der Ahnung hat! Von dir kann auch camper noch was lernen!

drakon

Bjarne Stroustrup schrieb:

Die Antwort schrieb:

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?

Ich sehe, du hast mein Buch gelesen! Wenigstens einer in diesem Forum, der Ahnung hat! Von dir kann auch camper noch was lernen!

Nur komisch, dass er eplizit zu 0 rät. (TC++PL, 4. Auflage, Seite 96, 5.1.1)

Hat er doch gesagt, 0 für C++!

keine Magicnumbers dafür im Code verteilen, sonder Konstanten oder Defines, dann kann mans auch schnell ändern, wenn 0x0000 doch besser ist als 0x0

0 ist keine Magic Number, sondern eine Rahmenvereinbarung!

das 0 wiel jede Zahl im Code eine Magicnumber ist, ist ja wohl klar. Irgend einer kommt irgendwann mal auf dei idee sowas zu machen

pos = 0;

if (...)
  pos = 0;

...

pos = 0;

Ach pos sollte da doch besser immer 7 sein, kein Problem Suchen & Ersetzen, ups alle null pointer geändert.

Dafür gibt es z.B. die ungarische Notation. 0 ist bei Zeigern weiterhin keine Magic Number.

jetzt hör mal zu, alter schrieb:

Dafür gibt es z.B. die ungarische Notation. 0

Du bist lustig

Wenns dann mal nen richtigen nullptr in C++ gibt, dann wirst du merken wie klever es war überall 0 hinzuschreiben, dann kannst du bei jeder Zahl und bei jedem Pointer schauen, ob du es ersetzen willst. Aber arbeitest du überhaupt an großen Projekten die auch in ein paar Jahren noch weiterentwickelt werden?

Große Projekte werden eh nicht migriert. Zumindest bei mir in der Firma ist das so. Da wird teilweise auch noch mit irgendwelchem pre-C++98 Müll rumgebastelt.

das wichtigste ist schrieb:

das 0 wiel jede Zahl im Code eine Magicnumber ist, ist ja wohl klar. Irgend einer kommt irgendwann mal auf dei idee sowas zu machen
pos = 0;

if (...)
  pos = 0;

...

pos = 0;
Ach pos sollte da doch besser immer 7 sein, kein Problem Suchen & Ersetzen, ups alle null pointer geändert.

Es ist nicht jede Zahl im Code eine Magic Number. Gerade 0 und 1 kann man oft einfach hinschreiben und trotzdem versteht noch jeder was gemeint ist. Magic numbers sind, wenn du anwendungsspezifische Werte ausschreibst (wieviel Lebenspunkte hat ein Axtkämpfer?), die man vielleicht sogar noch tunen müsste. Sowas versteht dann kein Mensch.

0 für Pointer ist vollkommen klar, da zerbricht man sich nicht den Kopf darüber.

LukasBanana

Hi, ich war schon länger nicht mehr hier im Thread weil ich dachte die Sache wäre bereits geklärt.
Aber danke noch mal an alle, ich habe mich jetzt auch für 0 entschieden. Das scheint in C++ einfach Gang-Gebe zu sein nicht mehr mit NULL zu arbeiten.

Gruß