Wieso hat boost::shared_ptr<T> keinen Konvertierungsoperator T* ?
Gibt es dafür einen Grund?

bb

edit:
Und ist das eine ausreichende Lösung?

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();
	}
};

Oder stell ich mir so irgendwie nen Bein?

http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/shared_ptr.htm

Da steht doch, dass er einen hat...

T & operator*() const; // never throws

Gruß,
CSpille

bb

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.

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

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

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

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.

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

1. 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.

2. 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.