namespace vis {

    // Variante A
    class Size;

    class Widget {
    public:
        void SetSize( const Size& );
        Size GetSize() const;
    };

    // Variante B
    class size;

    class Widget {
    public:
        void Size( const size& );
        size Size() const;
    };

    //Variante C
    class Size;

    class Widget {
    public:
        void Size( const vis::Size& );
        vis::Size Size() const;
    };
}

Nun machen in der letzten Variante natürlich die Namespace-Spezifizierer die Sache etwas "unübersichtlicher". Dennoch würde ich sie im Moment bevorzugen, weil sie einfach immer funktioniert, genau wie die Get- und Set-Methoden. Was sagt ihr? Gibt es vielleicht noch andere Wege?

Viele Grüße,
Deci

// Variante B2
    class Size;

    class Widget {
    public:
        void size( const Size& );
        Size size() const;
    };

Aber irgendwie hab ich das Problem nie.

Wenn man nun die beiden Klassen Size und Widget hat, dann könnte man ja zuersteinmal auf den Gedanken kommen, der Klasse Widget die Methoden SetSize und GetSize zu verpassen. Ich bin es allerdings irgendwie inzwischen Leid geworden, da gesondert zu entscheiden. Also könnte ich ja auch verschiedene Überladungen der Methode Size bei Widget deklarieren.

Ich persönlich sehe bei "Set" und "Get" schneller, was getan wird, ausserdem bleibe ich der Linie "beschreibe Funktionen als Verben" etwas treuer

Demnach würde ich zu Variante A tendieren. Wobei du dir auch überlegen sollst, ob die Setter/Getter wirklich immer notwendig sind. Wenn man damit nur immer eine Aktion durchführt, kann man vielleicht auch eine spezialisierte Methode anbieten. Oder du nimmst zur Abwechslung Bezeichner wie "Resize", was aber schnell mal inkonsistent wird. Gerade wenn man anfängt, "Move" statt "SetPosition" zu verwenden, übertrifft die Verwirrung so langsam den Nutzen.

template< typename T > class Accessor { /* ... */ };

class Size;

class Widget {
public:
     Accessor<vis::Size> Size;

private:
     vis::Size size_;
};

,
könnte man sozusagen auf diese Eigenschaft so zugreifen, wie ich mir das - zumindest im ersten Moment - eigentlich vorstellen würde:

Widget some;
some.Size = vis::Size(10,10);
vis::Size someSize = some.Size;

Wobei der Accessor dann entweder Direktzugriff macht, oder das auf versteckte Methoden oder Funktionen mapt. Der Großbuchstabe des Members bei der Zuweisung würde auch direkt anzeigen, dass es sich um einen Accessor handelt, da ich ansonsten Membervariablen immer klein schreibe.
Das würde auch wunderbar zu "Named Properties" passen, wenn man den Accessors sagt, dass sie sich irgendwo zentral unter bestimmten Namen registrieren sollen... Was man damit nicht alles anstellen könnte^^
Schade nur, dass ich selbst für den Direktmodus im Moment keinen Weg sehe, das ohne Indirektion (sei es über Zeiger auf size_ oder sonstwie) umzusetzen.

Tagträumerei?^^ Edit: Nachtträumerei?^^

An Jockel gesondert: Wie genau kommt es, dass du solche Situation noch nicht hattest? Ich kann mir das gar nicht vorstellen!

Wahrscheinlich meinte er, dass ihm 0815-Setter und -Getter bisher meist gereicht haben. Das geht mir ähnlich. Ich hab zwar auch schon Artikel gelesen, die Setter/Getter verdammen und eine Alternative (war glaub ich was mit Funktoren) heilig sprechen. Aber so wirklich hat mich das bisher nie überzeugt.

Decimad schrieb:

Schade nur, dass ich selbst für den Direktmodus im Moment keinen Weg sehe, das ohne Indirektion (sei es über Zeiger auf size_ oder sonstwie) umzusetzen.

Wie wärs, wenn du die Membervariable direkt öffentlich machst?

template <typename T>
class Accessor
{
    public:
        // Schnittstelle, um Property zu simulieren
        // d.h. Zuweisungs- und Konvertierungsoperator etc.
    private:
        T value;
};

class Widget
{
    public:
        Accessor<vis::Size> Size;

