Rückgabe von Objekten

[Dravere]

Bashar schrieb:

Wenn du ein Problem mit konkreten Beispielen hast, ...

Habe ich ja nicht. Es scheint eher, dass du Probleme hast, welche zu finden

Bashar schrieb:

... strlen ...

Ist, wie schon einmal gesagt, eine C-Funktion. In C gibt es keine Referenzen und keine Objekte. Alle Strings sind als Zeiger vorhanden. Also gibt es gar keinen anderen Weg.

Bashar schrieb:

... ifstream ...

Ich weiss nicht wieso man das bei ifstream , fstream und ofstream gemacht hat, ist aber meiner Meinung nach ein Designfehler. Vielleicht hat man es aber auch aus Kompatibilitätsgründen zu C gemacht, weil Stringliterale nunmal mit Zeiger angesprochen werden.
Interessanterweise wird dieser Designfehler nun "behoben".

Ich möchte zudem zu dem Thema noch ein paar Dinge anfügen.

Bisher hast du nur mit Funktionen argumentiert, welche einen C String erwarten. Da kommt man nunmal nicht um einen Zeiger herum.
Zeig mir mal eine Funktion, wo ein Objekt von einer Klasse übergeben werden muss und dabei Zeiger verwendet werden, aber in der Dokumentation steht, dass der Zeiger nicht 0 sein darf.
Da wirst du in der C++ Bibliothek wohl eher lange suchen.

Andere Bibliotheken können das sicher haben, zum Beispiel welche von volkard. Aber das heisst ja nichts. Das heisst einfach nur, dass ich diese Bibliothek als unschön empfinden werde.

Mir ist es daher ein wenig ein Rätsel, wieso du auf diesem Punkt so rumhackst und immer wieder Beispiele liefern willst, welche sowieso gar nichts bringen. Was willst du mit diesen Beispielen bezwecken?

Bashar schrieb:

Es gibt auch keine Möglichkeit, Zeiger, die nicht null sein können, zu spezifizieren. (Nein, das ist nicht die Aufgabe von Referenzen.)

Nein, das ist wirklich nicht die Aufgabe von Referenzen. Sie erfüllen aber genau diese Bedingung bei der Übergabe an Funktionen. Genau das was man braucht.

Grüssli

[Bashar]

EOD für mich.

[Shade Of Mine]

Dravere schrieb:

Bashar schrieb:

... strlen ...

Ist, wie schon einmal gesagt, eine C-Funktion. In C gibt es keine Referenzen und keine Objekte. Alle Strings sind als Zeiger vorhanden. Also gibt es gar keinen anderen Weg.

Es ist eine C++ Funktion da sie im C++ Standard erwaehnt wird.

Es waere trivial gewesen strlen(0) so zu definieren dass es etwas definiertes macht. zB 0 oder -1 zu liefern.

Aber es ist nicht notwendig. Dafuer wurden naemlich preconditions erfunden. Auch damals als man es noch nicht preconditions nannte.

Ein simples Beispiel fuer preconditions ist:

ofstream s;
s<<"foo";

s<<"foo"
ist eine precondition verletzung. Recht triviale Sache eigentlich.

Bisher hast du nur mit Funktionen argumentiert, welche einen C String erwarten. Da kommt man nunmal nicht um einen Zeiger herum.

Das ist aber eine komplette Themenverfehlung von dir. Denn es geht um Preconditions nicht um Zeiger.

strlen(0) koennte einfach 0 liefern oder -1 oder 7. Es muss nur definiert werden.

aber mal was anderes:
std::vector<int> v;
v[0]=3;

ist das nicht was lustiges? Es ist wieder einmal eine precondition verletzung (oder besser gesagt invarianten verletzung, aber ich bin mal so frech und packe das zusammen).

Zeig mir mal eine Funktion, wo ein Objekt von einer Klasse übergeben werden muss und dabei Zeiger verwendet werden, aber in der Dokumentation steht, dass der Zeiger nicht 0 sein darf.
Da wirst du in der C++ Bibliothek wohl eher lange suchen.

std::sort()

der comparer darf nicht ein null zeiger sein, wohl aber ein zeiger.

bekomm ich jetzt nen keks?

Bashar schrieb:

Es gibt auch keine Möglichkeit, Zeiger, die nicht null sein können, zu spezifizieren. (Nein, das ist nicht die Aufgabe von Referenzen.)

