1) Implizite Abfrage

if (ptr)
if (!ptr)

2) Explizite Abfrage (statt NULL auch 0 oder nullptr -Klasse möglich)

if (ptr != NULL)
if (ptr == NULL)

Variante 1) ist kürzer und einheitlich mit den Smart-Pointers aus Boost (aber nicht mit std::auto_ptr ), bei 2) hingegen ist die Intention deutlicher und eine klare Abgrenzung von bool vorhanden. Bisher habe ich eigentlich immer 2) verwendet.

Hintergrund: Ich muss mir eigene Smart-Pointer-Klassen schreiben, und ich überlege mir, ob ich den Konvertierungsoperator

SmartPtr::operator SafeBool() const;

mit all seinen Problemen, oder lieber eine explizite Methode

bool SmartPtr::IsNull() const;

anbieten soll. Oder sollte ich mir lieber was ganz Anderes wie

bool IsNull(const SmartPtr&);

überlegen? Das wäre dann für einfache Zeiger überladbar, allerdings zum Preis, dass an vielen Orten im Code diese Überladung bekannt sein müsste. Ganz elegant kommt mir dieser Ansatz auch nicht vor, auch weil es die bisher einzige freie Funktion fürs SmartPtr -Interface wäre.

Ich würds auch da mit der Konvertierung belassen. Alleine aus dem Grun, dass es halt doch sehr etabliert ist. Die anderen Funktionen kannst du ja dennoch anbieten für die, die es lieber anders machen. Stört ja nicht.

Das Problem wenn du die Konvertierung nicht zu lässt ist ja dann halt, dass deine Klasse nicht wirklich generisch als Zeiger verwendet werden kann und ich würde sagen, dass das sehr verwirrend für einen Benutzer sein kann.

Die anderen Funktionen kannst du ja dennoch anbieten für die, die es lieber anders machen. Stört ja nicht.

Doch, ich hab etwas gegen redundante Funktionen und unnötig grosse Schnittstellen. Und ich möchte lieber innerhalb meiner Bibliothek eine einheitliche Konvention.

drakon schrieb:

Das Problem wenn du die Konvertierung nicht zu lässt ist ja dann halt, dass deine Klasse nicht wirklich generisch als Zeiger verwendet werden kann und ich würde sagen, dass das sehr verwirrend für einen Benutzer sein kann.

Das stimmt natürlich. Wobei ein Smart-Pointer ja auch sonst einige Memberfunktionen enthält, was mit normalen Zeigern auch nicht konsistent ist (halt Dinge wie Reset() , Swap() , Release() ). Man könnte die auch alle global und als friend deklarieren, aber ob es dadurch intuitiver wird...? Allfällige Überladungen für normale Zeiger würde ohnehin niemand nutzen.

drakon schrieb:

Die anderen Funktionen kannst du ja dennoch anbieten für die, die es lieber anders machen. Stört ja nicht.

Doch, ich hab etwas gegen redundante Funktionen und unnötig grosse Schnittstellen. Und ich möchte lieber innerhalb meiner Bibliothek eine einheitliche Konvention.

Naja. Das ist ja nicht die Welt eine weitere Funktion zu haben. Im Gegenzug machst du aber alle glücklich.
Vor allem bei Operatoren finde ich das sowieso durchaus legitim eine benannte Version der Funktion zu haben.

drakon schrieb:

Das Problem wenn du die Konvertierung nicht zu lässt ist ja dann halt, dass deine Klasse nicht wirklich generisch als Zeiger verwendet werden kann und ich würde sagen, dass das sehr verwirrend für einen Benutzer sein kann.

Das stimmt natürlich. Wobei ein Smart-Pointer ja auch sonst einige Memberfunktionen enthält, was mit normalen Zeigern auch nicht konsistent ist (halt Dinge wie Reset() , Swap() , Release() ). Man könnte die auch alle global und als friend deklarieren, aber ob es dadurch intuitiver wird...? Allfällige Überladungen für normale Zeiger würde ohnehin niemand nutzen.

Zusätzlich spielt es ja keine Rolle, wenn es noch mehr hat, aber der boolsche Operator ist halt schon ein recht etablierter Bestandteil eigentlich jeder Smart Pointer Klasse. Auf den Rest kannst du dich ja schon alleine wegen Gross-/Kleinschreibung nicht verlassen.

Welche der beiden Möglichkeiten verwendet ihr zum Abfragen, ob ein Zeiger auf Null zeigt? ...

