Wie sollte der Standardkonstruktor für die Klasse Person aussehen?

camper schrieb:

Griese schrieb:

Bei mir hat eine jede Klasse einen std::string in der private-Sektion und die get-Funktionen geben immer schön einnen const char* zurück. Immer.

Begründung?

Wegen der Kompatibilität zu C. Hier ist std::string nicht mehr möglich, wenn die Funktionen ein (cost) char* erwarten.

Kompatibilität mit C in einer Memberfunktion? klingt nach Widerspruch

Nicht wenn ich Libraries benutze, die in C geschrieben worden sind. :p

Shade Of Mine

Griese schrieb:

Wegen der Kompatibilität zu C. Hier ist std::string nicht mehr möglich, wenn die Funktionen ein (cost) char* erwarten.

Dann ist std::string als internes Speichermedium auch falsch und man nimmt std::vector und verwendet es auch im Interface der Klasse.

Shade Of Mine schrieb:

Deine Gründe wären echt interessant.

Ja, wie gesagt, C-Bibliotheken sind mein Grund.

Shade Of Mine

Bibliothekar Griese schrieb:

Shade Of Mine schrieb:

Deine Gründe wären echt interessant.

Ja, wie gesagt, C-Bibliotheken sind mein Grund.

habe ich bereits entkräftet

Mecnels

interpreter schrieb:

@Mecnels: char* als Rückgabewert ist schlecht, weil so Benutzer der Klassen die internen Daten verändern können (ohne setter etc)
wenn schon char* (std::string ist besser), dann einen const char* zurückgeben.

Euch ist aber schon klar dass ich ihn eigentlich auf den prinzipiellen Fehler hinweisen wollte (char != char*). Jetzt wird's lustig:

class StrengGeheimeDaten{
 private:
 char* Name;
public:
 StrengGeheimeDaten(char*);
};

StrengGeheimeDaten TopSecret("Mecnels");

class AdAbsurdum{
 void* AllmaechtigerZeiger;
 ULONG SizeOfObject;

AdAbsurdum(StrengGeheimeDaten* SGD){
 AllmaechtigerZeiger=StrengGeheimeDaten;
 SizeOfObject=sizeof(*StrengGeheimeDaten);
 MessageBox(NULL,(char*)AllmaechtigerZeiger,"Ihr streng geheimer Name lautet",
      NULL);
}
};

AdAbsurdum(&TopSecret);

// So und wenn ihr gerafft habt, was hier geschieht, dann könnt ihr mir ja
// noch einmal etwas über interne Daten einer Klasse erzählen.

simon.phoenix

Bibliothekar Griese schrieb:

Shade Of Mine schrieb:

Deine Gründe wären echt interessant.

Ja, wie gesagt, C-Bibliotheken sind mein Grund.

Die Sache mit den C-Libs lässt sich mit einem vector umgehen.

Schnipsel aus aktuellem Projekt von mir...

void c_func(char* val);

template<class CharType>
std::vector<CharType> GetStringBuffer(const std::basic_string<CharType>& bufferSource){
    return std::vector<CharType>(bufferSource.begin(), bufferSource.end());
}

class Foo{
    public:
        std::string GetFoo() { return fooVar_; }
    private:
        std::string fooVar_;
};

int main(){
    Foo myFoo;
    std::vector fooBuf = GetStringBuffer<char>(myFoo.GetFoo());

    c_func(&fooBuf[0]);

   return 0;
}

edit: Wer exceptionsicheren Code schreiben will, sollte eh in aller Regel die Finger von Buffern lassen (ich behaupte das einfach mal aufgrund der Speicherleckproblematik; bei unserem Fall jedoch nicht zwangsläufig auftretend).

simon.phoenix

davie schrieb:

simon.phoenix schrieb:

Behalte deinen Mist doch für dich Mecnels

das geht auch weniger aggressiv. wir sind hier im c++ forum und nicht im trollforum;
argumentieren ohne kraftausdrücke ist doch viel lustiger

Sorry, du hast da sicher Recht.

