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

[davie]

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

[interpreter]

Aber leider nicht immer möglich.

Dann nenn mir mal ein paar Szenarien, wo es NICHT möglich ist.

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?

Warum soll std::string noch mal besser als Rückgabewert sein...?

Habe ich nie behauptet. Ich sagte std::string ist besser als char* in diesem Fall. Die Begründung ist zu offensichtlich, als dass ich sie angeben müsste.

[Griese]

interpreter schrieb:

Aber leider nicht immer möglich.

Dann nenn mir mal ein paar Szenarien, wo es NICHT möglich ist.

Sorry, ich hab schlecht zitiert. Wollte bis auf "std::string ist besser" alles aus dem Zitat raushauen.

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.

[Shade Of Mine]

Griese schrieb:

Aber leider nicht immer möglich. 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.

Sinnlose Performance einbußen? Der Grund dafür würde mich mal interessieren.

Warum soll std::string noch mal besser als Rückgabewert sein...?

Weil es schneller ist cooler Grund gell.
Außerdem verwendet man in C++ keine rohen Zeiger, deshalb kann man mit char* nix anfangen und muss sowieso wieder in ein string Objekt kopieren. Das ist doof.

Deine Gründe wären echt interessant.

[camper]

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 und wenn du doch mal nen C-string brauchst gibts da noch c_str()

[Griese]

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.

[Bibliothekar Griese]

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.

[Redhead]

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!