NULL Pendant bei value Typen

Mahlzeit,

wenn ich einen std::vector<T*> habe, dann kann ich ja ganz leicht signalisieren das ein Element unbelegt ist mit einem NULL Zeiger. Sagen wir ich habe 3 Elemente und das 2. ist gerade inaktiv, dann sieht das so aus:
[0] = 0x23346611
[1] = NULL
[2] = 0x22AA33CC

Nun möchte ich einen std::vector<Foo> haben, wobei Foo eine struct ist. Jetzt liegen da ja quasi echte Werte im vector. Wie kann ich das jetzt machen, dass Element 2 gerade inaktiv ist (Der Vektor soll dennoch 3 Elemente haben, nur soll irgendwie klar sein, dass Element 2 gerade keinen Wert hat)?

theta

Ich nemhe für alles 0 (NULL).
Im nächsten Standard wird dann ein nullptr dabei sein.

Dass ein Pointer NULL ist hat ja den Effekt, dass if(ptr) -> false ist.
Mit nem non-ptr kannst du das durch definition von opertor bool () erreichen.

struct Test
{
    operator bool () {
        if( bedingung_erfuellt ) return true;
        return false;
    }
}

Alternativ inderekt über eine Methode bool isValid() oder dergleichen, muss halt immer aufrufen.

Und da operator bool () dein Objekt nicht verändert, solltest du die Methode auch const machen

struct Test
{
    operator bool () const
    {
        //
    }
}

Dravere

Wenn ein Objekt Inaktiv sein kann, dann würde ich wirklich zu einer Methode bool isActive() const; oder sowas ähnliches raten.
Nur Objekte welche eine Abstraktion von Zeiger, Ganzzahlen oder dergleichen sind, sollten einen operator bool() const bekommen. Wobei man im aktuellen Standard lieber das Safe-Bool-Idiom verwenden sollte:
http://www.artima.com/cppsource/safebool.html

Grüssli

Dravere schrieb:

Wobei man im aktuellen Standard lieber das Safe-Bool-Idiom verwenden sollte:
http://www.artima.com/cppsource/safebool.html

Vielen Dank für den Link!!

hustbaer

Was macht ihr hier mit dem safe-bool Idiom rum?
Was wenn Foo ein std::string ist, oder halt einfach irgendwas was der OP nicht modifizieren kann/will?

@OP:
Guck dir mal boost::optional<T> an. Das ist ein Container für genau "ein oder kein T". Quasi die nullbare Variante von T.

theta schrieb:

Ich nemhe für alles 0 (NULL).
Im nächsten Standard wird dann ein nullptr dabei sein.

Wieso postest du ständig Antworten, obwohl du die Fragen nie verstehst?

@hustbaer: Danke!

Dravere

hustbaer schrieb:

Was macht ihr hier mit dem safe-bool Idiom rum?

Es gab den operator bool Vorschlag und da dieser nicht sehr gut ist, bzw. man ihn vermeiden sollte, habe ich das Safe-Bool Idiom vorgeschlagen. Hätte ich dies vermeiden sollen?

hustbaer schrieb:

Was wenn Foo ein std::string ist, oder halt einfach irgendwas was der OP nicht modifizieren kann/will?

Sowas kann es geben, nur wie oft kommt dies vor?
boost::optional<T> halte ich für gleich gefährlich wie boost::shared_ptr<T> . Das sind pauschale Lösungen, welche man für alles einsetzen kann und am Ende zu oft einsetzt. Daher würde ich solche pauschale Lösungen erst am Schluss empfehlen, wenn wirklich klipp und klar ist, dass es nicht anders geht.

Grüssli

theta

ribari schrieb:

theta schrieb:

Ich nemhe für alles 0 (NULL).
Im nächsten Standard wird dann ein nullptr dabei sein.

Wieso postest du ständig Antworten, obwohl du die Fragen nie verstehst?

@hustbaer: Danke!

ständig und nie ist wohl übertrieben. Bei diesem Thread ist das allerdings korrekt, ich habe die Frage nicht mal ganz gelesen... mein Fehler.
Simon

hustbaer

Dravere schrieb:

hustbaer schrieb:

Was macht ihr hier mit dem safe-bool Idiom rum?

Es gab den operator bool Vorschlag und da dieser nicht sehr gut ist, bzw. man ihn vermeiden sollte, habe ich das Safe-Bool Idiom vorgeschlagen. Hätte ich dies vermeiden sollen?

Sorry, mein Fehler. Ich meinte eigentlich wieso hier überhaupt die implizite Konvertierung nach bool vorgeschlagen wurde. Darauf hinzuweisen dass diese gefährlicher Unsinn ist, ist schon OK.

hustbaer schrieb:

Was wenn Foo ein std::string ist, oder halt einfach irgendwas was der OP nicht modifizieren kann/will?

Sowas kann es geben, nur wie oft kommt dies vor?

Nicht sehr oft, aber oft genug

boost::optional<T> halte ich für gleich gefährlich wie boost::shared_ptr<T> . Das sind pauschale Lösungen, welche man für alles einsetzen kann und am Ende zu oft einsetzt. Daher würde ich solche pauschale Lösungen erst am Schluss empfehlen, wenn wirklich klipp und klar ist, dass es nicht anders geht.

Solche Pauschallösungen schaffen aber auch einen gewissen Standard, was IMO gut ist.
Und oft genug sind sie "vollkommen ausreichend" passend.
Sich dann was anderes zu stricken halte ich nicht für sinnvoll.
Und auch andere Lösungen wie "-1 heisst undefiniert" sind nicht unbedingt optimal.
Wenn wo optional<foo> steht weiss ich wenigstens sofort dass es "null" sein kann