Nein, das ist wirklich nicht die Aufgabe von Referenzen. Sie erfüllen aber genau diese Bedingung bei der Übergabe an Funktionen. Genau das was man braucht.

Ich bin kein Fan von volkards variante mit zeigern fuer out parametern.
aber das wirkliche Problem dass er angeht damit ist ein ziemlich akutes:

c++ bietet nicht die moeglichkeit zwischen in, out und inout parametern zu unterscheiden. diese unterscheidung ist wichtig. wenn sie einem wirklich wichtig ist, dann ist die zeiger variante durchaus eine moegliche Loesung. uU wird es logischer wenn man

#define OUT &
connect(OUT con, "www.c++.de");

schreibt

aber das waere haesslich.

Die Frage um die es hier gehen sollte ist ob & eine sinnvolle Kennzeichnung fuer out parameter ist. Denn Zeiger die nicht 0 sein duerfen gibt es oefters - jeder kennt die C Strings und weiss dass es hier sehr oft so ist. Der Grund warum es in der C++ Standard Library sehr wenige solche Beispiele gibt kommt einfach daher dass fast nirgendwo Zeiger verwendet werden. Aber an fast allen Stellen wo Zeiger verwendet werden sind 0 Werte verboten.

zB das komplette iterator subsystem erlaubt keine 0 Zeiger. Einzig wo 0 zeiger erlaubt sind ist bei memory operationen. wobei ich jetzt auch nicht weiss was ein allocator::deallocate(0) macht... aber ein allocator::destroy(0) muesste UB sein...

und das zieht sich durch die ganze c++ standard library. volkards methode out parameter als Zeiger setzen ist unueblich - aber Zeiger die nicht 0 sein duerfen sieht man ueberall wenn man die augen aufmacht.

[Bashar]

Shade Of Mine schrieb:

volkards methode out parameter als Zeiger setzen ist unueblich

Sie wird auch von John Lakos ("Large Scale C++ Software Design") empfohlen.

[Dravere]

Shade Of Mine schrieb:

Es ist eine C++ Funktion da sie im C++ Standard erwaehnt wird.

Können wir uns darauf einigen, dass die Funktion aus der C Bibliothek 1:1 übernommen wurde. Ok, noch einen Namensraum std drumrum. Ansonsten ist das eine C Funktion. Wenn ich mich recht erinnere, steht das glaub ich sogar im Standard, dass die Funktion aus der C Library ist

Shade Of Mine schrieb:

... preconditions erfunden ...

Und eine Menge Beispiele mit Preconditions, aber hier ging es doch nie um Preconditions, oder habe ich was verpasst? Es ging doch um Zeiger übergeben zum Kennzeichnen von veränderbaren Objekten, statt einer Referenz, damit man keinen Nullzeiger übergeben darf.

Die ganze Diskussion wird völlig aus dem Kontext gezogen.

Shade Of Mine schrieb:

bekomm ich jetzt nen keks?

Ja, aber nur weil die hier gegessen werden müssen, sonst sind sie bald überfällig von Weihnachten her

Shade Of Mine schrieb:

Ich bin kein Fan von volkards variante mit zeigern fuer out parametern.
aber das wirkliche Problem dass er angeht damit ist ein ziemlich akutes:

Das will ich nicht abstreiten, aber solche Kennzeichnungen kann man anders machen und anders berücksichtigen. Das wurde ja auch schon gesagt. Darum ging es hier ja eigentlich auch nicht. Es ging um das wie des Kennzeichnens.

Shade Of Mine schrieb:

Die Frage um die es hier gehen sollte ist ob & eine sinnvolle Kennzeichnung fuer out parameter ist.

Genau! Du sprichst mir aus dem Herzen!

Shade Of Mine schrieb:

Denn Zeiger die nicht 0 sein duerfen gibt es oefters - jeder kennt die C Strings und weiss dass es hier sehr oft so ist.

Und da kann man bekanntlich auch nicht anders. Wurde auch schon gesagt.

Und es geht auch nicht um die Fehlerbehandlung, sondern es geht darum, dass man in C keine Referenzen verwenden konnte und erst recht nicht für C Strings. Es ging also um die Übergabe.

Shade Of Mine schrieb:

