ich habe ein kleines Prob. mit Klassen. Ich möchte ein Prog in dem ich mehrer Fahrzeuge verwalte, nun mein Problem. Wenn ich ein Kennzeichen (zb. a-aa 666) anlege und ein neues Objekt anlege wie kann ich dieses Objekt später ansprechen?

class automobil
{
   string zeichen;
   automobil(const string& z) : zeichen(z) {}
};

automobil a("a-aa 666");
string kennzeichen = a.zeichen;

[edit]
Klassenname geändert.
So besser. [edit]

class Auto{
      float kmAlt;
      float kmNeu;
      float lieter;
      float gefahren;
      float verbrauch;

      public:
....

]
im prinziep erst mal ne grundidee

class automobil
{
   string zeichen;
   automobil(const string& z) : zeichen(z) {}
};

alles 'private' *ggg*

@rest: wenn du ein objekt direkt anlegst, dann mit dem punkt 'object.member = ...'
solltest du mit 'new' arbeiten dann 'object->member = ...'

class Auto
{
  string kennz;
public:
  Auto(const string& k) : kennz(k) {}

  void set_kennz(const string& k) {kennz=k;}//nur wenn du der Meinung bist, das Kennzeichen nachträglich ändern zu wollen
  string get_kennz() { return kennz;}
};

(dieser Ansatz hat den Vorteil, daß du im Setter noch eine Fehlerkontrolle einbauen (oder ihn ganzweglassen) kannst)

wir wollen ja nicht, daß die freien attribute schneller sind.

const string &get_kennz() const { return kennz;}
string get_kennzKopie() const { return kennz;} //kopie kann auch nützlich sein

zum beispiel mit so einer funktion:

void test(const Auto &a) { cout << a.get_kennz() << endl; }

Schließlich kann man eine Kopie ja jederzeit mit

Auto a;
std::string sKennzeichen = a.get_kennz();

anlegen.

Sorry doppelmoppel, aber deine 2. Methode ist sinnlos!

stimmt. ich hatte eigentlich an folgendes szenario gedacht:

void test(string &s);
...
Auto a("bla");
test(a.get_kennzKopie());

aber referenzen auf nicht const sind ja mit temporaries verboten

test(a.get_kennzKopie()); ergibt keinen sinn, wenn test die kopie ändert.

es ergibt nur dann keinen sinn, wenn test nichts anderes macht, als die kopie zu ändern. es kann ja sein, dass test viele andere sinnvolle sachen macht, und die veränderung des parameters ignoriert werden darf.

Das nutzen von Seiteneffekten bedeutet jedoch sich mit undefinierten verhalten einzulassen, da sich die Implementierung von test jederzeit ändern kann.

Da ja aber keiner undefiniertes verhalten haben will (also keine Seiteneffekte) ist der Aufruf von test mit einer Kopie eines Wertes der gezeigten Art ohne effekt.

IMHO braucht man keine Methode in einer Klasse, wenn diese die internen Daten per const ref zurück liefert. Wird dennoch eine Kopie benötigt, so möge diese der Client der Klasse erzeugen. Dieser kann durch das Wissen wofür er diese benötigt viel effizienter/zielgerichteter anlegen.

test(a.getKennzKopie());
test(string(a.getKennz()));

auch ein netter vorschlag, damit kopiegetter nicht immer eingebaut werden müssen:

template<typename T>
T kopie(T const& t){
   return t;
}
test(kopie(a.getKennz()));

mann, bin ich heute wieder fantasievoll.

grrrr - hat er doch noch schnell nachgezählt

Die Signatur der Funktion sagt das sie für eine Modifikation des übergebenen Parameters zuständig ist. Die vielen anderen nützlichen Dinge wären Seiteneffekte.

Eine Funktion mit Rückgabetyp void, die Seiteneffekte verursacht; wer hätte das gedacht? Die Modifikation des übergebenen Parameters kann evtl. auch eine ignorierbare Log-Funktionalität darstellen.

Unter Seiteneffekt verstehe ich, das die Funktion Daten verändert die nicht offensichtlich sind.

void x::test(T & t)
{
   // Seiteneffekte
   intern_ganz_viel_am_internen_objekt_aendern();
   t += 2;
}

Und was wenn x::test nun davon ausgeht, das t wirklich geändert wurde ?

Drehen wir den Spieß doch mal um:

Nenne einen konkreten Fall in dem man einer Routine, die Werte ändert und deren Implementierung unbekannt ist, eine Kopie des zu ändernden Wertes übergeben sollte und warum dies kein Risiko betreffend undefinierten Verhaltens ist.

Ebenso wäre es interesannt Deine Sicht der Designentscheidung zu erfahren einer solchen Routine eine aufwendige und teure Kopie zu übergeben.

Mir fällt dazu nur das ausnutzen von Seiteneffekten (s.o.) zu verwenden und die eigentliche Aufgabe der Routine wegzuwerfen.

(Das es in der Praxis viele Routinen gibt die T & annehmen aber keine Änderung des Wertes vornehmen sei als bekannt hingestellt aber nicht als garantiert).

Ich lerne doch gerne was neues dazu - und bitte nich als Flame verstehen

(Das es in der Praxis viele Routinen gibt die T & annehmen aber keine Änderung des Wertes vornehmen sei als bekannt hingestellt aber nicht als garantiert).

nee, ist mir neu.

Na dann von mir aus auch T * und nen Blick in die WinApi oder so macher kommerziellen Lib, den Quellcode vom Cheffe .... In dem was zum stan**** gehört kann ich Dir keinen einzigen Fall nennen (weils den nich gibt oder ich mich nich auskenne mit C++)

in libs, die sooo alt sind, daß sie in c vor 1999 geschrieben wurden. da mögen T* vorkommen, wo T const* gemeint ist.

Unter Seiteneffekt verstehe ich, das die Funktion Daten verändert die nicht offensichtlich sind.

Auch jede Ausgabe ist ein Seiteneffekt obwohl sie die Daten nicht verändert.

in libs, die sooo alt sind, daß sie in c vor 1999 geschrieben wurden. da mögen T* vorkommen, wo T const* gemeint ist.

Naja, ein Blick in das .Net Framework 2.0 :

public: static int String::Compare (String^ strA, String^ strB);
public: bool String::Contains (String^ value);

(^ = managed Pointer)

Ok, die definition von Seitenefekten sollte ich mir noch mal ansehen, aber der Punkt "Warum kann es sinvoll sein eine Kopie zu übergeben um ein T & zu einem T zu machen" wäre für mich vom verständnis her noch offen.

Gerade wenn man Volkards ansprüche annimmt, das überall wo Nichts verändert wird T const(*|&|^|%) angesetzt wird erschliesst sich mir der Grund nicht und ich würde gerne diese Wissenslücke schliessen.

Gerade wenn man Volkards ansprüche annimmt, das überall wo Nichts verändert wird T const(*|&|^|%) angesetzt wird erschliesst sich mir der Grund nicht

Z.B. allein schon deswegen, damit dir der Compiler deinen Code um die Ohren haut,
wenn du versuchst, eine als const definierte Variable, einer Funktion
zu übergeben, die ihr Argument verändert.

void test(T &);
void test(T(value));

Also einer ändernden Funktion/Methode eine Kopie des Wertes zu übergeben, siehe ein paar Beiträge weiter vorne.

Z.B. allein schon deswegen, damit dir der Compiler deinen Code um die Ohren haut,
wenn du versuchst, eine als const definierte Variable, einer Funktion
zu übergeben, die ihr Argument verändert.

Ein Aufruf von

test(const_cast<T>(t));

verbessert die Situation von test nicht.

test(T(t));

mag das ganze zwar verbessern, aber mir erschliesst sich dennoch nicht, warum ich als Entwickler so etwas machen will - eine Kopie an eine Funktion zu übergeben deren Aufgabe die Wertänderung ist.

Die Antwort wären IMHO:

Nach standard garnicht, funktionen die eine solche Schnitstelle liefern werden immer einen Wert ändern und in diesem Falle ist es völlig sinnfrei eine Kopie zu übergeben - ausnutzen von Seiteneffekten ist tabu.

In der Praxís fällt mir nur eine Situation ein:

Die Implementierung test ist unbekannt bzw. garantiert nicht das der Wert nicht geändert wird und man hat sehr empfindliche Daten, die garantiert keine Änderung erfahren dürfen und an test übergegen werden müssen.

(Eigentlich die gleichen Gründe für einen const_cast ? Wobei der const_cast ja wiederum notwendig sein könnte um ein einer void test(T const&) const änderungen an membern zu machen !?)

Also, Diksussion führt zu nix, lasse mers