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

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

[otze]

Mecnels schrieb:

//*snip*
// 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.

du weist, dass jeder compiler mit den klassen und den darin enthaltenen variablen machen kann, was er will, und dein code auf dem einen compiler funktionieren könnte, und auf keinem anderen sonst?

[Mecnels]

davie schrieb:

<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

Natürlich ist const correctnes wichtig. Aber sollte doch sehr gut überlegt sein, und bei dem Beispielklässchen des Threadstarters, das nur zu Übungszwecken geschrieben wurde, ???

templates = unendlich viel und zugleich nichts. Das gute alte Überladen einer Funktion, nur - bevor man überhaupt weiß, ob man sie jemals benötigt.

template<class Irgendetwas>
Irgendetwas MachEtwasMit(Irgendetwas,Irgendetwas){
 return f(IrgendEtwas,g(IrgendEtwas));
}
// Dann setz ich das Ding irgendwo in einem konkreten Fall
// ein und komm dahinter es haette eigentlich
// im konkreten Fall so heißen sollen:

template<class Irgendetwas, class IrgendetwasAnderes>
IrgendeteasAnderes MachEtwasMit(Irgendetwas,IrgendetwasAnderes){...
 // und so weiter, ich hab die Bezeichner nicht zufällig so gewählt,
 // aber es veranschaulicht ganz gut = unendlich viel und zugleich nichts.
 // Das gute alte Überladen einer Funktion SOBALD MAN SIE BRAUCHT
 // ist doch ein bisschen praxisnäher und konkreter, mal ehrlich?
 // Trotzdem nehm ich sie auch manchmal her, wenn ich sie nicht selber
 // machen muss, aber hab dann irgendwie ein schlechtes Gewissen,
 // weil ich mich dann schon wieder mehr als Konsument denn als
 // Produzent sehe, und das Produzieren können ist eben mir der Grund,
 // warum ich mich nach 24 Jahren in der Branche immer wieder aufs Neue
 // motivieren kann.

// Jetzt bin ich wahrscheinlich wieder der unverbesserliche alte Sturkopf

Schönen Abend noch.

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

Du hast dich soeben meiner Party angeschlossen.

const char* klasse::f() const { return string.c_str(); }

[Griese]

Shade Of Mine schrieb:

habe ich bereits entkräftet

Du meinst vermutlich das, was simon.phoenix geschrieben hat?

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;
}

Das sieht ja höchst ineffektiv aus. Und wie viel da kopiert und erzeugt wird...

Warum soll das jetzt besser als das Rückgeben eines const char*s sein? Bitte um Aufklärung, habe einen möglichen Nachteil des Rückgabetyps const char* nämlich noch nicht entdeckt.

[Shade Of Mine]

Mecnels schrieb:

Natürlich ist const correctnes wichtig. Aber sollte doch sehr gut überlegt sein, und bei dem Beispielklässchen des Threadstarters, das nur zu Übungszwecken geschrieben wurde, ???

Klar, gerade Anfänger sollten nichts richtig machen.

// Dann setz ich das Ding irgendwo in einem konkreten Fall
// ein und komm dahinter es haette eigentlich
// im konkreten Fall so heißen sollen:

Ja, wenn man zu blöd ist eine Funktion richtig zu designen, dann helfen nichtmal Templates. Aber das ist kein Templates problem, sondern ein Designproblem.

[davie]

Mecnels schrieb:

Natürlich ist const correctnes wichtig. Aber sollte doch sehr gut überlegt sein, und bei dem Beispielklässchen des Threadstarters, das nur zu Übungszwecken geschrieben wurde, ???

lieber von anfang an richtig, als irgendwann dazugelernt und dann alles verwechseln je öfter man const correct ist, desto leichter fällt es (und desto schlimmer sieht es aus, wenn man nicht const-correcten code liest )

templates = unendlich viel und zugleich nichts. Das gute alte Überladen einer Funktion, nur - bevor man überhaupt weiß, ob man sie jemals benötigt.