Der Grund warum es in der C++ Standard Library sehr wenige solche Beispiele gibt kommt einfach daher dass fast nirgendwo Zeiger verwendet werden.

Wieso wurden aber teilweise keine Zeiger hingeschrieben und einfach eine Bedingung hingemacht, dass keine Nullzeiger übergeben werden dürfen? Vielleicht weil es unsinnig ist und keine "Nullobjekte" übergeben werden sollten?

Bestes Beispiel sind da doch die swap Funktionen von den Containern. Wieso sollte man dort nicht einen Zeiger übergeben sollen. Würde doch gehen, wir müssen nur eine Precondition in die Dokumentation setzen, dass es kein Nullzeiger sein darf.

Shade Of Mine schrieb:

zB das komplette iterator subsystem erlaubt keine 0 Zeiger.

Mit diesen Zeigern als Zeigern komme ich als Nutzer aber nie in Berührung? Diese Zeiger sind Bibliothek intern und abgeschlossen. Zudem ging es nicht um die Speicherung als Zeiger, sondern um die Übergabe bei einer Funktion.

Ich übergebe zum Beispiel noch oft Referenzen, um dann deren Zeiger zu speichern. Der Zeiger in der Klasse darf kein Nullzeiger sein. Aber wie gesagt, darum geht es hier nicht.

Shade Of Mine schrieb:

Einzig wo 0 zeiger erlaubt sind ist bei memory operationen. wobei ich jetzt auch nicht weiss was ein allocator::deallocate(0) macht... aber ein allocator::destroy(0) muesste UB sein...

Das Beispiel ist aber auch eher witzig. Das Objekt, mit welchem man hier arbeitet, ist der Zeiger. Logisch übergibt man dann einen Zeiger. Was man aber nicht macht, ist ein Zeiger auf einen Zeiger zu übergeben

Grüssli

PS: Wer wettet, dass wir hier noch nicht am Ende der Diskussion sind?

[Badestrand]

Ich verstehe nicht ganz, wieso hier eine so ausufernde Diskussion entsteht Soweit ich weiß, hängt sich das Ganze doch an Volkards Anmerkung auf:

volkard schrieb:

aber noch lieber mag ich dann

Connection con;      // erstelle das Objekt
function(&con, 645);  // übergib das Objekt zur Bearbeitung.

damit ich sofort erkenne, daß con verändert wird. mir hilft das bei der fehlersuche, besonders, wenn der code schon ne ecke älter ist.

Daran ist nichts falsch und solange diese Konvention eingehalten wird, halte ich sie auch für sinnvoll. Dass Referenzen Nullzeigern vorbeugen können, bestreitet hier doch keiner und genauso unsinnig weil trivial ist eine Diskussion über strlen.

[Shade Of Mine]

Dravere schrieb:

Shade Of Mine schrieb:

... preconditions erfunden ...

Und eine Menge Beispiele mit Preconditions, aber hier ging es doch nie um Preconditions, oder habe ich was verpasst? Es ging doch um Zeiger übergeben zum Kennzeichnen von veränderbaren Objekten, statt einer Referenz, damit man keinen Nullzeiger übergeben darf.

Und genau das ist der Punkt an dem Preconditions relevant werden.
Denn eine Referenz hat eine erzwungene Precondition von "darf nicht null sein". Dass dies dennoch nicht immer gegeben ist (eine referenz kann ja ungueltig sein) sollte dir zu denken geben.

die aussage "damit man keinen nullzeiger uebergeben darf" ist eine precondition. du kannst sie auf bestimmte arten durchsetzen.

eine moeglichkeit ist es in der doku zu notieren. eine ist referenzen zu verwenden und eine ist ein assert(ptr); zu machen. das alles sind nur precondition validierungen - mehr nicht.

und das musst du verstehen. sonst ist die diskussion sinnlos.

Und es geht auch nicht um die Fehlerbehandlung, sondern es geht darum, dass man in C keine Referenzen verwenden konnte und erst recht nicht für C Strings. Es ging also um die Übergabe.

Du hast nichts verstanden

Eine Diskussion macht keinen Sinn

Shade Of Mine schrieb:

zB das komplette iterator subsystem erlaubt keine 0 Zeiger.

Mit diesen Zeigern als Zeigern komme ich als Nutzer aber nie in Berührung? Diese Zeiger sind Bibliothek intern und abgeschlossen. Zudem ging es nicht um die Speicherung als Zeiger, sondern um die Übergabe bei einer Funktion.