Ich kann es aber überhaupt nicht leiden, wenn Leute (mecnels), die von sich behaupten, ja soooo erfahren zu sein (das bedeutet nicht, dass ich von mir behaupte erfahren zu sein(!) ), Sachen vom Stapel lassen, die schlichtweg sinnfrei sind .

Shade Of Mine

Mecnels schrieb:

// So und wenn ihr gerafft habt, was hier geschieht, dann könnt ihr mir ja
// noch einmal etwas über interne Daten einer Klasse erzählen.[/cpp]

Syntaxfehler.

Wenn wir die Fehler ausbessern haben wir trotzdem nur Käse da, denn es ist ein böser Hack, der undefiniertes Verhalten produziert.

Mecnels

simon.phoenix schrieb:

davie schrieb:

simon.phoenix schrieb:

Behalte deinen Mist doch für dich Mecnels

das geht auch weniger aggressiv. wir sind hier im c++ forum und nicht im trollforum;
argumentieren ohne kraftausdrücke ist doch viel lustiger

Sorry, du hast da sicher Recht.

Ich kann es aber überhaupt nicht leiden, wenn Leute (mecnels), die von sich behaupten, ja soooo erfahren zu sein (das bedeutet nicht, dass ich von mir behaupte erfahren zu sein(!) ), Sachen vom Stapel lassen, die schlichtweg sinnfrei sind .

Hey, ich weiß ja nicht, warum ich bei Dir so in Misskredit geraten bin, aber wenn Du wirklich glaubst, es gäbe so etwas wie Sicherheit vor dem Zugriff auf interne Daten und dann daraus schließt, höchstens const Zeiger darauf zurückgeben zu müssen, um Zugriff auf interne Daten auszuschließen, dann ist das schlicht Unsinn. Vergiss nicht, dass auch noch (void*) da ist. Der Zeiger kann potenziell nämlich alles.
Kleiner Tip von 'nem alten Sturkopf, auch mal selber die Rübe anzustrengen, bevor man mit (mir völlig unbegreiflichen) Schimpftiraden auf andere losgeht.

Shade Of Mine

Mecnels schrieb:

Hey, ich weiß ja nicht, warum ich bei Dir so in Misskredit geraten bin, aber wenn Du wirklich glaubst, es gäbe so etwas wie Sicherheit vor dem Zugriff auf interne Daten und dann daraus schließt, höchstens const Zeiger darauf zurückgeben zu müssen, um Zugriff auf interne Daten auszuschließen, dann ist das schlicht Unsinn.

Ne, das was du sagst ist Unsinn. Man kann sich gegen Fehler absichern, gegen mutwillige Zerstörung kann man natürlich nix machen, aber mit std::string hätte man einen guten Schritt getan. Denn dann _muss_ der Client den Code hacken um die Daten zu ändern.

Vergiss nicht, dass auch noch (void*) da ist. Der Zeiger kann potenziell nämlich alles.

Was kann denn void was andere Zeiger nicht können?

Und sag jetzt nicht "auf alles zeigen", das kann jeder Zeiger, nur dass man halt casten muss.

camper

Mecnels schrieb:

simon.phoenix schrieb:

davie schrieb:

simon.phoenix schrieb:

Behalte deinen Mist doch für dich Mecnels

das geht auch weniger aggressiv. wir sind hier im c++ forum und nicht im trollforum;
argumentieren ohne kraftausdrücke ist doch viel lustiger

Sorry, du hast da sicher Recht.

Ich kann es aber überhaupt nicht leiden, wenn Leute (mecnels), die von sich behaupten, ja soooo erfahren zu sein (das bedeutet nicht, dass ich von mir behaupte erfahren zu sein(!) ), Sachen vom Stapel lassen, die schlichtweg sinnfrei sind .

Hey, ich weiß ja nicht, warum ich bei Dir so in Misskredit geraten bin, aber wenn Du wirklich glaubst, es gäbe so etwas wie Sicherheit vor dem Zugriff auf interne Daten und dann daraus schließt, höchstens const Zeiger darauf zurückgeben zu müssen, um Zugriff auf interne Daten auszuschließen, dann ist das schlicht Unsinn. Vergiss nicht, dass auch noch (void*) da ist. Der Zeiger kann potenziell nämlich alles.
Kleiner Tip von 'nem alten Sturkopf, auch mal selber die Rübe anzustrengen, bevor man mit (mir völlig unbegreiflichen) Schimpftiraden auf andere losgeht.