naja, template-metaprogrammierung ist auch eine feine sache

// Das gute alte Überladen einer Funktion SOBALD MAN SIE BRAUCHT
// ist doch ein bisschen praxisnäher und konkreter, mal ehrlich?

in dem fall sind templates eher dazu da, dass man eine funktion nicht zehnmal überladen muss, bis man draufkommt, dass alle gleich implementiert sind und sich nur der code leicht ändert.
man kann ein thema einfach nicht breit genug treten

// Trotzdem nehm ich sie auch manchmal her, wenn ich sie nicht selber
// machen muss, aber hab dann irgendwie ein schlechtes Gewissen,
// weil ich mich dann schon wieder mehr als Konsument denn als
// Produzent sehe, und das Produzieren können ist eben mir der Grund,
// warum ich mich nach 24 Jahren in der Branche immer wieder aufs Neue
// motivieren kann.

mit "sie" meinst du templates? irgendwann muss man halt auch nutzen aus fremden code ziehen und konsumieren und weiterverarbeiten kann auch lustig sein.

und aus dem abend wurde nacht

[Shade Of Mine]

Griese schrieb:

Du meinst vermutlich das, was simon.phoenix geschrieben hat?
[cpp]void c_func(char* val);

Nein. Man nimmt konsequent vector statt string und sonst nix.

Manchmal ist ein Wrapper um vector nicht schlecht, damit es sich besser anfühlt. Aber sicher kein "GetBuffer()" oder so ähnlich. Einfach nen normalen String nehmen, der kompatibel zu der C API ist.

[otze]

@mecnels schau dir mal so algorithmen wie std::sort sd::copy std::find usw an, die sind alle template basiert, und funktionieren mit jedem iterator, der den anforderungen genügt(eigentlich gehen die funktionen sogar noch weiter, indem sie sich auf verschiedene iteratortypen einstellen können)

//edit

naja, template-metaprogrammierung ist auch eine feine sache

full ack

templates sind richtig eingesetzt einfach zu mächtig, als das man sie wegschieben könnte(ich sag dazu nur komplett zur compiletime ausgerechnete sinus/cosinus/tangens lookuptables)

[camper]

Edit: müll

[simon.phoenix]

Griese schrieb:

Shade Of Mine schrieb:

habe ich bereits entkräftet

Du meinst vermutlich das, was simon.phoenix geschrieben hat?

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;
}

Das sieht ja höchst ineffektiv aus. Und wie viel da kopiert und erzeugt wird...

Warum soll das jetzt besser als das Rückgeben eines const char*s sein? Bitte um Aufklärung, habe einen möglichen Nachteil des Rückgabetyps const char* nämlich noch nicht entdeckt.

Da hast du schon recht. Aber C-Funktionen erwarten sehr häufig char* und nicht const char*.

[Griese]

simon.phoenix schrieb:

Griese schrieb:

Shade Of Mine schrieb:

habe ich bereits entkräftet

Du meinst vermutlich das, was simon.phoenix geschrieben hat?

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;
}

Das sieht ja höchst ineffektiv aus. Und wie viel da kopiert und erzeugt wird...

Warum soll das jetzt besser als das Rückgeben eines const char*s sein? Bitte um Aufklärung, habe einen möglichen Nachteil des Rückgabetyps const char* nämlich noch nicht entdeckt.

Da hast du schon recht. Aber C-Funktionen erwarten sehr häufig char* und nicht const char*.

const_cast

[Griese]

Ferner gibt's für jene, die ein char* erwarten, einen Ersatz in C++. Ich reden von nicht von solchem Schnickschnack wie strcpy() usw., sondern von solchen C-Funktionen, die schon ein const char* erwarten und auf dieser Basis viel Arbeit erledigen.

[interpreter]

const_cast ist pfui

[Griese]

interpreter schrieb:

const_cast ist pfui

