ADD_MEMBER-Macro, Meinung?

[Cyres]

Mir ist soeben ein Macro untergekommen, dass eine Membervariable einer Klasse hinzufügt, ich wollte dazu mal eure Meinung hören:

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

[MFK]

Inhaltlich sinnlos. Da kann man auch gleich public-Member anlegen.

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

[SeppJ]

Den gleichen Effekt erreiche ich einfacher, ohne Pseudo-Objektorientierung und ohne unerwartete Makroeffekte (dein Makro setzt zum Beispiel die Sichtbarkeit unerwartet auf public):

struct Foo
{
 std::string name;
};

[pumuckl]

Cyres schrieb:

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

[Cyres]

pumuckl schrieb:

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

[SeppJ]

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?

[Cyres]

SeppJ schrieb:

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.

[pumuckl]

Cyres schrieb:

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