Ich mache die explizite Variante und dazu auch noch eine verkehrt rum aussehende:

if (NULL == ptr)
if (NULL != ptr)

Der Grund für die explizite Variante ist, dass es eine Regel gibt, stammt, glaube ich, aus den MISRA Regeln, dass "if ()" immer eine explizite Bedingung enthalten soll...
Verkehrt rum, weil "sicherer". Man könnte sich ja vertippen und so was eingeben:

if (ptr = NULL)

Ich denke, das ist gewöhnungsbedürftig und "if (ptr == NULL)" ist auch ok (Hauptsache, explizite Bedingung), hat sich bei mir aber halt andersrum eingeprägt...
Ich habe mal neulich bei meinem älteren Code so was gesehen:

for (i = 0u; MAX > i; ++i)
{
    ...
}

D.h. es gab mal eine Zeit, wo ich es überall durchgehend im Quellcode "Konstante Vergleichsoperator Variable" eingegeben habe. Aber die Software musste auf einem Mikrocontroller "gedebugt" werden, wo man nur zwei Hardware-Breakpoints setzen konnte (Software-Breakpoints haben nicht funktioniert, weil Programm im Flash, d.h. ROM) - ist natürlich kein Argument für so was - erschien damals irgendwie als nützliche "Strategie"... weil wahrscheinlich Zeitdruck, zu viele Compiler-Ausgaben, keine Zeit und zu müde, zu monoton, um sie alle nach Warnungen durchzusehen usw.

Naja. Das ist ja nicht die Welt eine weitere Funktion zu haben. Im Gegenzug machst du aber alle glücklich.
Vor allem bei Operatoren finde ich das sowieso durchaus legitim eine benannte Version der Funktion zu haben.

Das erinnert mich an einen Thread aus dem SFML-Forum, wo tatsächlich vorgeschlagen wurde, für alle möglichen Funktionen Aliase einzuführen, um zusätzlich eine andere Namenskonvention zu haben.

Im Ernst: Alle glücklich machen zu wollen führt längerfristig zu Problemen. Man kann nicht alle Ansichten berücksichtigen, sondern muss Entscheidungen treffen. Und mir gefällt der Gedanke grundsätzlich nicht, zwei Dinge für den exakt gleichen Zweck anzubieten. Als Benutzer ist man tendentiell verunsichert und fragt sich, ob ein Unterschied in der Funktionalität besteht. Ich verstehe heute noch nicht, warum std::string size() und length() hat.

Wobei es hier natürlich weniger schlimm ist, weil das eine ein Operator ist – da hast du Recht. Die STL verwendet z.B. auch assign() , um Zuweisungen mit mehreren Argumenten durchführen zu können. Ich muss mir wahrscheinlich nochmals in Ruhe durch den Kopf gehen lassen, ob eine zusätzliche benannte Methode wirklich Vorteile brächte. Möglicherweise werde ich sie zuerst weglassen, dann kann ich immer noch schauen...

drakon schrieb:

aber der boolsche Operator ist halt schon ein recht etablierter Bestandteil eigentlich jeder Smart Pointer Klasse. Auf den Rest kannst du dich ja schon alleine wegen Gross-/Kleinschreibung nicht verlassen.

Das ist ein guter Punkt. Wenn man Funktionalität allein durch sprachübliche Konventionen ausdrücken kann, ist das sicher ein Vorteil.

Du überzeugst mich langsam... Beim Smart-Pointer scheint immer mehr dafür zu sprechen, einen Konvertierungsoperator bereitzustellen (unabhängig davon, ob IsNull() bleibt).

abc.w schrieb:

Ich mache die explizite Variante und dazu auch noch eine verkehrt rum aussehende:

if (NULL == ptr)
if (NULL != ptr)

Okay, noch eine Variante. Mir gefällt die Vertauschung jedoch nicht so (Begründung). Übrigens interessante Anekdote mit dem Mikrocontroller!

Danke für die bisherigen Antworten. Weitere Meinungen sind natürlich erwünscht!

Welche der beiden Möglichkeiten verwendet ihr zum Abfragen, ob ein Zeiger auf Null zeigt?

So gefragt 2).

Mit 1) schaue ich, ob der Zeiger gültig oder ungültig ist, ob er auf etwas zeigt oder auf nix. Ob es den pointee gibt oder nicht. Ob der Auftrag noch zu erledigen ist oder schon weg. Und so weiter.