    private:
        // nichts
};

Allerdings ist es ja nun so, dass z.B. die Veränderung der Ausdehnung eines Widgets natürlich größere Auswirkungen auf den Rest haben (das ist ja der interessante Punkt und überhaupt der Hauptgrund um die Member, so sie denn in der direkten Form existieren, zu verstecken) und der Direktmodus damit ausfällt.

Du kannst ja dem Accessor Funktionalität mitgeben, falls nötig. Z.B. mit std::tr1::function , aber keine Ahnung, ob das drin liegt. Da Accessor ein Template ist, könntest du unter Umständen sogar (Member-)Funktionszeiger als Template-Parameter fest verdrahten.

Diese Properties in C++ sind jedenfalls ein interessantes Experiment

Wie würdest du denn umgekehrt die Funktionalität einbauen, wenn der Accessor nur eine Indirektion auf den Member wäre? Und was stört dich dabei an den Zeigern?

Decimad schrieb:

An Jockel gesondert: Wie genau kommt es, dass du solche Situation noch nicht hattest? Ich kann mir das gar nicht vorstellen!

Wahrscheinlich meinte er, dass ihm 0815-Setter und -Getter bisher meist gereicht haben.

Ja. Ich finde diese C#-Properties zwar sehr nett, aber da das in C++ so nicht vorgesehen ist, versuche ich das nicht irgendwie nachzubauen.
Also sind meine getter/setter normale Funktionen und die tuen was und sind daher Verben: getXY/setXY.
(Ich dachte diese Variante dürfte man aber nicht nennen, da du die nicht haben willst).

namespace vis {
    class Size {
    public:
        const int  y() const { return y_; }
              int& y()       { return y_; }
    private:
        int y;
    };

    class Widget {
    public:
        const Size& size() const { return size_; }
              Size& size()       { return size_; }
    private:
        Size size_;
    };

    void test()
    {
        Widget widget;
        widget.size().y() += 10; // sowas ist doch einfach schön
        const Widget w2(widget);
        int y = w2.size().y(); // nur read-only Zugriff
    }
}

widget.size().y() += 10; // sowas ist doch einfach schön

Ich habe eindeutig ein anderes Schönheitsempfinden

In C++ bin ich ebenfalls für set und get und zwar nach dem Codestil der Standardbibliothek: get_size und set_size . Wobei ich mir auch für reine Getter ein size vorstellen könnte. Als Setter sieht eine Funktion size aber einfach nur blöd aus.

Implementierungen für Properties unter C++ gibt es im Netz schon zahlreiche. Allerdings kann es schnell zu gewissen Unschönheiten und sogar Problemen kommen. C++ hat diese Möglichkeit einfach nicht und sich diese Möglichkeit irgendwie hinzubiegen, halte ich für verkehrt.

Grüssli

Und hier der Artikel, den ich vorhin erwähnt habe, der jedoch nur eine begrenzt bessere Alternative zu Settern/Gettern bietet: Link

Wenn du an unterschiedlichen Möglichkeiten interessiert bist, dann noch meine:

// [Code-Auszug]
    class Widget {
    public:
        const Size& size() const { return size_; }
              Size& size()       { return size_; }
    private:
        Size size_;
    };

Und wo genau ist hier der Vorteil gegenüber öffentlichen Memberfunktionen?

• Bei veränderbaren Objekten gibst du eine Non-Const-Referenz auf die Variable zurück. Damit hat man den gleichen Zugriff wie auf die Variable selbst.
• Bei konstanten Objekten gibst du eine Const-Referenz oder Kopie zurück. Dadurch kann man die Variable zwar nicht verändern, aber genau das Gleiche trifft auf eine öffentliche Membervariable zu.

Der Unterschied zu public -Variablen sind also lediglich die Klammern beim Aufruf und der zusätzliche Code, was ich nicht unbedingt als Vorteil werten würde.

Implementierungen für Properties unter C++ gibt es im Netz schon zahlreiche. Allerdings kann es schnell zu gewissen Unschönheiten und sogar Problemen kommen. C++ hat diese Möglichkeit einfach nicht und sich diese Möglichkeit irgendwie hinzubiegen, halte ich für verkehrt.

