Garantiert mir der C++-Standard, dass ein Zeiger der auf ein mit new reserviertes Objekt immer ungleich NULL ist?

MfG, EOutOfResources

#include <iostream>

class MyOb {
public:
  int i;
  MyOb() : i (200) {}
};

int main()
{
    MyOb * meins = new MyOb;

    #define NULL meins // dont do this, its UB :(

    std::cout << NULL;

}

Deswegen: [c]0[/c] statt [c]NULL[/c]. Zugegebenermassen etwas konstruiert aber es garantiert dir keiner das [c]NULL == 0[/c], also kann da auch was anderes drinstehen, und wenn das nun zufällig genau das ist was das [c]new[/c] als Adresse erzeugt, PECH.

[...] aber es garantiert dir keiner das NULL == 0 , also kann da auch was anderes drinstehen, und wenn das nun zufällig genau das ist was das new als Adresse erzeugt, PECH.

Doch, der Standard garantiert Dir das. Was Du da tust ist produziert UB und ist daher eh nicht relevant für die Frage.

EOutOfResources schrieb:

Hallo

Garantiert mir der C++-Standard, dass ein Zeiger der auf ein mit new reserviertes Objekt immer ungleich NULL ist?

MfG, EOutOfResources

Wenn Dein Name Programm wird, dann kann es, je nach Konfiguration der new -Fehlerbahandlung sein, dass new 0 zurückgibt.

Deswegen: 0 statt NULL .

Man muss immer Pimpl einsetzen und die Body-Klasse in der .cpp-Datei verstecken. Sonst könnte jemand #define private public schreiben und die Kapselung aufheben.

So läuft das in C++ nicht.

Nein.

#define NULL meins

Ob das erlaubt ist?
Aber mach doch

#define new new(badHint)

NULL, new, private, usw. zählen alle dazu.

padreigh schrieb:

Mist gibts irgendwo eingentlich eine Liste von UB? Wo schau ich sowas nach?

Den Standard nach "undefined" durchsuchen? Das lohnt aber den Aufwand nicht, gesunder Menschenverstand und Erfahrung sollten für die meisten Fälle reichen und ansonsten guckt man eben gezielt im Standard. Hier Kapitel 2.10 "Identifiers" wo man schon private und new findet und von dort wird man weiterverwiesen nach 17.4.3.1 "Reserved names" wo dann indirekt NULL ausgeschlossen wird.

Mist gibts irgendwo eingentlich eine Liste von UB? Wo schau ich sowas nach?

Im C++ Standard...

Wie bekomm ich denn heraus welche Doku "meinem" C++ entspricht? (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5))

Der Sinn eines Standards ist ja gerade, dass es nicht verschiedene Versionen gibt

Die meisten Compiler haben zwar gewisse Erweiterungen, aber um portabel programmieren zu können, solltest du dich soweit möglich an den C++-Standard halten. Abweichungen findest du in der Dokumentation deines Compilers.

Wie bekomm ich denn heraus welche Doku "meinem" C++ entspricht? (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5))

Das ist der C++ Standard (und eben das aktuelle Working Draft für den Neuen und nicht der momentan gültige Standard, darum die etwas anderen Nummern) und keine Doku...

http://www.cplusplus.com/reference/std/new/operator%20new/

Hab ich die Frage falsch verstanden? Hier steht doch ganz klar, dass die Rückgabe von new NULL ist, wenn kein Speicher mehr vorhanden ist und die nothrow-Variante vom Operator new genommen wird:

http://www.cplusplus.com/reference/std/new/operator%20new/

Von nowthrow war hier nie die Rede, es geht um das Verhalten von new. Und da garantiert der Standard, dass man den Speicher bekommt oder eine bad_alloc exception geworfen wird.

Von nowthrow war hier nie die Rede, es geht um das Verhalten von new. Und da garantiert der Standard, dass man den Speicher bekommt oder eine bad_alloc exception geworfen wird.