zeiger sind iteratoren.

bsp:

int arr[]={1,2,3};
vector<int> v(arr, arr+3);

PS: Wer wettet, dass wir hier noch nicht am Ende der Diskussion sind?

wir sind am ende - es macht keinen sinn weiter zu reden.

@Bashar:
Es macht ja durchaus auch Sinn out parameter zu kennzeichnen. das steht ja komplett ausser frage. aber weit verbreitet ist diese methode dennoch nicht.

es waere ganz interessant ueber fuer und wider von konkreten out parameter kennzeichnungen zu diskutieren.

ein problem von zeigern hier ist ja zB dass ich mir einen zeiger merken kann und den uebergebe statt &obj zu schreiben und mich so selbst austrickse. (wobei man natuerlich sich selber sowieso immer austricksen kann wenn man sich nur anstrengt)

was mir persoenlich am besten gefallen wuerde, waere ein feature in der IDE dass mir out parameter im call selber kennzeichnet - anhand der funktionsdeklaration.
zB:

void connect(Connection out& con, string const& server) {
  //...
}

Und in der IDE sehe ich dann:
Connection con;
connect(con, "bla blup");

denn eine kennzeichnung von out parametern auf einer freiwilligen basis innerhalb der calls sehe ich persoenlich als fehleranfaellig an... (uU mag natuerlich eine nicht perfekte methode zur kennzeichnung von out parametern besser sein als keine...)

[erkenner]

Badestrand schrieb:

Ich verstehe nicht ganz, wieso hier eine so ausufernde Diskussion entsteht Soweit ich weiß, hängt sich das Ganze doch an Volkards Anmerkung auf:

volkard schrieb:

aber noch lieber mag ich dann

Connection con;      // erstelle das Objekt
function(&con, 645);  // übergib das Objekt zur Bearbeitung.

damit ich sofort erkenne, daß con verändert wird. mir hilft das bei der fehlersuche, besonders, wenn der code schon ne ecke älter ist.

Daran ist nichts falsch und solange diese Konvention eingehalten wird, halte ich sie auch für sinnvoll. Dass Referenzen Nullzeigern vorbeugen können, bestreitet hier doch keiner und genauso unsinnig weil trivial ist eine Diskussion über strlen.

liegt an Shade Of Mines Themenverfehlungen.

[Simon2]

Hi,

sorry, dass ich noch einmal kurz an den Anfang dieser Diskussion schwenke.
Ich möchte mich auch nicht soooo leidenschaftlich daran beteiligen (das Thema selbst provoziert mich jetzt auch nicht ganz so), sondern nur noch eine kleine persönliche Einschätzung beisteuern:
Ursprungsargument:

volkard schrieb:

...
aber noch lieber mag ich dann

Connection con;      // erstelle das Objekt
function(&con, 645);  // übergib das Objekt zur Bearbeitung.

damit ich sofort erkenne, daß con verändert wird. ...

Dieses Argument begegnet mir hier zum ersten Mal, während ich die Einschätzungen "Ist nen Zeiger - könnte 0 sein" und "Ob der Parameter verändert wird, sage ich mit const" dauernd höre.
Letztlich kann ich mich auf keine der beiden Deutungsweisen 100%ig verlassen, aber auf eine, die außer mir keiner teilt, hilft mir nur sehr begrenzt (und nur bei selbstgeschriebenem Code) weiter - und sei sie noch so logisch und elegant.
Das allein hält mich schon davon ab, diese Interpretation zu verwenden.

Ärgerlicherweise kann man sich noch nichteinmal darauf verlassen,
- dass sich hinter einer Referenz ein gültiges Objekt liegt (bequemerweise hat man aber gar keine Möglichkeit, das zu überprüfen, weswegen einem nichts anderes übrigbleibt) und
- dass ein non-const Objekt wirklich geändert wird.

Gruß,

Simon2.

[Nexus]

Shade Of Mine schrieb:

und das musst du verstehen. sonst ist die diskussion sinnlos.
[...]
Du hast nichts verstanden

Eine Diskussion macht keinen Sinn
[...]
wir sind am ende - es macht keinen sinn weiter zu reden.

Und die Güte, ihm (und den anderen) dies Sache genauer zu erklären, besitzt du nicht?

