boost::shared_ptr kein Konvertierungsoperator

unskilled

Nein.
Das ist der Dereferenzierungs-Operator... ;o)
Und überall &*the_pointer schreiben zu müssen... ne...^^

bb

ipsec

Q. Why doesn't shared_ptr (or any of the other Boost smart pointers) supply an automatic conversion to T*?

A. Automatic conversion is believed to be too error prone.

Ist ja leider ein Nachteil der Kovertierungsoperatoren, das oft auch unerwünschte Konvertierungen möglich sind. Mit C++0x und explicit wird das sicher besser.

brotbernd

Mit normalen Zeigern und shared_ptr auf das selbe Objekte kann man ne Menge Blödsinn anstellen. Wenn Du z.B. mit so einem Konvertierungsoperator kurz einen normalen Zeiger hast und damit wieder in einen shared_ptr gehst, hast du 2 Referenzzähler und zwei deletes. Klar, wenn man ein bischen aufpasst, passiert sowas nicht, aber ein get() zwingt dich ein bischen mehr aufzupassen. Daher finde ich das eigentlich ganz gut so.

unskilled

ipsec schrieb:

Q. Why doesn't shared_ptr (or any of the other Boost smart pointers) supply an automatic conversion to T*?

A. Automatic conversion is believed to be too error prone.

Ist ja leider ein Nachteil der Kovertierungsoperatoren, das oft auch unerwünschte Konvertierungen möglich sind. Mit C++0x und explicit wird das sicher besser.

k, ty
ob das jetzt wirklich ne fehlerquelle ist... wage ich mal zu bezweifeln - aber ok... ^^

bb

unskilled schrieb:

Und überall &*the_pointer schreiben zu müssen... ne...^^

Jetzt nochmal eine theoretische Frage...
Du möchtest dir ja das &* sparen.

Jetzt hab ich mich gerade gefragt, was passiert denn, wenn ich in
Templates ein &* verwende, damit ich sie auf normale Zeiger und shared-Pointer
anwenden kann, hab ich wenn mein Zeiger 0 ist, undefiniertes Verhalten
oder ist das noch ok, weil ich auf die Speicherstelle nicht zugreife?

Ansonsten kann man natürlich eine Funktion aufrufen, die unterschiedlich für
normale Zeiger und shared_ptr definiert ist.

Gruß,
CSpille

unskilled

CSpille schrieb:

Jetzt hab ich mich gerade gefragt, was passiert denn, wenn ich in
Templates ein &* verwende, damit ich sie auf normale Zeiger und shared-Pointer
anwenden kann, hab ich wenn mein Zeiger 0 ist, undefiniertes Verhalten
oder ist das noch ok, weil ich auf die Speicherstelle nicht zugreife?

Prinzipiell schon. Ich denke aber, im Release-Mode wird es wegoptimiert werden und nur im Debug-Mode krachts(vermutlich die assertion davor im op* des smart_ptrs)

Ansonsten kann man natürlich eine Funktion aufrufen, die unterschiedlich für normale Zeiger und shared_ptr definiert ist.

Ja, eben - man hat wieder mehraufwand.
Oftmals interessiert es ja auch gar nicht, welche Art von pointer man verwendet, weil eine factory oder so dahintersteht, die nur ein pointer-typedef hat...

bb

hustbaer

unskilled schrieb:

ipsec schrieb:

Q. Why doesn't shared_ptr (or any of the other Boost smart pointers) supply an automatic conversion to T*?

A. Automatic conversion is believed to be too error prone.

Ist ja leider ein Nachteil der Kovertierungsoperatoren, das oft auch unerwünschte Konvertierungen möglich sind. Mit C++0x und explicit wird das sicher besser.

k, ty
ob das jetzt wirklich ne fehlerquelle ist... wage ich mal zu bezweifeln - aber ok... ^^

bb

Man könnte auch einfach davon ausgehen dass die grossen Jungs in dem Fall gewusste haben was sie da tun

Mir fällt zwar auf die Schnelle jetzt kein Beispiel ein wo es ein Problem machen würde, aber rein intuitiv finde ich es richtig so wie es ist.
Gäbe es eine implizite Konvertierung hätte ich ein mords ungutes Gefühl dabei, und hätte shared_ptr vermutlich nicht so schnell akzeptiert.

Ich würde dir auch raten keine wie von dir skizzierte Hilfsklasse zu schreiben.

unskilled

hustbaer schrieb:

Ich würde dir auch raten keine wie von dir skizzierte Hilfsklasse zu schreiben.

Also den Code so zu ändern, dass ich als Nutzer meiner Klasse dann davon ausgehen kann, dass es ein smart_ptr bleibt, der eine Methode T* get() const anbietet!?

Ich mag so etwas aber:

struct user
{
  struct pointer : boost::shared_ptr<user>
  {
    pointer() {}
    explicit pointer(user* x) : boost::shared_ptr<user>(x) {}

    operator user*()
    {
      return get();
    }
    operator const user*() const
    {
      return get();
    }
  };

  static const pointer bad_user;
  static pointer login(user::id_t user_id, const user::pwd_t& password);
  static void logout(pointer to_logout);
/*...*/
};

wenn ich irgendwann denke: der smart_ptr ist zu teuer, weil... keine Ahung, kann ich einfach nen normalen Pointer draus machen(das logout gibts ja eh - das im exceptionfall, speicherlecks entstehen sollte dort nichts ausmachen) - oder einen anderen smart_ptr aus einer anderen bibliothek nehmen, der vll kein get() anbietet...

ich hab auch gerade mal versucht, unsinn mit dem konvertierungs-operator zu machen - ist mir aber nicht gelungen.
es geht selbst nicht, noch einen smart_ptr um den gleichen ptr zu packen - außer mit casts, aber das ist ja schon boshaft. vor so etwas muss man sich imho nicht schützen...

bb

hustbaer

also das ist für mich überhaupt kein argument

du wirst shared_ptr nicht so schnell gegen einen raw pointer tauschen können. schliesslich verwendet man shared_ptr nicht ohne grund. d.h. du müsstest sowieso viel ändern.
dein "problem" ist leicht ohne so eine fragwürdige hilfklasse zu umgehen.

beispiel:

template <class T> T* get_pointer(T* p)
{
	return p;
}

template <class T> T* get_pointer(anderer_komischer_ptr<T> const& p)
{
	return p.was_auch_immer();
}

void ifoo(int *p)
{
}

void foo(boost::shared_ptr<int> const& sp)
{
	ifoo(get_pointer(sp));
}

void foo2(int* p)
{
	ifoo(get_pointer(p));
}

// ...

allgemein finde ich das die wesentlich schönere und sauberere lösung irgendwelche dinge die variieren können im eigenen programm austauschbar zu machen.

unskilled

so hatte ich es so gar zu erst - allerdings fand ichs hässlicher... -.-
naja, danke trotzdem - auch, wenn ich wohl ein wenig zu stur bin