Es war die Rede vom operator new und der beinhaltet unter anderem die nothrow-Variante. Deswegen kann man doch nicht allgemein sagen, dass der Pointer, der mit new initialisiert wird, niemals NULL ist.

Garantiert mir der C++-Standard, dass ein Zeiger der auf ein mit new reserviertes Objekt [zeigt] immer ungleich NULL ist?

Die Reservierung ist aber nicht erfolgt, wenn new wirft.

Die Reservierung ist aber nicht erfolgt, wenn new wirft.

Genau! Wenn geworfen wird, will ich überhaupt nicht auf Gleichheit mit NULL prüfen.

Danke!

Hallo

Garantiert mir der C++-Standard, dass ein Zeiger der auf ein mit new reserviertes Objekt immer ungleich NULL ist?

MfG, EOutOfResources

NULL ist nach Konvertierung in einen beliebigen Zeigertyp ein Nullzeiger. Ein Nullzeiger zeigt definitionsgemäß niemals auf irgendein Objekt (ob nun per new oder irgendwie anders erzeugt).
Im Umkehrschluss folgt, dass wenn new erfolgreich war und ein Objekt erzeugt hat, das Resultat kein Nullzeiger sein kann.

Was macht new in diesem Fall, was garantiert der Standard

gar nix, "Exception Handling ausschalten" ist im Standard nicht vorgesehen...

Na, seht ihr, also doch alle Zeiger schön und brav mit NULL vergleichen

Öhm nein, in Standard C++ mal in der Regel nicht, da wirft new eine exception!?

padreigh schrieb:

Deswegen: 0 statt NULL .

Man muss immer Pimpl einsetzen und die Body-Klasse in der .cpp-Datei verstecken. Sonst könnte jemand #define private public schreiben und die Kapselung aufheben.

Ganz klares jain

Wenn man die Klasse wirklich "verstecken" will muss man PIMPLn (oder mit Factories arbeiten). Zumindest dann wenn "verstecken" bedeutet dass der Programmierer nichtmal sehen soll welche Member so für die Implementierung verwendet werden. Dazu reicht es nämlich das Header-File zu lesen, ganze ohne böse #define Tricks.

Wenn es allerdings um Kapselung geht, dann sollte man private in C++ IMO als ausreichen ansehen (*).
Grund: wenn man eine Klasse im selben Programm (in unterschiedlichen Translation Units) einmal mit public=public und einmal mit public=private übersetzt, dann ist das laut Standard IIRC "undefined behaviour (no diagnostic required)". Und sobald man anfängt sich auf Tricks zu verlassen die offiziell UB sind, kann man viel machen. Debugger anwerfen, nachsehen wie das worauf der PIMPL-Zeiger zeigt so aussieht, eigene Helper-Structs definieren, reinterpret_cast, fertig.

Ich finde das erwähnenswert, da PIMPL viele Nachteile hat, die man nicht nur deswegen in Kauf nehmen sollte, weil man (fälschlicherweise) denkt damit die Kapselung zu verbessern. Programmieren ist schon genug Arbeit ohne dass man sich das Leben noch unnötigerweise schwer macht

----

*: zumindest so lange eine Klasse keine Memberfunction-Templates hat die public oder protected sind. Der einzig mir bekannte standardkonforme Trick um "private" auszuhebeln ist nämlich der, eine Member-Funktion auf einen im eigenen Programm definierten Typ zu spezialisieren.

Ich persönlich meide PIMPL allerdings selbst dann WENN die Klasse public Memberfunction-Templates hat, weil es IMO einfach den Aufwand nicht wert ist. Wenn ein Programmierer rumpfuschen will, dann wird er es so oder so machen. private sagt ganz klar "Finger weg", und man muss mehr oder weniger fragwürdige Workarounds anwenden um es auszuhebeln. Das ist gut, denn es vermeidet "Unfälle" bzw. Unklarheiten. Alles was darüber hinaus geht, ist IMO in 95% der Fälle unnötig/übertrieben.