Bei dir ist mir schon öfters aufgefallen, dass du teilweise einfach Sätze in den Raum wirfst, ohne sie zu begründen. Du gehst einfach davon aus, man wisse, was du damit meinst.

Beispiel:

Shade Of Mine schrieb:

Ein simples Beispiel fuer preconditions ist:

ofstream s;
s<<"foo";

s<<"foo"
ist eine precondition verletzung. Recht triviale Sache eigentlich.

Und dann noch etliche Male das Wort "precondition" zu erwähnen. Da erstaunt es mich nicht, dass Dravere der Zusammenhang fehlt.

Oder im anderen Thread:

iterator und const_iterator sind nicht verwandt.

Es ist ja nicht schlimm, aber wenn man dann nachfragt, solltest du nicht genervt antworten (was im anderen Thread schliesslich auch gut klappte). Es ist auch nicht böse gemeint, aber vielleicht solltest du dich etwas mehr darauf achten.

[volkard]

Nexus schrieb:

Bei dir ist mir schon öfters aufgefallen, dass du teilweise einfach Sätze in den Raum wirfst, ohne sie zu begründen. Du gehst einfach davon aus, man wisse, was du damit meinst.
Beispiel:

Shade Of Mine schrieb:

Ein simples Beispiel fuer preconditions ist:

ofstream s;
s<<"foo";

s<<"foo"
ist eine precondition verletzung. Recht triviale Sache eigentlich.

Und dann noch etliche Male das Wort "precondition" zu erwähnen. Da erstaunt es mich nicht, dass Dravere der Zusammenhang fehlt.

braucht man würklich länger als 10 sekunden, um zu sehen, daß "foo" nicht in die datei geschrieben wird (tip: in welche datei?)?
klar steigen manche leute aus der diskussion aus, wenn andere leute die klarsten argumente dutzendfach ignorieren und irgendwelchen mist verzapfen, der allein durch die ignoranz des erfinders unwiderlegbar ist.

[Nexus]

volkard schrieb:

braucht man würklich länger als 10 sekunden, um zu sehen, daß "foo" nicht in die datei geschrieben wird (tip: in welche datei?)?

Es ging mir hier nicht um die Precondition an sich, sondern um den Zusammenhang zum Thema. Und der war wirklich nicht sofort ersichtlich.

[Shade Of Mine]

Nexus schrieb:

volkard schrieb:

braucht man würklich länger als 10 sekunden, um zu sehen, daß "foo" nicht in die datei geschrieben wird (tip: in welche datei?)?

Es ging mir hier nicht um die Precondition an sich, sondern um den Zusammenhang zum Thema. Und der war wirklich nicht sofort ersichtlich.

Was genau ist nicht klar? Ich erklaere es gerne...

uU habe ich auch etwas falsch verstanden - aber soweit ich die Sache hier verstanden habe ging es darum dass ein Zeiger bedeutet dass das Objekt NULL sein kann und deshalb volkards Variante der Kennzeichnung von OUT parametern gegen die Sprache arbeitet.

Oder liege ich hier falsch?

[volkard]

Nexus schrieb:

volkard schrieb:

braucht man würklich länger als 10 sekunden, um zu sehen, daß "foo" nicht in die datei geschrieben wird (tip: in welche datei?)?

Es ging mir hier nicht um die Precondition an sich, sondern um den Zusammenhang zum Thema. Und der war wirklich nicht sofort ersichtlich.

das begann mit

Ich finde so einen Code eher fehleranfällig und unhandlich, erst recht um die Funktion zu implementieren, da man eine Fehlerbehandlung einführen muss, falls ein Null-Zeiger übergeben wird.

da hatte ich versucht, einspruch zu erheben. natürlich *muss* man das nicht machen. im späteren verlauf kamen dann an passender stelle auch begriffe wie preconditions.

[asc]

volkard schrieb:

Ich finde so einen Code eher fehleranfällig und unhandlich, erst recht um die Funktion zu implementieren, da man eine Fehlerbehandlung einführen muss, falls ein Null-Zeiger übergeben wird.

da hatte ich versucht, einspruch zu erheben. natürlich *muss* man das nicht machen. im späteren verlauf kamen dann an passender stelle auch begriffe wie preconditions.

