struct VECTOR
{
    float x, y, z;
};

// Referenz
void add(VECTOR &vector)
{
    vector.x += 3;
    vector.y += 3;
    vector.z += 3;
}

// Zeiger
void add(VECTOR *vector)
{
    vector->x += 3;
    vector->y += 3;
    vector->z += 3;
}

(Sorry, falls Fehler im Code sind. Hab noch keinen Compiler am Internetrechner)
(Die Funktionen haben keinen weiteren Sinn, solln nur als Beispiel dienen)

void print(VECTOR const &vector)
{
    cout<<vector.x<<' ';
    cout<<vector.y<<' ';
    cout<<vector.z<<' ';
}

// Zeiger
void add(VECTOR *vector)
{
    vector->x += 3;
    vector->y += 3;
    vector->z += 3;
}

Wenn man mit Zeiger schreibt, sieht es auch viel professioneller aus.

hmmm...?

Gruß

Ich nehme pointer nur, wenn ich wirklich muss.

besser sind hier zeiger, um beim aufruf schon zu zeigen, daß was geändert wird an den daten. nimm die referenz, wenn sie als const-referenz geht, also eigentlich auch by-value gehen würde, und wenn es sich wie mit by-value anfühlen soll.

Mit dieser Meinung bist du hier ziemlich alleine!

Mit dieser Meinung bist du hier ziemlich alleine!

irgend jemand muß ja vorangehen. wir haben lange zeit zu viele referenzen benutzt aus fadenscheiniten gründen, eigentlich nur, weil es geht. du wirst oft hören "nimm immer referenzen, wenn es überhaupt möglich ist und nur im aüßerseten notfall zeiger". aber selten mit guter begründung und nie mit einer, die einer längeren diskussion standhält. weil es nämlich gar nicht so ist, daß man bei zeigern jeden übergebenen wert auf 0 prüfen sollte.

swap. schrieb:

Mit dieser Meinung bist du hier ziemlich alleine!

irgend jemand muß ja vorangehen. wir haben lange zeit zu viele referenzen benutzt aus fadenscheiniten gründen, eigentlich nur, weil es geht. du wirst oft hören "nimm immer referenzen, wenn es überhaupt möglich ist und nur im aüßerseten notfall zeiger". aber selten mit guter begründung und nie mit einer, die einer längeren diskussion standhält. weil es nämlich gar nicht so ist, daß man bei zeigern jeden übergebenen wert auf 0 prüfen sollte.

Du glaubst du gehst voran ? Aber nur weil du dich nicht umdrehst und siehst
das alle anderen in die entgegengesetzte Richtung marschieren.

Referenzen sind aus vielerlei Hinsicht besser: Sie bringen das Fehlerrisko nahe Null, machen den Code lesbarer, und sind fuer den Compiler leichter zu optimieren (da der Geltungsbereich genau definiert ist).

Falls moeglich, sollte man nur Zeiger verwenden, die die Adresse einer Referenz nehmen (z.B. bei Konstruktorparametern).

Am besten ist, man vermeidet auch new- und delete-Operator-Aufrufe. Man kann in C++ ja Objekte auf dem Stack deklarieren, die dann beim Verlassen des Geltungsbereichs automatisch vernichtet werden. Das nicht nur praktisch, sondern auch lesbarer, und bei der Exception-Behandlung muss man sich dann auch um nichts kuemmern.

Manche Leute verwenden gruendsatzlich nur dieses Modell, und verwenden Zeiger nur innerhalb von AutoPointer-Objekten.

Referenzen helfen, C++ Code robust zu machen.

Setzt man Referenzen geschickt ein, kann man in C++ genauso idiotensicher wie z.B. in Java programmieren.

volkard hat sowieso Unrecht.

Zum Überprüfen der Zeiger auf 0: Weiter oben angeführte C++-FAQ impliziert ähnliches in anderem Kontext: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.12

(Kurz: dass eine Überprüfung auf 0 von Zeiger-Argumenten nicht immer notwendig ist.)

(Kurz: dass eine Überprüfung auf 0 von Zeiger-Argumenten nicht immer notwendig ist.)

Eine Referenz ist kein Zeiger, daher hinkt der Vergleich (falls beabsichtigt).

Die Ueberpruefung von Zeigern auf 0 bringt relativ wenig, da der Fall selten vorkommt, dass ein falscher Zeiger auf die Adresse 0 zeigt.

Ausnahme sind z.B. ungepruefte dynamic_cast<> Aufrufe, sowie andere Aufrufe, die einen 0-Zeiger im Fehlerfall zurueckliefern, der dann ungeprueft als Zeiger verwendet wird. D.h. die Pruefung sollte beim Aufrufer erfolgen und nicht beim Aufgerufenen.

Einziges gutes Argument fuer Zeiger, das mir grade einfaellt, ist, dass die Anzahl von Konstruktoraufrufen durch die Verwendung von Zeigern reduziert werden kann. Dies hat einen definitiven Performance-Impact.

Aber man kann sich dann gleich fragen lassen, warum man C++ und nicht C benutzt. Der Programmieroverhead in C++ wird durch die Verwendung von Zeigern stark erhoeht, und das Fehlerrisiko steigt.

Konrad Rudolph schrieb:

(Kurz: dass eine Überprüfung auf 0 von Zeiger-Argumenten nicht immer notwendig ist.)