Mit 2) schaue ich, ob der Zeiger auf *NULL zeigt. Also in Bäumen, verketteten Listen und so, wo in der Doku explitzit steht, daß NULL das Ende anzeigt.

Wobei ich aber nie NULL nehme, sondern nur 0 und bald nullptr.

Demnach müßte der SmartPointer für mich 1) anbieten und sonst nichts. Ich würde nie einen Smartpointer mit 0 initialisieren oder ihm eine 0 zuweisen, warum sollte ich dann so ulkig sein, und schauen, ob eine 0 drin ist?

IsNull ist nur eine Verblümung von 2), das müßte IsValid oder so heißen, um zur Verblümung von 1) zu werden.

Ich bin auch gegen Umdrehen wie bei if(0==ptr), weil das zu untersuchende Objekt ganz links beim Lesen hilft, so wie das empfangende Objekt in Zuweisungen ganz links, zum Beispiel if(0<=auszahlung-kontostand) versus if(auszahlung>=kontostand). Den extrem seltenen Zuweisungsfehler da wegzumachen, indem man mit so einem großen Hammer draufhaut und den Lesefluß==Debugfluß signifikant stört, ist nicht mehr gerechtfertigt.

Übrigens ist SafeBool auch eine Operation gegen ein Problem, das ich nicht habe. Ich bräuchte also kein SafeBool, da täte es vielleicht schon auch ein bool oder besser ein void*. Aber Einbasteln schadet erst recht nicht, weil ich von den SafeBool-Problemchen wohl auch nicht erwischt werden würde.

drakon schrieb:

Naja. Das ist ja nicht die Welt eine weitere Funktion zu haben. Im Gegenzug machst du aber alle glücklich.
Vor allem bei Operatoren finde ich das sowieso durchaus legitim eine benannte Version der Funktion zu haben.

Das erinnert mich an einen Thread aus dem SFML-Forum, wo tatsächlich vorgeschlagen wurde, für alle möglichen Funktionen Aliase einzuführen, um zusätzlich eine andere Namenskonvention zu haben.

Für x-beliebige Funktionen sicher nicht! Obwohl.. richtig sinnvoll wäre natürlich, wenn man die STL für alle schön macht:

std::remove_if (..);
std::RemoveIf (..);

Das wäre doch schon was tolles! :p (Mist.. Ich habe mein Sarkasmus-Schild verlegt..)

Im Ernst: Alle glücklich machen zu wollen führt längerfristig zu Problemen. Man kann nicht alle Ansichten berücksichtigen, sondern muss Entscheidungen treffen. Und mir gefällt der Gedanke grundsätzlich nicht, zwei Dinge für den exakt gleichen Zweck anzubieten. Als Benutzer ist man tendentiell verunsichert und fragt sich, ob ein Unterschied in der Funktionalität besteht. Ich verstehe heute noch nicht, warum std::string size() und length() hat.

Wobei es hier natürlich weniger schlimm ist, weil das eine ein Operator ist – da hast du Recht. Die STL verwendet z.B. auch assign() , um Zuweisungen mit mehreren Argumenten durchführen zu können. Ich muss mir wahrscheinlich nochmals in Ruhe durch den Kopf gehen lassen, ob eine zusätzliche benannte Methode wirklich Vorteile brächte. Möglicherweise werde ich sie zuerst weglassen, dann kann ich immer noch schauen...

Wie gesagt bei Operatoren finde ich das überhaupt nicht verwirrend (ansonsten stimme ich dir zu und finde das ebenfalls komisch). Im Gegenteil bei einem Operator würde ich sogar eine benannte Funktion erwarten. Es kann durchaus Fälle geben, wo das wünschenswert sein kann. Bei einem Smart Pointer eher weniger, aber wie du sagst bei assign oder Sachen, welche ein Argument bekommen macht es durchaus Sinn. (Da finde ich den Weg, den Eiffel geht noch sehr schön. Dort macht man einfach eine Funktion und sagt dann, dass man sie auch mit einem Operator aufrufen kann. Keine Verwirrung, sondern es ist immer klar, dass es das gleiche ist).

Imo ist es bei keiner anderen Klasse, wie einem Smart Pointer so deutlich, dass er mindestens diesen Operator unterstützen muss. Alles andere wäre sehr kontraintuitiv.

Stilfrage: if (ptr) oder if(ptr != NULL)

