//hier möchte ich quasi verhindern, dass der benutzer
//die zurückgelieferte adresse benutzt, um das objekt zu löschen
int *foo();

vielen dank schonmal im voraus

const hilft nicht. Wie sollten sonst const-Objekte zerstört werden, mmh?

Du könntest eine Proxy-Klasse mit überladenem -> Operator schreiben.

Oder vielleicht den Destruktor private machen und die Lösch-Instanz zum friend erklären (das ist allerdings ein fragwürdiges Design). Edit: Äääh und ich seh gerade, dass es sich um einen int handelt.

Oder, ja, Referenz, sofern der Schnittstellenvertrag das zulässt und die Eigentümerschaft klar geregelt bleibt.

Edit2:
Mal ganz davon abgesehen, dass ein Klient dieser Schnittstelle das Objekt niemals löschen kann (wenn er sie als Blackbox betrachtet), da er garnicht wissen kann, wie es erzeugt wurde (new, new[], malloc, irgendeine beliebige andere Funktion). Wer sowas macht, gehört sowieso geschlagen.

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.

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

Sorry, mein Fehler

Kein Problem. Und, no offense

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/

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 schrieb:

Sorry, mein Fehler

...Und, no offense

none taken!

Gruß,

Simon2.

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.