Eine Referenz ist kein Zeiger, daher hinkt der Vergleich.

Ich bezog mich auf Volkards Aussage "[...] weil es nämlich gar nicht so ist, daß man bei zeigern jeden übergebenen wert auf 0 prüfen sollte."

Der Programmieroverhead in C++ wird durch die Verwendung von Zeigern stark erhoeht, und das Fehlerrisiko steigt.

Nun, es ging hier doch nur um Parameterübergabe per Zeiger/Referenz und hier entsteht wohl kaum ein Programmieroverhead durch Zeigerverwendung (zumindest, wenn man sich um Nullwerte keine Sorgen macht).

Nun, es ging hier doch nur um Parameterübergabe per Zeiger/Referenz und hier entsteht wohl kaum ein Programmieroverhead durch Zeigerverwendung (zumindest, wenn man sich um Nullwerte keine Sorgen macht).

Ja, das stimmt.

Ich mein ja nur. Wenn wir's schon von Referenzen vs. Zeiger haben.

Einziges gutes Argument fuer Zeiger, das mir grade einfaellt, ist, dass die Anzahl von Konstruktoraufrufen durch die Verwendung von Zeigern reduziert werden kann. Dies hat einen definitiven Performance-Impact.

versteh ich nich
im zusammenhang mit referenzen die als argument einer funktion übergeben werden?
wo finden da konstruktorenaufrufe statt?

Power Off schrieb:

Einziges gutes Argument fuer Zeiger, das mir grade einfaellt, ist, dass die Anzahl von Konstruktoraufrufen durch die Verwendung von Zeigern reduziert werden kann. Dies hat einen definitiven Performance-Impact.

versteh ich nich
im zusammenhang mit referenzen die als argument einer funktion übergeben werden?
wo finden da konstruktorenaufrufe statt?

Z.B. bei dieser Sequenz:

#include <string>

using std::string;

void func( const string& str ) {
   // ...
}

void func2( void ) {
   func( "alpha" );  // versteckter Konstruktor-Aufruf: es wird ein temporaeres string-Objekt angelegt
                     // und danach wieder vernichtet.
   string c = "alpha" + string("beta");  // 2 Konstruktor-Aufrufe, 1 Destruktor-Aufruf, 
                                         // 1 operator+() Aufruf
}

string c = "alpha" + string("beta");  // 3 Konstruktor-Aufrufe, 2 Destruktor-Aufrufe, 
                                         // 1 operator+() Aufruf
}

ich zähle aber nur 2 ctor-aufrufe, 1 dtor-aufruf und 1 op+()-aufruf.

/**
   *  @brief  Concatenate C string and string.
   *  @param lhs  First string.
   *  @param rhs  Last string.
   *  @return  New string with value of @a lhs followed by @a rhs.
   */
  template<typename _CharT, typename _Traits, typename _Alloc>
    basic_string<_CharT,_Traits,_Alloc>
    operator+(const _CharT* __lhs,
	      const basic_string<_CharT,_Traits,_Alloc>& __rhs);

ich zähle aber nur 2 ctor-aufrufe, 1 dtor-aufruf und 1 op+()-aufruf.

Stimmt, hast recht. Werd's gleich korrigieren!

void func( const string* str ) {
   // ...
}

void func2( void ) {

   func( &string ( "alpha" ) );

   //wohl eher 
   string c = string ( "alpha" ) + string("beta");  
   //weil "alpha" sonst nur n zeiger is zu dem du addierst
   //beim zweiten kann ich den vorteil von zeigern auch nich nachvollziehn
   //geht schliesslich garned mit zeigern
}

[/quote]

volkard hat sowieso Unrecht.

Falsch geraten, Volkard hat immer Recht (naja, fast). Er wird schliesslich nicht umsonst "The Godfather" genannt.

Trotzdem hab ich seine Ansichten bzgl. Referenzen vs. Zeiger in diesem Punkt nie nachvollziehen können. Mir ist es ehrlich gesagt zu unintuitiv, anhand semantischer Feinheiten zu erlesen, was ein Programm macht. Mir ist zB vollkommen egal, ob da

add_something(foo)

oder

add_something(&foo)

steht. Das einzige was mich interessiert, ist, dass something zu foo addiert wird.

Wenn ich programmiere, dann weiß ich ja was die Methoden die ich aufrufe machen.
Wenn ich mir später meinen Code wieder durchsehe und Methodenaufrufe mit '&' sehe, dann weiß ich sofort.. oha.. der will einen Pointer -- gut da passen wir mal auf.

(naja, fast)

genau das meinte ich

Nimmt die Methode einen Pointer, dann kann man sich sicher sein, dass die Methode dem Paramerter verändert.
Nimmt die Methode eine (const) Referenz, dann ist man sich sicher, dass die Methode den Parameter nicht verändern kann.

Warum macht man das nicht gleich nur mit Referenzen?

void func( const alpha& a );  // a kann nicht geaendert werden
void func( alpha& a );        // a kann geaendert werden

string c = string ( "alpha" ) + string("beta");  
//weil "alpha" sonst nur n zeiger is zu dem du addierst

Das macht nix, weil es einen operator+( const char*, const string& ) gibt, den Volkard ja aufgelistet hat.
Also ist:

string c = "alpha" + string("beta");

equivalent zu:

string c( operator+( "alpha", string( "beta" ) ) );