#define ADD_MEMBER(TYPE, NAME) \
private: \
	TYPE NAME##_; \
public: \
	const TYPE& NAME() const {return NAME##_;} \
	void NAME(const TYPE& NAME) {NAME##_ = NAME;}

// In Anwendung dann: 

#include <iostream>

class NamedObject {
    ADD_MEMBER(std::string, name)
};

int main() {
    NamedObject obj;
    obj.name("Foo");
    std::cout << obj.name() << std::endl;
}

Handwerklich fragwürdig, da es den Zugriffsspezifizierer ändert. Was danach steht, ist public, egal, was davor steht.

struct Foo
{
 std::string name;
};

Mir ist soeben ein Macro untergekommen,

"Untergekommen"? Eingefallen oder irgendwo im Netz oder Literatur über den Weg gelaufen?

• Eingefallen: Schnell vergessen
• Netz: Nicht jeden Scheiß für voll nehmen, der im Netz steht
• Literatur: Rundablage...

Netz: Nicht jeden Scheiß für voll nehmen, der im Netz steht

Ebendrum habe ich nochmal nachgehakt, weil es einfach viel zu wenig guten Code im Internet gibt, den großen Nachteil mit dem public sehe ich selber
Danke jedenfalls für die Antworten.

PS.: Ich bin froh, dass ich keine Literatur als (Hardware-)PDF habe, die mit Macros umsich schmeißt

Ebendrum habe ich nochmal nachgehakt, weil es einfach viel zu wenig guten Code im Internet gibt, den großen Nachteil mit dem public sehe ich selber

Siehst du denn auch den anderen großen (größeren?) Nachteil, also den designerischen, jeden Member automatisch mit Getter und Setter auszustatten?

Cyres schrieb:

Ebendrum habe ich nochmal nachgehakt, weil es einfach viel zu wenig guten Code im Internet gibt, den großen Nachteil mit dem public sehe ich selber

Siehst du denn auch den anderen großen (größeren?) Nachteil, also den designerischen, jeden Member automatisch mit Getter und Setter auszustatten?

Ich weiß, dass wir die Disskussion vor einigerzeit schonmal hatten, weiß aber nicht, ob du daran beteiligt warst (ich gehe mal von aus). Ich bin der Meinung, man sollte nicht jeden kleinen Mist mit Gettern und Settern versehen, sie bringen aber eine Durchgängigkeit ins Projekt. Bei Containerklassen wie zum Beispiel Size oder Point sind Getter/Setter total überflüssig und stören sogar den Lesefluss. Dazu kommt, wenn man nicht gerade einen Getter wie operator[] hat, dann fehlen einem die Inc/Decrementoren und die Verknüften Zuweisungsoperatoren, was einen gravierenden Nachteil zur Folge hat.
Ein sehr guter Vorteil von Gettern und Settern sind der gekapselte Zugriff auf interne Daten, d.h. man kann (gerade bei längerfristigen Projekten) interne Strukturen verändern, ohne das sich eine Schnittstelle nach außen verändert, höchstens ergänzt wird. Ebenso kann man Funktionalitäten wie notifies etc. hinzufügen, da ist natürlich wieder der Anwendungsfall entscheident.

Resume: Getter und Setter sind Abhängig von der Anwendung gut oder schlecht. Für nicht-Containerklassen sind sie häufiger zu gebrauchen als für Containerklassen, im großen und ganzen kann man nicht global für oder gegen sie sprechen.

Resume: Getter und Setter sind Abhängig von der Anwendung gut oder schlecht.

Eben. Und damit sind die pauschalen Standard-Getter/Setter des Makros einfach nur Schwachsinn