zeiger löschen verhindern

7H3 N4C3R

Simon2 schrieb:

int const * foo();
täte es ja schon mal ...

Ähm wie kommst du darauf oder was meinst du?

Darauf kannst du ein delete machen wie auf alles andere.

Wie solle man sonst das hier wieder zerstören? :

int const * p = new const int(5);
delete p; // wäre ziemlich schlecht, wenn das nicht gehen würde :clown:

cv-Qualifikationen werden beim Erzeugen und Zerstören ignoriert.

pumuckl

wie siehts aus mit einem shared_ptr<int>:
macht zumindest deutlich(er), dass mutwillige Zerstörungsversuche nicht erwünscht bzw. eingeplant sind.

Simon2

7H3 N4C3R schrieb:

...cv-Qualifikationen werden beim Erzeugen und Zerstören ignoriert.

Hmmm, also ich hatte das anders in Erinnerung (meinte, mal Compile-Probleme mit einem delete auf einen "const *" gehabt zu haben) ... aber gerade habe ich auch die entsprechende Bemerkung im Std gefunden ...

Kap. 5.3.5.2, Note2 schrieb:

... a pointer to a const type can the operand of a delete-expression; it is not necessary to cast away the constness(5.2.11) of the pointer expression before it is used as the operand of the delete-expression...

Sorry, mein Fehler,

Simon2.

7H3 N4C3R

Simon2 schrieb:

Sorry, mein Fehler

Kein Problem. Und, no offense

StarCraftFeuerteufel

also referenzen machen sich schlecht, da ich u. U. auch mal einen nullptr zurückgeben möchte. das mit int war nur ein beispiel. in meinem fall ist das ein template-objekt-pointer, den ich zurückgebe.
naja das mit der proxy-klasse und factory, da weiß ich nicht was das ist bzw was damit gemeint ist. und shared_ptr sagt mir auch nichts

pumuckl

FreakyBKA schrieb:

naja das mit der proxy-klasse und factory, da weiß ich nicht was das ist bzw was damit gemeint ist. und shared_ptr sagt mir auch nichts

google: proxy pattern ist ein design pattern (Entwurfsmuster) - wenn du das noch nicht kennst solltest du es dir aneignen, es ist eines der häufiger gebrauchten Entwurfsmuster in OO-Software.
google: Factory pattern ist ebenfalls ein häufig gebrauchtes design pattern.
google: shared_ptr ist ein sogenannter smart pointer, wohl der bekannteste außer vielleicht std::auto_ptr. Solltest du noch nichts von smart pointern gehört haben, auch das ist ein in C++ sehr weit verbreitetes und bekanntes Konzept, das du dir auf jeden Fall früher oder später aneignen solltest.

P.S: wenn Begriffe auftauchen, die dir nichts sagen, zeig Einsatz und schau es nach (google, wikipedia...) bevor du hier nach Erklärungen fragst

http://www.gidf.de/

7H3 N4C3R

pumuckl schrieb:

google: proxy pattern

Naja, das Proxy Pattern wäre doch schon ziemlich hart und oversized. Auch wenn es dem Verständnis förderlich ist.

Ich dachte eher an sowas hier:

template <typename T>
class PointerProxy
{
  T* t_;
public:
  PointerProxy( T* t) : t_( t) { }
  bool assigned() const { return t_ != 0 }
  T* operator->() { assert( t_ != 0); return t_; }
}

Und dann eben:

PointerProxy<MyClass> f() {
  // do something
}

...

PointerProxy<MyClass> p = f();
if( p.assigned()) {
p->myMethod( "yay!");
}

Imho aber völlig unnötig, da einerseits eine Funktion, die dem Aufrufer auch den Besitz des Speichers überantwortet, schlampig wäre und andererseits ein Aufrufer, der einfach an diesem Zeiger rumlöscht, geschlagen gehört Das wäre sehr sehr schlechter Stil.

Simon2

7H3 N4C3R schrieb:

Simon2 schrieb:

Sorry, mein Fehler

...Und, no offense

none taken!

Gruß,

Simon2.

FreakyBKA schrieb:

ich habe eine funktion die dem benutzer einen zeiger auf ein objekt zurückgibt. allerdings habe ich da momentan das problem, dass der benutzer das dahinterstehende objekt löschen könnte (z.B. mit delete). meine frage ist nun ob ich das verhindern kann, vllt mit const oder so?

gib dem benutzer keine pointer, sondern IDs oder 'handles' für die objekte und ein paar funktionen, um mit den objekten zu arbeiten. dann hat er mit 'delete' u.ä. keine chance.

hustbaer

Du kannst User-Programmer in C++ nicht vor der eigenen Dummheit schützen.
Wenn du nur verhindern willst dass es unabsichtlich passiert, dann gib einen shared_ptr, oder eine selbst gestrickte Proxy-Klasse zurück.