Anstelle der Funktionen, die ein char* erwarten, benutze ich lieber die Stringmanipulation von std::string und ein const_cast findet sich in keinem meiner Programme.

War lediglich eine Alternative zu dem Code von simon.

[Griese]

Vielleicht habe ich mich gestern nicht deutlich genug ausgedrückt, aber ich habe keinen Plan, wie man das mit einem std::vector umgehen sollte. Würde mich echt interessieren, Beispiel-Code zu sehen. Hat jemand was?

Griese schrieb:

Bitte um Aufklärung, habe einen möglichen Nachteil des Rückgabetyps const char* nämlich noch nicht entdeckt.

Daran hat sich übrigens immer noch nichts geändert. Ihr widersprecht mir doch die ganze Zeit, den als Rückgabetyp zu benutzen. Warum?

[simon.phoenix]

Griese schrieb:

Vielleicht habe ich mich gestern nicht deutlich genug ausgedrückt, aber ich habe keinen Plan, wie man das mit einem std::vector umgehen sollte. Würde mich echt interessieren, Beispiel-Code zu sehen. Hat jemand was?

Griese schrieb:

Bitte um Aufklärung, habe einen möglichen Nachteil des Rückgabetyps const char* nämlich noch nicht entdeckt.

Daran hat sich übrigens immer noch nichts geändert. Ihr widersprecht mir doch die ganze Zeit, den als Rückgabetyp zu benutzen. Warum?

const char* als Rückgabetyp ist imho sehr nervig, wenn man was stack-generiertes returnen will (bestes beispiel imho const char* std::exception::what()):

const char* foo::what(){
    std::string errorInf;
    GenerateMyError(errorInf);
    return errorInf.c_str(); // Es wird dann auf einen nicht mehr existenten Zeiger gezeigt
}

Deshalb std::string >>>> const char* :p

[Shade Of Mine]

Griese schrieb:

Ferner gibt's für jene, die ein char* erwarten, einen Ersatz in C++. Ich reden von nicht von solchem Schnickschnack wie strcpy() usw., sondern von solchen C-Funktionen, die schon ein const char* erwarten und auf dieser Basis viel Arbeit erledigen.

std::vector

Vielleicht habe ich mich gestern nicht deutlich genug ausgedrückt, aber ich habe keinen Plan, wie man das mit einem std::vector umgehen sollte. Würde mich echt interessieren, Beispiel-Code zu sehen. Hat jemand was?

std::vector<char> vec;
vec.resize(1024);
GetStringFormSomewhere(&vec[0], vec.size());

Daran hat sich übrigens immer noch nichts geändert. Ihr widersprecht mir doch die ganze Zeit, den als Rückgabetyp zu benutzen. Warum?

Wenn du intern einen std::string hast, kannst du _nur_ char const* nach außen geben. Das bringt dir oft nichts, weil du damit keine vernünftigen setter hast.

denn ein

char buffer[1024];
GetStringFromSomewhere(buffer, sizeof(buffer));
obj.set(buffer);

suckt doch, oder?

Weiters ist die manipulation von rohen zeigern fehleranfällig, sollte also vermieden werden.

und es ist langsamer (weil unnötig kopiert wird) im gegensatz zu std::vector

[Guest352342]

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

Du bist ja wohl einer von der ganz 1337en Sorte ..

Ich kann natürlich dem Compiler und dem Standard den Kampf
ansagen und solch miese Hacks hernehmen ..

Ich könnte natürlich einfach die Header-Datei hernehmen und
das private durch public ersetzen. So .. schreib mir doch jetzt
bitte einen C++-Header der sich selbst gegen sowas schützt, danke.

Ts, .. "angeblich" bereits 24 Jahre in der Branche und wohl noch
kein einziges vernünftiges Buch vor der Nase gehabt ..

[finix]

Guest352342 schrieb:

Ich könnte natürlich einfach die Header-Datei hernehmen und
das private durch public ersetzen.

Und dann?