Meine Antwort:
if (ptr) kann ich deutlich einfacher lesen und verstehen als: if(ptr != NULL)

Warum ?
1. Keine Negierung in der Bedingung
2. kein zweiter - wenn auch einfacher - Operand
3. kürzer und deshalb einfacher und schneller zu lesen.

if (!ptr) kann ich etwas einfacher lesen und verstehen als: if(ptr == NULL)
Warum ?
1. Ich muss negieren oder ich muss mit einem zweiten, einfachen Operanden vergleichen, was aufs gleiche heraus kommt.
2. besser finde ich dennoch die erste Variante, weil kürzer und deshalb einfacher und schneller zu lesen.

Naja, ist nur so meine Ansicht.
Letzenendes sollte und MUSS das jeder so für sich halten können wie er will.
Es können gerade an diesen Stellen einfach nur unnötige Fehler enstehen,
wenn die API einem eine Logik aufzwingt, die man nicht gewoht ist.

Deshalb, bitte beide Varianten anbieten.

Danke, Gruß Frank

Der Thread ist seit über 12 Stunden auf und noch keine Beschwerde,
dass es nicht äquivalent ist, weil der Standard (afaik) ja nicht vorschreibt,
dass NULL auch 0 sein muss.

Cool...
Ich dachte der Thread endet in so einer ewigen Diskussion...

EDIT: Ich bevorzuge:

if(ptr)

if(!ptr)

(Ich werde nie einen Compiler verwenden, wo NULL != 0 ist)

EDIT: Außerdem verwende ich 0 und nicht NULL

Unglaublich...

Der Thread ist seit über 12 Stunden auf und noch keine Beschwerde,
dass es nicht äquivalent ist, weil der Standard (afaik) ja nicht vorschreibt,
dass NULL auch 0 sein muss.

Das hast Du falsch verstanden.
Ein Nullzeiger muß zwar intern nicht als 0 repräsentiert werden, aber immer wenn 0 in einem Zeigerkontext verwendet wird, wird die 0 in einen Nullzeiger umgewandelt, der wie gesagt nicht 0 sein muß, aber logischerweise beim Vergleich mit ==0 doch true sagt, weil die rechte 0 vor dem Vergleich erst in einen Nullzeiger umgewandelt wird. Damit ist für Dich das Wissen, daß NULL nicht unbedingt 0 sein muß, gar nicht Teil des beobachtbaren Verhaltens.
Höchstens im Debugger könnte man vor Schreck vom Stuhl fallen, wenn sofort nach ptr=0 in ptr eine 0xdeadbeef steht.

volkard schrieb:

Mit 1) schaue ich, ob der Zeiger gültig oder ungültig ist, ob er auf etwas zeigt oder auf nix. Ob es den pointee gibt oder nicht. Ob der Auftrag noch zu erledigen ist oder schon weg. Und so weiter.

Mit 2) schaue ich, ob der Zeiger auf *NULL zeigt. Also in Bäumen, verketteten Listen und so, wo in der Doku explitzit steht, daß NULL das Ende anzeigt.

Das scheint mir eine sehr sinnvolle Vorgehensweise zu sein. Sowas kann ich mir ernsthaft für meinem eigenen Code überlegen...

volkard schrieb:

Wobei ich aber nie NULL nehme, sondern nur 0 und bald nullptr.

Warum nicht schon jetzt? Ist natürlich nicht so gut wie in C++0x, aber viel besser als NULL und 0 .

const class nullptr_t
{
	public:
		// Konvertierbar in Datenzeiger
		template <typename T>
		operator T* () const
		{
			return 0;
		}

		// Konvertierbar in Zeiger auf Member
        template <class C, typename T> 
        operator T C::* () const 
        { 
            return 0; 
        } 

	private:
		// Nicht adressierbar
		void* operator& ();

} nullptr = {};

Zu gefrickelt?

volkard schrieb:

Ich bin auch gegen Umdrehen wie bei if(0==ptr), weil das zu untersuchende Objekt ganz links beim Lesen hilft, so wie das empfangende Objekt in Zuweisungen ganz links, zum Beispiel if(0<=auszahlung-kontostand) versus if(auszahlung>=kontostand). Den extrem seltenen Zuweisungsfehler da wegzumachen, indem man mit so einem großen Hammer draufhaut und den Lesefluß==Debugfluß signifikant stört, ist nicht mehr gerechtfertigt.

Genau, so ähnlich habe ich im anderen Thread argumentiert.

