Welches der beiden Deklarationen ist mehr C++ Standard bzw. besser:

1:
class Mensch
{
char vorname[20];
char name[20];
unsigned int alter;
char geschlecht;

void set_vorname(const char *);
void set_name(const char *);
void set_alter(unsigned int);
void set_geschlecht(char);
};

oder
2:
class Mensch
{
char vorname[20];
char name[20];
unsigned int alter;
char geschlecht;

void set_vorname(const char *vorname);
void set_name(const char *name);
void set_alter(unsigned int alter);
void set_geschlecht(char geschlecht);
};

lg

Zweitens: Gute C++ Programmierer verwenden keine nackten char-Arrays und -Zeiger, sondern std::string. Und private Setter sind imho unnötig.

Drittens: sfds

...Und private Setter sind imho unnötigSyntaxcoloring:

Ok, private Methoden bringen mir in diesem Fall tatsächlich nichts. Aber wenn ich die Methoden public mache, dann ist es doch gut oder? Besser, als auf die Eigenschaften direkt (public) zuzugreifen.
--> Zweite Frage:
Wenn ich die Methoden nicht explizit public mache, dann kann ich doch nicht auf die Methoden von außen zugreifen oder? Da sie dann private sind.

lg

Besser, als auf die Eigenschaften direkt (public) zuzugreifen.

Sehr schöne Frage

Jeffson schrieb:

Wenn ich die Methoden nicht explizit public mache, dann kann ich doch nicht auf die Methoden von außen zugreifen oder?

Jop.

Jeffson schrieb:

--> Zweite Frage:
Wenn ich die Methoden nicht explizit public mache, dann kann ich doch nicht auf die Methoden von außen zugreifen oder? Da sie dann private sind.

lg

Ja, solange du in der class keine anderen Sichtbarkeitsmodifikationen angegeben hast, sind die Member privat und damit von außen nicht verwendbar (abgesehen von friends und einigen illegalen Präprozessor-Tricks).

Ja, wenn du die Methoden public setzt, bringen sie etwas. Allerdings wirst du beim Thema Getter/Setter hier auf geteiltes Echo stoßen ...

Hast du einen besseren Vorschlag? Her damit

lg

Ok, private Methoden bringen mir in diesem Fall tatsächlich nichts. Aber wenn ich die Methoden public mache, dann ist es doch gut oder? Besser, als auf die Eigenschaften direkt (public) zuzugreifen.

Das kommt ganz da drauf an, was die Methoden machen.

--> Zweite Frage:
Wenn ich die Methoden nicht explizit public mache, dann kann ich doch nicht auf die Methoden von außen zugreifen oder? Da sie dann private sind.

Ja, bei class ist die Defaultsichtbarkeit (d.h. wenn man nichts angibt) private, bei structs ist sie public. Das ist übrigens der einzige (technische) Unterschied zwischen class und struct.

edit: Oje, da war ich viel zu langsam. Sollte mal die Threadansicht aktualisieren, bevor ich antworte.

Ja, bei class ist die Defaultsichtbarkeit (d.h. wenn man nichts angibt) private, bei structs ist sie public. Das ist übrigens der einzige (technische) Unterschied zwischen class und struct.

Deswegen passt class auch viel besser ins OOP-Schema.

Aus Sicht eines Verwenders der Klasse würde ich die erste bevorzugen.

Echt? Parameterlisten ohne Parameternamen?
Sag das nochmal.

Hast du einen besseren Vorschlag? Her damit

Statt

char vorname[20];
void set_vorname(const char *vorname)
{
   if(strlen(this->vorname)>=20)
      throw std::wtf_exception("name too long");
   strcpy(vorname,this->vorname);
}

kann man auch

std::string vorname;

machen.

Was noch die Frage sein wird, ist, ob man einen öffentlichen setter haben mag(, um ungültige Namen herauszufiltern,) oder lieber keinen haben will und stattdessen nur einen Namensprüfer und im Kostruktor den Namen verlangt und damit echten Schreibschutz durchsetzt.

CStoll schrieb:

Aus Sicht eines Verwenders der Klasse würde ich die erste bevorzugen.

Echt? Parameterlisten ohne Parameternamen?
Sag das nochmal.

Klar doch - das bietet mir mehr Raum ür Interpretationen

Nein ernsthaft: Du hast mich erwischt, ich meinte natürlich die andere Variante.

C++ kennt keine Methoden, nur Memberfunktionen!

Doch, das sind auch Methoden.

Dieses Beispiel kann es nicht geben. C++ hat keine Methoden, genauso wie andere Sprachen keine Memberfunktionen haben.

Aus welchem Buch hast Du das? (Für die Blacklist)

Edit: Yay, gefunden! Klick

Ich suche mal den Artikel, kleinen Moment.

Edit: Yay, gefunden! Klick

Er redet irre. Gibt es eigentlich static member functions, also member functions, die keinen geheimen this-Pointer übergeben bekommen? Sind das danbn Methoden?

Es ist nicht notwendig, ein neues Wort zu erfinden, nur um auf ein Implementierungsdetail von C++ hinzuweisen, zumal genau dieses Detail im Standard nicht garantiert wird und C++-Member-Functions innendrin doch genauso funktionieren könnten wie Methoden in Eiffel oder Java.

Leider spricht er englich, das macht ihn unglaublich glaubwürdig.
Daher kopiere ich mal den ersten commment:

First of all. After compilation all code is transformed into assembly, which is raw machine code with no human-friendly structure.

That said, why are you looking at the implementation of the concept after we hit the "compile" button?

In my opinion, you're clearly confusing the OO concept, with the way it is implemented.

The concept of a property is a characteristic of an object. A method, is simply it's action. In what sense member function are not methods and data members are not properties?

Ok, we do have more fancy implemetations in other languages, but their implementations mostly implement syntax suggars, optimization techniques or even have other concerns like reflection support.

This remember me a classical question my teacher asked me in the computer science course, several years ago: "What is the difference between polymorphism and virtual methods?"

C++ kennt keine Methoden, nur Memberfunktionen!

Keine Methoden im Sinne von irgendwelchen abstrakt gehaltenen Definitionen einzelner Autoren von Büchern über OOP-Konzepte. Was im hiesigen Kontext völlig irrelevant ist. Du darfst es dir so vorstellen, dass im C++-Kontext die allgemein anerkannte Definition der C++-Community (Methode = Memberfunktion) mehr wiegt als die von irgendwelchen provokanten Artikeln, die du in der letzten Woche gelesen hast. Natürlich weißt du das, ich geh mal davon aus, dass du nicht ganz so ignorant bist, wie du dich manchmal gibst, sondern wie üblich nur provozieren möchtest.
Deshalb bitte back to topic.