Also ohne eingehende Begründung (von der ich fest ausgehe, dass du sie besitzt, nur nicht so weit ausholen wolltest) finde ich die Argumentation "C++" hätte etwas nicht eingabaut -> versuch es nicht trotzdem, wenig überzeugend

Der Unterschied zu public -Variablen sind also lediglich die Klammern beim Aufruf und der zusätzliche Code, was ich nicht unbedingt als Vorteil werten würde.

Es hat einige zusätzliche Vorteile gegenüber public -Variablen:

• Du kannst die Size irgendwo speichern. In einem std::vector , in einer union , in einem pImpl , usw., ohne dass der Aufrufer davon wissen muss.
• Du hast die Möglichkeit, nicht direkt eine Referenz sondern einen Acessor, der sich so verhält wie eine Size, zurückzugeben. Im Normalfall ist das allerdings nicht nötig.
• Du kannst den Zugriff loggen.
• Einheitlichkeit. Ein öffentlich unveränderlicher Member kann nicht als öffentliche Variable definiert werden, sondern muss wie von der STL von vector::size() als Funktion zur Verfügung stehen. Einmal mit, einmal ohne Klammern - immer mit sehe ich da als Vorteil.

Nexus schrieb:

Und wo genau ist hier der Vorteil gegenüber öffentlichen Memberfunktionen?

• Einheitlichkeit. Ob ein Member unveränderlich ist wie ein vector::size() oder eben doch veränderlich, der Zugriff bleibt gleich.
• Für manche Leute subjektiv schönerer Code ( a.foo() += 5; ).
• Objektiv kürzerer Code.

Muss dich natürlich nicht überzeugen, Boost und mein Lieblingstoolkit verwenden auch die get_prop / set_prop -Variante, das zwingt mich dann doch zu solchen Eigenschaftsfunktionen in allen damit verbundenen Klassen. Ich bin mit meinem Geschmack scheinbar in der Unterzahl.

Naja, wird wohl etwas OffTopic. Decimad, hast du schon etwas mit dem Accessor herumexperimentiert? Du hast ja gesagt, du sähest die Möglichkeit über Zeiger. Wie würde das konkret aussehen, Funktionalität zu implementieren? Auch über Callables ( std::tr1::function )?

Du kannst die Size irgendwo speichern. In einem std::vector , in einer union , in einem pImpl , usw., ohne dass der Aufrufer davon wissen muss.

Okay, das stimmt.

Du hast die Möglichkeit, nicht direkt eine Referenz sondern einen Acessor, der sich so verhält wie eine Size, zurückzugeben.

Womit wir wieder beim Property wären...

alternato schrieb:

Du kannst den Zugriff loggen.

Aber nur beschränkt. Du kannst nur aufzeichnen, wann die Referenz zurückgegeben wurde, und nicht jede einzelne Veränderung. Du siehst auch nicht, welche Art von Veränderung stattfindet. Das ist ein Nachteil gegenüber SetPosition(absolutePos) und Move(offset) , weil du = und += nicht unterscheiden kannst.

Du kannst aber in der Dokumentation schreiben, dass die Referenz nicht weiterverwendet werden soll, sodass du zumindest den Zeitpunkt kennst. Auch wenn du damit ein paar sinnvolle Fälle einschränkst.

alternato schrieb:

Einheitlichkeit. Ob ein Member unveränderlich ist wie ein vector::size() oder eben doch veränderlich, der Zugriff bleibt gleich.

Was aber auf GetSize() ebenso zutrifft.

alternato schrieb:

Objektiv kürzerer Code.

Das kommt erst bei komplexeren Ausdrücken zum Tragen, wie bei

obj.SetSize(5 * obj.GetSize());
// vs
obj.Size() *= 5;

Dafür nimmst du eine geringere Kontrollmöglichkeit in Kauf (siehe oben). Falls dieser spezifische Fall oft vorkommt, könnte man sich auch sowas überlegen:

obj.Scale(5);

alternato schrieb:

Muss dich natürlich nicht überzeugen [...]. Ich bin mit meinem Geschmack scheinbar in der Unterzahl.

Ich bin nur bisher meist mit konventionellen Get/Set-Methoden zufrieden gewesen. Ab und zu habe ich auch Strukturen mit nur öffentlichen Variablen.

