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

[interpreter]

#include <iostream> 
#include <string>

class Person { 
private:                      // protected ist fast immer Quatsch
    std::string name;
    std::string forename;
    int age;                

public: 
   Person(const std::string& name_, const std::string& forename_, int age_):name(name_),
                                                                             forename(forename_),
                                                                             age(age_) { }
   std::string getName() const { return name; } 
   std::string getForename() const { return forename; } // getVorname => Deutsch-Englisch-Mischung vermeiden
   int getAge() const { return age; }
};

Wegen Faulheit alles inline...

[Zentaur]

Wow gleich 2 Antworten auf einmal, ich werde sie mal studieren.
Ich wollte erst einmal ausprobieren, ob es mit char-Feldern geht, anschließend nach und nach strings einbauen, aus Dateien lesen, etc. Das mit den Underscore wusste ich nicht.

Danke für die Antworten

Gruss

[Zentaur]

Wow gleich 2 Antworten auf einmal, ich werde sie mal studieren.
Ich wollte erst einmal ausprobieren, ob es mit char-Feldern geht, anschließend nach und nach strings einbauen, aus Dateien lesen, etc. Das mit den Underscore wusste ich nicht.

Danke für die Antworten

Gruss

[Mecnels]

Zentaur schrieb:

Hallo,
ich versuche mich an meiner ersten Klasse und komme mit einigen Sachen nicht ganz zurecht.
Kann mir jemand sagen, wie ich den Konstruktor und Destruktor machen soll?

[cpp]
#ifndef _Person_h
#define _Person_h

class Person { // Na dann wollen wir mal

protected:
char name[32];
char vorname[32];
int alter;

public:
// Den machen wir besser gleich hier
Person():name(NULL),vorname(NULL),alter(0) {}
// Hier weiss ich schon nicht wie das geht

char***** getname(); // unten dann, aber wär auch gut, wenn das Zeugs
// irgendwie in das Objekt hineingelangen würde,
// machst Du eben ein paar Set-Methödchen dazu

char***** getvorname();
int getalter**()**;
~Person(); // wozu? Deine Arrays haben ja eine fixe Größe,
// also brauchst auch keinen Speicher eigenhändig
// freigeben
};

#endif
[/cpp]

[cpp]

#include<iostream> // grrrr...

using namespace std;

/* Zum Kommentar degradiert, haben wir schon
Person::Person() { //genauso hier
}
*/

char***** Person::getname() { // Genauigkeit schadet nicht char*,
// nicht nur char
return name;
}

char***** Person::getvorname() { // OK
return vorname;
}

int Person::getalter() { // OK
return alter;
}

/* nicht nötig, solange da char name**[32]** steht
Person::~Person() {}
Auch zum Kommentar degradiert, bis auf weiteres */

/* Irgendwie vertüge das Ding auch noch ein paar Konstruktoren oder
Funktionen zum Einlesen der Daten. Außerdem char* ist vielleicht
auch sinnvoller als char[32], aber was Du mit Deiner Klasse
anstellen willst weißt Du besser.*/

[/cpp]

der Aufruf in der main wäre wohl, wenn ich mich nicht täusche:

#include <iostream>

using namespace std;

int main () {

	Person a; 
	a.getname(); // Da kommt jetzt NULL retour, denk Dir
                   // ein paar bessere Konstruktoren aus
return 0;
}

Gruss

Ebenfalls Gruß.

[simon.phoenix]

Behalte deinen Mist doch für dich Mecnels

Immer schön Handles auf interne Daten liefern, genau wie Meyers es sagt

...

[interpreter]

@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.

[Griese]

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.

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. Immer. Warum soll std::string noch mal besser als Rückgabewert sein...?

[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.