richtig mecnels, weil man trotz angelegtem sicherheitsgurt bei einem unfall sterben kann, sollte man ihn besser gar nicht erst anlegen.

Mecnels

Shade Of Mine schrieb:

Mecnels schrieb:

// So und wenn ihr gerafft habt, was hier geschieht, dann könnt ihr mir ja
// noch einmal etwas über interne Daten einer Klasse erzählen.[/cpp]

Syntaxfehler.

Wenn wir die Fehler ausbessern haben wir trotzdem nur Käse da, denn es ist ein böser Hack, der undefiniertes Verhalten produziert.

Hab's auch nicht getestet, sondern nur mal schnell reingehackt, sollte aber klappen (void*) nimmt Adresse beliebigen Typs, die später (char*) explizit gecastet wird. Und schon spuckt Dir das Teil den streng geheimen Namen aus, weil die Ausgabefunktion auf char* trifft, die Adresse, die in den ersten vier Byte des Objekts TopSecret steckt, dereferenziert und die zugehörige Zeichenkette demzufolge ausgibt.

ES GING MIR DOCH NUR UM DIE VERANSCHAULICHUNG EINER TATSACHE, der man sich bewusst sein sollte, wenn man glaubt, mit private/protected seine internen Daten 100% ig schützen zu können.

Aber da erzähl ich Dir sicher nichts Neues, eher schon simon@phoenix.

Na, jedenfalls gute Nacht.

interpreter

Schwachsinn. Natürlich kann man seine internen Daten zu 100% schützen.

Hi interpreter,

schon mal was von einem Tool namens Debugger gehört.

simon.phoenix

Mecnels schrieb:

Aber da erzähl ich Dir sicher nichts Neues, eher schon simon@phoenix.

Du ziehst immer sehr schlagkräftige Beispiele heran. void* wird in C++ kaum mehr benötigt, wozu haben wir denn Templates (ich denke, von denen hast du noch nie was gehört)...?

class AdAbsurdum{
 void* AllmaechtigerZeiger;
 ULONG SizeOfObject;
 // ...

Jetzt fehlt noch das malloc!

interpreter

Redhead schrieb:

Hi interpreter,

schon mal was von einem Tool namens Debugger gehört.

Und?

Mecnels

Redhead schrieb:

Hi interpreter,

schon mal was von einem Tool namens Debugger gehört.

Trifft den Nagel auf den Kopf.

Shade Of Mine

Mecnels schrieb:

ES GING MIR DOCH NUR UM DIE VERANSCHAULICHUNG EINER TATSACHE, der man sich bewusst sein sollte, wenn man glaubt, mit private/protected seine internen Daten 100% ig schützen zu können.

Das ist natürlich blödsinn, sowas kann man nicht. Ist aber auch nicht der sinn von information hiding und kapselung.

denn damit will man nicht vor mißbrauch schützen, sondern vor fehlern.

davie

<ironie>
machen wir pimpl mit gettern/settern die rsa können? nur noch den schlüssel irgendwie verstecken ...

es geht einfach nur um den komfort. niemand, der mit code ordentlich arbeitet, kommt drauf, char const* oder von mir aus string const& manipulieren zu wollen. wenn das wer will, geht es auch irgendwie -- immer.
aber const correctnes ist wichtig.

http://www.gotw.ca/gotw/006.htm
wer das nicht liest, braucht gar nicht erst weiter zu programmieren

interpreter

Mecnels schrieb:

Redhead schrieb:

Hi interpreter,

schon mal was von einem Tool namens Debugger gehört.

Trifft den Nagel auf den Kopf.

Falsch. Es ging hier um den Zugriff auf interne Datenstrukturen im Code. Das ich per Debugger mir Strukturen anschauen kann hat damit nichts zu tun.