Frank Erdorf schrieb:

Meine Antwort:
if (ptr) kann ich deutlich einfacher lesen und verstehen als: if(ptr != NULL)

Warum ?
1. Keine Negierung in der Bedingung
2. kein zweiter - wenn auch einfacher - Operand

Ah, noch mehr Argumente für 1).

Frank Erdorf schrieb:

Es können gerade an diesen Stellen einfach nur unnötige Fehler enstehen,
wenn die API einem eine Logik aufzwingt, die man nicht gewoht ist.

Deshalb, bitte beide Varianten anbieten.

Nun ja, beim Verwenden einer Bibliothek muss man sich eben an dortige Konventionen halten. Das beginnt schon bei der Namenskonvention, geht weiter über die Verwendung diverser Sprachmittel, über Codestil allgemein. Benutzt die Bibliothek Exceptions? Smart-Pointer? Werden Callbacks über Funktionszeiger, implementierte Interfaces oder std::tr1::function realisiert? Implizieren Zeiger in der Schnittstelle, dass NULL erlaubt ist?

..., ob ich den Konvertierungsoperator

SmartPtr::operator SafeBool() const;

mit all seinen Problemen, ...

Nicht mehr "lange", mit dem neuen Standard bekommen wir explicit für die Konvertierungsoperatoren. Ich denke, dass man hier schon etwas zukunftsausgerichtet denken darf.

Ich mache es übrigens meistens so, wie volkard es beschrieben hat. Wenn der Nullzeiger einen Fehlerfall andeutet oder eine Gültigkeit, dann wird er einfach geprüft. In allen anderen Fällen vergleiche ich den Zeiger mit der nullptr Struktur. Und ich bin inzwischen sogar wieder vom nullptr == ptr Tripp abgekommen. Zu viele Leute scheinen damit Probleme beim Lesen zu haben und ich denke daher, dass hier die Wartbarkeit über die Fehlerprävention gewinnt

Grüssli

Nicht mehr "lange", mit dem neuen Standard bekommen wir explicit für die Konvertierungsoperatoren. Ich denke, dass man hier schon etwas zukunftsausgerichtet denken darf.

Ich weiss nicht, ob ich in der Bibliothek schon bald C++0x verwende. Wahrscheinlich würde ich die User stark dezimieren...

Dravere schrieb:

Und ich bin inzwischen sogar wieder vom nullptr == ptr Tripp abgekommen.

In meinen Anfängen verwendete ich NULL , dann 0 , später nullptr und jetzt für die Bibliothek wieder NULL (sonst nullptr ). Und in Zukunft werde ich wahrscheinlich implizit abfragen.

Dravere schrieb:

Nicht mehr "lange", mit dem neuen Standard bekommen wir explicit für die Konvertierungsoperatoren. Ich denke, dass man hier schon etwas zukunftsausgerichtet denken darf.

Ich weiss nicht, ob ich in der Bibliothek schon bald C++0x verwende. Wahrscheinlich würde ich die User stark dezimieren...

Aktuell wird explicit nur vom GCC 4.5 unterstützt. Aber ich meinte auch nicht, dass du bereits explicit einsetzen sollst. Aber man kann aktuell das Safe-Bool-Idiom verwenden und halt im Hinterkopf behalten, dass dies nicht ein Workaround für alle Zeiten ist, sondern nur bis der neue Standard sich etabliert hat. Damit halt der üble Geschmack ein wenig besser wird

Nexus schrieb:

Dravere schrieb:

Und ich bin inzwischen sogar wieder vom nullptr == ptr Tripp abgekommen.

In meinen Anfängen verwendete ich NULL , dann 0 , später nullptr und jetzt für die Bibliothek wieder NULL (sonst nullptr ). Und in Zukunft werde ich wahrscheinlich implizit abfragen.

Ich meinte wegen dem nullptr == ptr <-> ptr == nullptr
nullptr verwende ich schon noch weiterhin, wie ich es im meinem vorherigen Beitrag geschrieben hatte.

Grüssli

Dravere schrieb:

Nicht mehr "lange", mit dem neuen Standard bekommen wir explicit für die Konvertierungsoperatoren. Ich denke, dass man hier schon etwas zukunftsausgerichtet denken darf.

Ich weiss nicht, ob ich in der Bibliothek schon bald C++0x verwende. Wahrscheinlich würde ich die User stark dezimieren...

OpenSource