Aber wenn, dann denke ich am ehesten sowas wie den Accessor aus diesem Thread. Diese Alternative könnte durchaus in manchen Fällen Potenzial haben. Und zufälligerweise stehe ich auch gleich vor einem ähnlichen Problem (einer Klasse mit sehr vielen Get/Set-Funktionen).

template< typename DataType, typename Class, void (Class::*Setter)( const DataType& ), DataType (Class::*Getter)() const >
class Accessor
{
public:
	Accessor( Class* p ) : this_(p) {}

	Accessor& operator=( const DataType& data )
	{
		(this_->*Setter)( data );
		return *this;
	}

private:
	Class* this_;
};

class Test {
public:
	Test() : Value( this ) {}

private:
	void setValue( const int& val ) { std::cout << "Setting to " << val; }
	int getValue() const;

public:
	Accessor< int, Test, &Test::setValue, &Test::getValue > Value;
};

int main()
{
	Test myTest;

	myTest.Value = 10;

	return 0;
}

Dravere schrieb:

Implementierungen für Properties unter C++ gibt es im Netz schon zahlreiche. Allerdings kann es schnell zu gewissen Unschönheiten und sogar Problemen kommen. C++ hat diese Möglichkeit einfach nicht und sich diese Möglichkeit irgendwie hinzubiegen, halte ich für verkehrt.

Also ohne eingehende Begründung (von der ich fest ausgehe, dass du sie besitzt, nur nicht so weit ausholen wolltest) finde ich die Argumentation "C++" hätte etwas nicht eingabaut -> versuch es nicht trotzdem, wenig überzeugend

Gut, dann bringe ich mal ein einfaches Argument:
Man verwendet Getter und Setter unterandem, damit zusätzlicher Code bei der jeweiligen Aktion durchgeführt werden kann. Auch wenn es nur ein Breakpoint ist oder man die Aktion protokollieren möchte. Wie erreichst du dies mit den nachgebauten Properties? Geht nicht! Es erfordert gleich die Abänderung der Property-Hilfsklasse und betrifft somit alle Properties, statt nur eines einzelnen. Oder dann muss man einen Callback-Mechanismus einbauen, welcher aber recht aufwendig sein kann. std::tr1::function oder boost::function sind unheimlich komplexe Gebilde und kosten auch einiges an Zeit. Wenn man anfängt für so Dinge wie Setter und Getter viel Zeit zu verbraten, nur weil man dadurch 3 Zeichen einsparen kann, dann ist das irgendwie recht fraglich.
Wenn du die Properties in C# ansiehst, dann kannst du dort ganz einfach die Getter und Setter eines jeden Properties an deine Bedürfnisse anpassen, ohne zusätzliche Laufzeit zu verbraten.

Es ist alles eben ein wenig eine Frage des Preis-Leistungsverhältnis. Was bringen einem Properties in C++? Das einzige Argument ist, welches ich bisher gesehen habe, dass man nicht mehr size() schreiben muss sondern size . Es geht also darum zwei Klammern einzusparen. Damit soll angeblich die Lesbarkeit erhöht werden. Dass man auch mit temporären Zwischenvariablen arbeiten kann, wird hingegen oft ignoriert:

int x = pos.get_x();
int y = pos.get_y();
int width = rect.get_width();

int index = y * width + x;

Was soll daran unübersichtlich sein?

Ein anderes bisschen einfacheres Argument:
Wie machst du Properties kopierbar, aber von aussen nicht zuweisbar?

Properties Workarounds in C++ bieten keinerlei relevanten Vorteil. Dafür können sie Nachteile mit sich bringen. Wieso sollte man also eine Technik einsetzen, welche unter dem Strich nichts bringt?

Grüssli

Also in der simpelsten Form würde ich auf die generalisierten Funktionszeiger ala tr1::function gerne erstmal verzichten, da es sich ja erstmal nicht um dynamische Beziehungen handelt, sondern um zur Compile-Zeit festgelegte

Genau, deshalb auch noch der Vorschlag "Da Accessor ein Template ist, könntest du unter Umständen sogar (Member-)Funktionszeiger als Template-Parameter fest verdrahten." Scheinbar hast du das auch gerade getan

Mit Metaprogrammierung könnte man wahrscheinlich noch etwas optimieren, sodass z.B. int statt const int& verwendet werden kann.

Decimad schrieb:

Man beachte die nicht so tolle Konstruktion, this vor dem Betreten des Konstruktors zu verwenden...

Ist das ein Problem? Du verwendest ja nur den Zeiger als Verweis. Soweit ich weiss, wird es erst beim tatsächlichen Zugriff auf this problematisch...

Allerdings ist meinem Beispiel nicht der Vorteil tragend, dass man sich das () spart, sondern dass man die intuitive Zuweisungs-Operation benutzen kann (zumindest in meinen Augen).

Es geht also darum?

text.x = 20;
text.set_x(20);

Du willst wirklich diesen riesigen Aufwand betreiben wegen sowas? Dir alle Nachteile (gibt noch mehr als bisher genannt) einkaufen, weil du es ein bisschen intuitiver findest? Setter und Getter sind äusserst üblich in Programmiersprachen. Daran gewöhnst du dich sehr schnell.

Decimad schrieb:

Ich hasse solche Konflikte, ganz ehrlich

Ich sehe keinen Konflikt. Die Kosten sind im Verhältnis zum Nutzen so überdimensional, dass die einzig logische Entscheidung gegen Property Workarounds in C++ sein muss.
Mag zwar eine interessante akademische Überlegung sein und vielleicht Spass machen, sowas mal auszuprobieren - was ich auch schon gemacht habe, aber für den praktischen Einsatz ist es einfach untauglich.

Grüssli

Es erfordert gleich die Abänderung der Property-Hilfsklasse und betrifft somit alle Properties, statt nur eines einzelnen. Oder dann muss man einen Callback-Mechanismus einbauen, welcher aber recht aufwendig sein kann. std::tr1::function oder boost::function sind unheimlich komplexe Gebilde und kosten auch einiges an Zeit.

Darum auch die Hardwire-Lösung über Templateparameter. Accessor muss dazu nicht verändert werden, da es generisch ist.

Dravere schrieb:

Dass man auch mit temporären Zwischenvariablen arbeiten kann, wird hingegen oft ignoriert:

// [leicht abgeändert]
int x = pos.get_x();
int y = pos.get_y();
int width = rect.get_width();

pos.set_x(y * width + x); // [Setter eingebaut]

Und dass das viel mehr Code als

pos.x = pos.y * pos.width + pos.x; // oder auch
pos.x() = pos.y() * pos.width() + pos.x();

braucht, wird scheinbar von dir ignoriert.

Dravere schrieb:

Was soll daran unübersichtlich sein?

Es ist nicht unübersichtlich, aber es braucht verdammt viel Code, um fast nichts zu erreichen. Bei grösseren Objekten kommt die Kopie dazu. Es sei denn, du speicherst etwas als Const-Referenz (falls auch eine solche zurückgegeben wird), womit aber auch viele Leute ein Problem haben.

Dravere schrieb:

Ein anderes bisschen einfacheres Argument:
Wie machst du Properties kopierbar, aber von aussen nicht zuweisbar?

Das ist ein guter Punkt, hier müsste man sich was überlegen. Eine Einschränkung wäre vielleicht, dass man trotzdem den operator() aufruft, um auch keine Konflikte mit impliziten Konvertierungen etc. zu bekommen.

Dravere schrieb:

Properties Workarounds in C++ bieten keinerlei relevanten Vorteil. Dafür können sie Nachteile mit sich bringen. Wieso sollte man also eine Technik einsetzen, welche unter dem Strich nichts bringt?

Die Prämisse stimmt schon nicht. Mit Properties kann man eine einfachere und intuitivere Syntax haben.

Natürlich sind sie nicht ganz so toll wie in C#, und es gibt einige Einschränkungen. Für den Alltagsgebrauch würde ich auch klassische Setter/Getter empfehlen. Aber nur weil man ein Sprachkonzept an eine andere Sprache anlehnt, schrillen bei dir die Alarmglocken und du musst jeden Versuch schon kategorisch schlecht finden.

Die Idee von Properties ist interessant. Ich sage nicht, man soll sie jetzt immer einsetzen. Aber man kann ja mal ein wenig herumexperimentieren, was sie alles so können, ohne gleich in die böse Sprachkonzept-Übernehmer-Schublade gesteckt zu werden. Gut möglich, dass sie sich nicht bewähren, aber dann wars ein lustiges Experiment.