Verstehe diesen Konstruktor nicht

Pille456

Hi,
Was passiert in dem Code?

class feistel
{
 private:
    int laeufe;
    char key;
  //....
 public:
    feistel(unsigned char cryptkey,int durchlaeufe):key(cryptkey),laeufe(durchlaeufe)
    {
    }
  //...
}
int main()
{
  feistel test(10,5);
  //...
}

Ich weiss soviel, dass fesitel der Konstrukor der Klasse feistel ist und dass die Übergabeparameter in key und laeufe gespeichert werden, jedoch nicht warum

Der Code ist von www.cpp-world.de, was ja die Seite vom Forengenossen mikey ist - also wenn du über den Thread stolperst, was passiert da?

Alle anderen dürfen natürlich auch ihr Wissen mir mitteilen

BorisDieKlinge

die werte werden in der initialiseungs liste beim c-tor aufruf gesetzt:

feistel(unsigned char cryptkey,int durchlaeufe):
key(cryptkey),laeufe(durchlaeufe)
{
}

Simon2

Pille456 schrieb:

...

...
    char key;
 ...unsigned char cryptkey, ... key(cryptkey)....

...

Das ist natürlich nicht wirklich optimal...
Ansonsten hat Boris schon die "Initialisierungsliste" erwähnt.

Gruß,

Simon2.

Pille456

Ahh ok, habe verstanden^^
In Wahrheit ist "key" aus ein unsigned char, war nur faul zum schreiben

asc

Um noch etwas weiter zu gehen:

Wenn du einen Konstruktor in der folgenden Form benutzt:

Klasse::Klasse()
{
  Membervariable = Wert;
}

Bedeutet dies das folgendes gemacht wird:
a) Der Standardkonstruktor der Membervariable wird aufgerufen
b) Eine Wertzuweisung wird durchgeführt

Wenn du statt dessen über die Initialisierungsliste gehst:

Klasse::Klasse()
: Membervariable(Wert)
{
}

Bedeutet dies das folgendes gemacht wird:
a) Der Konstruktor der Membervariable mit dem aufruf über Wert wird durchgeführt

Sprich: Letzteres ist schon mal etwas effektiver. Zudem gehen bestimmte Sachen auch nur mittels der Initialisierungsliste. z.B. die Initialisierung konstanter Membervariablen...

Natürlich gibt es wieder einen Harken bei der Sache: Die Reihenfolge der Deklaration ist für die Initialisierungsliste wichtig, wenn du innerhalb der Initialisierungsliste schon auf Member zugreifst (z.B. wenn du einen mit den Wert eines anderen initialisieren willst). Den unabhängig von der Reihenfolge wie sie in der Initialisierungsliste aufgeführt werden, erfolgt die Initialisierung in Reihenfolge der Deklaration.

cu André

queer_boy

standardtext:

drei dinge beachten bei elementinitialisierungslisten:
1. verwende sie immer, außer es ist nicht erlaubt (z.b. mit arrays)
2. achte immer darauf, dass die reihenfolge der elemente in der elementinitialisierungsliste die reihenfolge ihrer deklaration in der klasse ist
3. bei virtuellen basisklassen muss die unterste klasse in der hierarchie den konstruktor der virtuellen basisklasse aufrufen

dann bist du sicher

inp

Pille456 schrieb:

Hi,
Was passiert in dem Code?
class feistel
{
 private:
    int laeufe;
    char key;
  //....
 public:
    feistel(unsigned char cryptkey,int durchlaeufe):key(cryptkey),laeufe(durchlaeufe)
    {
    }
  //...
}
int main()
{
  feistel test(10,5);
  //...
}
Ich weiss soviel, dass fesitel der Konstrukor der Klasse feistel ist und dass die Übergabeparameter in key und laeufe gespeichert werden, jedoch nicht warum

Der Code ist von www.cpp-world.de, was ja die Seite vom Forengenossen mikey ist - also wenn du über den Thread stolperst, was passiert da?

Alle anderen dürfen natürlich auch ihr Wissen mir mitteilen

[cpp]
class feistel
{
 private:
    char key;
    int laeufe;
  //....
 public:
    feistel(char cryptkey, int durchlaeufe):
        key(cryptkey), laeufe(durchlaeufe)
    {
    }
  //...
}

wäre standardkonform, die reinfolge der parameter der initialisierungsliste sollte gleich mit der reinfolge der deklaration sein.

CStoll

inp schrieb:

wäre standardkonform, die reinfolge der parameter der initialisierungsliste sollte gleich mit der reinfolge der deklaration sein.

Das ist eine Empfehlung, aber nicht zwingend vorgeschrieben. Du kannst die Member in beliebiger Reihenfolge in der Initialisierungsliste aufzählen.

Die Reihenfolge, in der die Member tatsächlich initialisiert werden, ist vom Standard vorgegeben (erst virtuelle Basisklassen, dann direkte Basisklassen und schließlich eigene Member, jeweils in der Reihenfolge, wie sie in der Deklaration auftauchen) und stimmt deshalb nicht unbedingt mit der angegebenen Reihenfolge überein. Aber das führt höchstens dann zu Problemen, wenn die einzelnen Elemente sich aufeinander beziehen.

inp

CStoll schrieb:

inp schrieb:

wäre standardkonform, die reinfolge der parameter der initialisierungsliste sollte gleich mit der reinfolge der deklaration sein.

Das ist eine Empfehlung, aber nicht zwingend vorgeschrieben. Du kannst die Member in beliebiger Reihenfolge in der Initialisierungsliste aufzählen.

Die Reihenfolge, in der die Member tatsächlich initialisiert werden, ist vom Standard vorgegeben (erst virtuelle Basisklassen, dann direkte Basisklassen und schließlich eigene Member, jeweils in der Reihenfolge, wie sie in der Deklaration auftauchen) und stimmt deshalb nicht unbedingt mit der angegebenen Reihenfolge überein. Aber das führt höchstens dann zu Problemen, wenn die einzelnen Elemente sich aufeinander beziehen.

hmmh, hatte mal n fall wo die reinfolge geändert werden musste (msvc 2005)
weil 2 pointer member mit falschen typen initialisiert worden sind.
das hat mich damals davon überzeugt.

ty für die info, muss jetzt mal im standard genauer nachlesen

CStoll

Der Vorteil, wenn du es in der "richtigen" Reihenfolge einträgst, ist einfach, daß du mögliche Fehler leichter siehst:

class String
{
  char* data;
  size_t field_size;
public:
  String(char* src)
  : field_size(strlen(src)+1)
  , data(new char[field_size])
  {
    strcpy(data,src);
  }
  ...
};

Auch wenn es anders aussieht, wird von diesem Ctor erst data initialisiert und danach field_size - ergo legst du dir hier ein char-Array undefinierter Größe an, was vermutlich nicht im Sinne des Erfinders ist. Wenn der Autor dieser Klasse auf die Reihenfolge geachtet hätte, wäre ihm das vermutlich nicht passiert.