Le C++ n'intègre pas cette fonctionnalité, mais vous pouvez définir un modèle pour imiter la fonctionnalité des propriétés :
template <typename T>
class Property {
public:
virtual ~Property() {} //C++11: use override and =default;
virtual T& operator= (const T& f) { return value = f; }
virtual const T& operator() () const { return value; }
virtual explicit operator const T& () const { return value; }
virtual T* operator->() { return &value; }
protected:
T value;
};
A définir une propriété :
Property<float> x;
Pour mettre en œuvre un getter/setter personnalisé juste hériter :
class : public Property<float> {
virtual float & operator = (const float &f) { /*custom code*/ return value = f; }
virtual operator float const & () const { /*custom code*/ return value; }
} y;
Pour définir un propriété en lecture seule :
template <typename T>
class ReadOnlyProperty {
public:
virtual ~ReadOnlyProperty() {}
virtual operator T const & () const { return value; }
protected:
T value;
};
Et pour l'utiliser en classe Owner
:
class Owner {
public:
class : public ReadOnlyProperty<float> { friend class Owner; } x;
Owner() { x.value = 8; }
};
Vous pourriez définir certains des éléments ci-dessus dans macros pour le rendre plus concis.
73 votes
Cela pourrait être fait avec quelques macros. s'enfuit honteusement
0 votes
Je rends tout public et j'accède directement aux champs dans le cadre de l'interface publique de la classe. Si un champ doit vraiment être privé, je le fais précéder d'un trait de soulignement, mais on peut quand même y accéder s'il y a une raison impérative. C'est une mauvaise idée si vous avez des développeurs incompétents dans votre équipe qui en abusent. canards
7 votes
@Eloff : Rendre tout public est TOUJOURS une mauvaise idée.
8 votes
Ce concept n'existe pas ! Et vous n'en avez pas besoin non plus : seanmiddleditch.com/why-c-does-not-need-c-like-properties
2 votes
A) cette question est assez ancienne b) je demandais un sucre syntaxique, qui me permettrait de me débarrasser des parenthèses c) bien que l'article présente des arguments valables contre l'adaptation des propriétés, la question de savoir si le C++ "a besoin ou non" de propriétés est très subjective. Le C++ est équivalent à la Touring-machine même sans elles, mais cela ne signifie pas qu'avoir un tel sucre syntaxique rendrait le C++ plus productif.
0 votes
C'est vieux mais pertinent. La réponse acceptée actuellement n'est pas complète, envisagez d'en accepter une autre.
0 votes
Pour des raisons de débogage, il m'arrive de convertir une variable membre publique (ick) en un opérateur getter et setter nommé (en utilisant les techniques décrites dans les réponses). Trouvez le bogue, puis supprimez cette instrumentation. C'est une technique pratique pour traquer les bogues, mais pas quelque chose à laisser en place pour la production (imo).
0 votes
@Kaiserludi pas nécessairement, si tout est public et statique vous êtes en sécurité =))) {sarcastices fermés}
0 votes
J'ai bien peur que non. 4321
3 votes
Définitivement non.
1 votes
Non, mais d'autant plus qu'il s'agit d'une lecture seule.
const Foo& foo(): const;
0 votes
Cette question est assez ancienne. Je demandais un sucre syntaxique, qui me permettrait de me débarrasser des parenthèses, bien que l'article présente des arguments valables contre l'adaptation des propriétés, la question de savoir si le C++ "a besoin ou non" de propriétés est très subjective. Le C++ est équivalent à la Touring-machine même sans elles, mais cela ne signifie pas qu'avoir un tel sucre syntaxique rendrait le C++ plus productif.
2 votes
Il n'y en a pas, principalement parce que cet anti-modèle est insensé. Tout ce qu'il tend à faire, c'est contourner l'encapsulation. Mais il n'y a pas de mal à demander.
1 votes
@CinCout, je reçois actuellement HTTP 500 connexion refusée sur votre lien. Au cas où il ne s'agirait pas d'une panne passagère : web.archive.org/web/20170924162758/http://seanmiddleditch.com/