foo(Type *otype)

angebe, dann muss ich ja nen Pointer übergeben. Wenn ich es nun
aber so mache:

foo(Type &otype)

kann man ja nur dereferenzierte Sache geben, richtig?Es ist dann
aber trotzdem referentiell?!

kann mir jemand erklären was genau beim zweiten typ passiert?
(hab mal gelesen das das so einer dynamischer Referenz-typ sein
soll!in der gibs das jedenfall nich in C)

Gruß, TGGC (making great games since 1992)

ich bevorzuge erstere schreibweise, weil dann auch schon allein durch die Benutzung klar wird, ob man jetzt die Daten an die Funktion als referenz oder Kopie schickt. Die referenz würde ich nur dann verwenden, wenn es nicht anders geht (Kopierkonstruktor).

Du beforzugst also einen Zeiger als Parameter?
Dann musst du aber immer

parameter->foo

schreiben.

Ich hab mal ne kleine Frage: wenn ich bei Parametern
eine Referenz so:

foo(Type *otype)

angebe, dann muss ich ja nen Pointer übergeben. Wenn ich es nun
aber so mache:

foo(Type &otype)

kann man ja nur dereferenzierte Sache geben, richtig?Es ist dann
aber trotzdem referentiell?!

Im ersten Fall wird eine Kopie des Ausdrucks übergeben - call by value und das value ist vom Typ (Type *).
Das zweite ist call by reference. Du übergibst einen referenzierbaren(!) Typ (Type) und übertragen wird die Adresse (&) des Typs. Intern ist das identisch (es wird der Zeiger auf die Variable übergeben). In der Funktion hast Du nun eine Variable vom Typ (Type), die sich auch wie ein (Type) verhält. Sie muss also existieren.
Das ist ein sehr großer Vorteil und deswegen solltest Du (Type &) nahezu grundsätzlich nutzen, wenn Du in C (Type nutzen würdest. Du kannst sicher sein, dass die Variable eine gültige Referenz enthält, bei (Type kann ja auch null sein.
Darum (Type *), wenn Du Null erlauben kannst und (Type &), wenn Du einen Zeiger übergeben möchtest, der nicht Null sein soll.

Das Funktions-Argument muss referenzierbar sein, also ein gültiger Speicherbereich, genau wie bei (Type *):

void foo( int & ) { printf( "Referenz: %d\n", i ); i++; }
void bar( int * ) { printf( "Zeiger: %d\n", *i ); *i++; }

int main( void )
{
  int i = 1;

  foo( i );  // ok, referenz auf i wird erstellt, 1 wird ausgeben, i wird 2
  bar( &i ); // ok, Zeiger &i wird kopiert, 2 wird ausgeben, i wird 3
  foo( 1 );  // geht nicht, 1 ist nicht referenzierbar
  bar( 1 );  // geht nicht, 1 ist nicht vom Typ (int *)
  foo( NULL ); // geht nicht, NULL ist nicht wirklich int, auf jeden Fall nicht referenzierbar
  bar( NULL ); // geht, knallt aber.

  // (Type &) kann man natürlich auch austricksen.

  int * j = NULL;
  foo( *j );   // okay, knallt aber
  bar(  j );   // okay, knallt aber
}

Verzichtest Du soweit wie möglich auf Zeiger (kein int *j, kein (Type *), verringerst Du die Gefahr auf NULL-Pointer deutlich und damit die Gefahr eines fehlerhaften Zugriffs.

Krux schrieb:

//...

Du beforzugst also einen Zeiger als Parameter?
Dann musst du aber immer

parameter->foo

schreiben.

imho hat der -> op mehr style als der . op

Eine Referenz ist in C++ eine vereinfachte Schreibweise für Zeiger...

Nur ergänzend (um Missverständnissen vorzubeugen): Ja und Nein... eine Referenz hat Eigenschaften, die sie von einem Zeiger unterscheiden: Man kann sie nicht "umbiegen", nicht referenzieren, .... .

Trotzdem sind natürlich beides "Verweise auf Objekte", mit denen man "call by reference" umsetzen kann (bitte jetzt nicht mit dem "call-by-X"-Verständnis einer anderen Sprache kommen - andere Sprachen, andere Sitten ).

Gruß,

Simon2.

gehört diese call-by-reference sache zur "ihr sollt weniger
eigene Pointer verwenden"-Strategie?also damit meine ich das
man auch in der c++ std-lib viele implementationen hat die
dafür sprechen(vectoren, maps, bitsets)!

Hat einer eigentlich eine Ahnung warum Interfaces nicht in
C++ implementiert wurden? alle sagen ja es liegt daran das es
Mehrfachvererbung gibt!aber interfaces können ja mehr als nur
Mehrfachvererbung, oder? Also es gibt in meinen Augen keine
schöne Variante abstrakte Klassen zu machen.na klar geht es
aber ich find das irgendwie ekelig.

imho hat der -> op mehr style als der . op

Endlich ist mal jemand meiner meinung! Das sieht doch viel besser aus und macht erst die refernz sichtbar. Bei dem . ding kann es einen schon mal passieren(schussel), dass man in erwartung einer kopie veränderungen etc. macht, die sich dann aber auf das quellobjekt auswirken

Hat einer eigentlich eine Ahnung warum Interfaces nicht in
C++ implementiert wurden? alle sagen ja es liegt daran das es
Mehrfachvererbung gibt!aber interfaces können ja mehr als nur
Mehrfachvererbung, oder? Also es gibt in meinen Augen keine
schöne Variante abstrakte Klassen zu machen.na klar geht es
aber ich find das irgendwie ekelig.

Interfaces sind eine Notlösung in Sprachen, die keine Mehrfachvererbung erlauben wollen. Mehrfachvererbung ist kompliziert, sobald OOP verwendet wird. Solange man nur Klassen ohne virtual verwendet, ist Mehrfachvererbung aber eine sehr praktische Sache.

C++ unterstützt Mehrfachvererbung, also braucht man keine "interfaces".
Du kannst sie dennoch nachbilden, indem Du eine Klasse mit rein pure virtual functions erzeugt:

class MyInterface
{
  public:
    virtual void Func1( void ) = 0;
    virtual bool Func2( bool ) = 0;
    // usw.
};

Ein zusätzliches Schlüsselwort ist in C also nicht erforderlich.

Interfaces sind eine Notlösung in Sprachen, die keine Mehrfachvererbung erlauben wollen.

nein, mehrfachvererbung wurde in solche sprachen bewusst nicht eingebaut, z.b. wegen: http://en.wikipedia.org/wiki/Diamond_problem
mehrfachimplementation von interfaces dagegen ist unproblematisch.

Xin schrieb:

Interfaces sind eine Notlösung in Sprachen, die keine Mehrfachvererbung erlauben wollen.

nein, mehrfachvererbung wurde in solche sprachen bewusst nicht eingebaut, z.b. wegen: http://en.wikipedia.org/wiki/Diamond_problem
mehrfachimplementation von interfaces dagegen ist unproblematisch.

Ich weiß. Das Diamond-Problem tritt aber nur auf, wenn man die Technik nicht zu verwenden weiß. Virtueller Mehrfachvererbung kann eine Lösung sein, um wieder eine klare Hirachie hinzubekommen, wenn auch nur eine Lösung 2. Klasse. Den Diamanten kann man mit etwas Verstand durchaus vermeiden, von daher sehe ich ihn als Designfehler und Designfehler kann man keinem Sprachfeature zur Last legen.

Ich sehe das wie einen Führerschein. Wer einen PKW Fahren sollte, wird trotzdem geschult, wenn er einen LKW fahren will. Beim Programmieren ist das häufig leider nicht so. Wer ein "Hallo Welt" schreiben kann, darf ungestraft Mehrfachvererbung gegen die Wand fahren.
Bei vielen Sprachen hat man sich deswegen entschlossen, die LKWs abzuschaffen.
Schade für die Leute mit Führerschein.

Zeiger wollte man in Java ja auch schon abschaffen, aber da nimmt man wohl lieber das Risiko in Kauf, dass die Entwickler Mist bauen, als das es keine Java-Entwickler gibt.

Gruß,

Simon2.

Bei vielen Sprachen hat man sich deswegen entschlossen, die LKWs abzuschaffen.
Schade für die Leute mit Führerschein.

keine harmlosen LKW's, ich würde eher sagen: man hat sich dazu entschieden, selbstgebastelte und überfrisierte fahrzeuge vom strassenverkehr auszuschliessen. schade für police chaser, stuntmen und ähnliche freaks

btw: es ist ja nicht so, dass interfaces eine verkrüppelte art der mehrfachvererbung sein sollen, sondern sie sind eine weiterentwicklung.
in sprachen, die mehrfachvererbung statt interfaces haben, muss man sich interfaces mit tricks wie abstrakten klassen nachbauen (mit ausnahmen, ich glaub' in C# gibt es beides).

(mit ausnahmen, ich glaub' in C# gibt es beides).

kurz:nö!in C# gibs auch bloß interfaces nichts anderes

Xin schrieb:

Bei vielen Sprachen hat man sich deswegen entschlossen, die LKWs abzuschaffen.
Schade für die Leute mit Führerschein.

keine harmlosen LKW's, ich würde eher sagen: man hat sich dazu entschieden, selbstgebastelte und überfrisierte fahrzeuge vom strassenverkehr auszuschliessen. schade für police chaser, stuntmen und ähnliche freaks

Wer Autos bauen kann, kann sehr gute und sichere Eigenbauten auf die Straße schicken. In C++ zumindest.
Ich würde allerdings auch keine tiefergelegten Golf kaufen, wenn der Dorfdepp den zusammengeschraubt hat und damit die Felder bestellen kann.

Die Informatik hat keinen TÜV.
Die Lösung ist nur noch Standard-Autos zu erlauben. Die fahren sicherer. Stimmt.
Aber diese Sprachen schließen alle Informatiker aus, die Spaß am Rennsport haben, Schwertransporte benötigen, Motorradfahrer, Modellbauer, und viele, viele mehr.

Ich kenne noch bessere Formen: nur noch Standard-Algorithmen, forderte mal jemand in einer Firma, in der ich arbeitete. Nicht die Lösung ist das Problem, sondern die standardisierte Beschreibung der einer Lösung. Das funktioniert super bei standardisierten Problemen... merkt jemand was!?.

Undertaker schrieb:

btw: es ist ja nicht so, dass interfaces eine verkrüppelte art der mehrfachvererbung sein sollen, sondern sie sind eine weiterentwicklung.

Die Fachbegriffe hinter dem Joke ändern sich alle 5 Jahre, aber der Joke ist irgendwie immer der Gleiche.
Vor 5 Jahren wurde der Joke als "Java ist eine Weiterentwicklung von C++" erzählt.
Java erlaubt bis heute keine Templates.

Undertaker schrieb:

in sprachen, die mehrfachvererbung statt interfaces haben, muss man sich interfaces mit tricks wie abstrakten klassen nachbauen (mit ausnahmen, ich glaub' in C# gibt es beides).

C# hat nur interfaces.
Was ich an Interfaces nicht mag ist, dass man ein Interface mehrfach implementieren muss, sich die Funktionen hinter der Schnittstelle aber oftmals nicht ändern. Das Problem hat man auch schon erkannt, dafür kommt ja jetzt eine Technik, wo man die Funktionen aus anderen Klassen in den eigenen Namensraum übernehmen kann. Ich habe den Namen grade nicht im Kopf, aber an der Beschreibung fällt vielleicht dem einen oder anderen etwas auf...

Statt Mehrfachvererbung heißt die Zukunft also 'Interfaces und Übernahme der Methode aus der Basisklasse'. Das ist viel besser, ein deutlicher Schritt in die Zukunft und man benutzt keine böse Mehrfachvererbung.

Okay, ist das gleiche wie Mehrfachvererbung, aber es heißt wenigstens anders und man muss mehr tippen.
Man muss nicht alles ernst nehmen, was in der Informatik entwickelt wird. Das schließt Interfaces in meinen Augen ein.

Ich rate eher zu einer Sprache mit Mehrfachvererbung und guter Lektüre zu dem Thema. Die Dinge verstanden zu haben ist hilfreicher, als die Dinge nicht anzufassen, damit man nichts kaputt macht.

Die Lösung ist nur noch Standard-Autos zu erlauben. Die fahren sicherer. Stimmt.
Aber diese Sprachen schließen alle Informatiker aus, die Spaß am Rennsport haben, Schwertransporte benötigen, Motorradfahrer, Modellbauer, und viele, viele mehr.

naja, man ist ja nicht auf nur eine sprache festgenagelt.
willst du fahrzeuge aus sicheren und vielfach erprobten standardkomponenten bauen, dann nimm sprache X, die diese vorgehensweise begünstigt.
willst du ein super-science-fiction-mässiges gefährt basteln, wie noch niemand zuvor, dann nimm sprache Y, mit der man sogar die gewindegänge jeder schraube selbst feilen kann (wenn es sein muss). nur umgekehrt, also z.b. sprache X zu verwenden, wenn Y vorteilhafter wäre, wär' doof.

Xin schrieb:

Java erlaubt bis heute keine Templates.

Java hat noch nicht mal #defines, z.b. für bedingte compilierung und so...

Edit:
da war wohl einer schneller mit dem gleichen kommentar.
Zu #defines in Java, alles soll auf allen plattformen laufen, und den Debugmodus kann man nicht abschalten, ist doch 1a.

Xin schrieb:

Bei vielen Sprachen hat man sich deswegen entschlossen, die LKWs abzuschaffen.
Schade für die Leute mit Führerschein.

keine harmlosen LKW's, ich würde eher sagen: man hat sich dazu entschieden, selbstgebastelte und überfrisierte fahrzeuge vom strassenverkehr auszuschliessen. schade für police chaser, stuntmen und ähnliche freaks ;)...

Also WENN schon so ein Vergleich, dann würde ich eher sagen: Man hat sämtliche Schraubenzieher aus dem Verkehr gezogen, damit ja niemand mehr seinen Trabbi in was besseres (schneller oder größer oder tragfähiger oder benzinsparender oder ...) aufmotzen kann.

Gruß,

Simon2.