Es gibt nunmal Anhänger des Ansatzes, das man die Fehlbedienung möglichst ausschließen will. Jede bereits im Vorfeld vermeidbare Precondition halte ich für sinnvoll, da sie die Fehlersuche erleichtert (Precondition muss man uU nachschauen, und sie sind nicht immer an den Parametern oder den Bezeichnern erkennbar).

cu André

[Simon2]

Bashar schrieb:

Shade Of Mine schrieb:

volkards methode out parameter als Zeiger setzen ist unueblich

Sie wird auch von John Lakos ("Large Scale C++ Software Design") empfohlen.

Was rät Lakos eigentlich für den Fall, dass
a) ein InputParameter (= kein Zeiger) optional ist?
b) ein bereits als Zeiger übergebener Parameter als Inputparameter an eine weitere Funktion weitergegeben werden soll?

oder in Code:

// a)
mach_nix_mit_optionalem_parm( ??? );

// b)
void mach_was_mit_parm(int* x) {
   *x = 0;
   mach_nix_mit_parm( ??? );
}

Gruß,

Simon2.

[Shade Of Mine]

asc schrieb:

Es gibt nunmal Anhänger des Ansatzes, das man die Fehlbedienung möglichst ausschließen will. Jede bereits im Vorfeld vermeidbare Precondition halte ich für sinnvoll, da sie die Fehlersuche erleichtert (Precondition muss man uU nachschauen, und sie sind nicht immer an den Parametern oder den Bezeichnern erkennbar).

Ist dir bewusst, dass du damit aussagst dass man Zeiger deshalb meiden soll weil man mit ihnen Fehler machen kann?

Zeiger zu meiden weil es Zeiger sind, ist einfach fragwürdig. Sehen wir uns zB Java an - da verwendet man nur Zeiger und hat Referenzen gleich komplett weggelassen und dort würde niemand so eine Diskussion führen.

Das Problem ist, dass es immer heisst dass Zeiger böse sind. Aber das sind sie nicht. Nur Anfänger sollten sie meiden. Das wirkliche Problem mit Zeigern sind nämlich wilde Zeiger und das kann einem bei Referenzen genauso passieren.

Null Pointer sind nichts unerwartetes...

@Simon2:
Ich sehe hier kein Problem. Einfach
mach_nix_mit_parm(*x)
schreiben
da die Funktion x entweder by value oder by const reference nimmt - je nachdem welchen Typ x hat. Die beiden Funktionen sind nämlich nicht verwandt oder sonst etwas - es sind einfach 2 freie Funktionen - warum sollten sie voneinander abhängig sein?

[Simon2]

Shade Of Mine schrieb:

...
@Simon2:
Ich sehe hier kein Problem. Einfach
mach_nix_mit_parm(*x)
schreiben
...

hmmm, wie passt das in die Logik:
"... beim call 'f(x)' weiß ich, dass der Parameter nicht verändert wird, bei 'f(&x)' weiß ich, dass er verändert wird..."?
Das könnte man zwar erweitern auf "...auch bei 'f(*x)' weiß ich ....", aber das Ganze wird doch ziemlich trashig bei

// b)
void mach_was_mit_parm(int* x, int** y) {
   *x = 0;
   mach_was_mit_parm2(x); // hoppla ... hier "sieht" man ja gar nicht, dass man etwas macht
   mach_was_mit_parm2(*x); // hier erst Recht nicht ....
}

und bei meinem anderen Beispiel lag der Schwerpunkt darauf, dass der Parameter optional ist. Da wird ein call-by-value jedenfalls eher "fingerbrechig" bzw. setzt seltsame und ansonsten unnötige Anforderung an den Typ (Def-konstruierbar, ...).

Gruß,

Simon2.

[drakon]

Da müsse man ja dann so vorgehen:

mach_was_mit_parm2(&(*x));

Oder man muss wissen, dass x ein Zeiger ist..
Aber da kann man ja gleich wissen, dass die Funktion etwas verändern kann..

[Simon2]

drakon schrieb:

Da müsse man ja dann so vorgehen:

mach_was_mit_parm2(&(*x));

...

oh ja und dann bei Pointerpointern dann

mach_was_mit_parm2(&(******y));

(nicht vergessen, sich bei jedem "" überlegen, ob man dereferenzieren darf, der operator()/operator&() evtl. überladen wurde, ....)

Alles nur, um ein "&" in den Aufruf zu bekommen...

Gruß,

Simon2.