[property] interest in C# like properties for C++?
I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it. Code sample: #include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream> class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused. BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); }; //And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); } The trick used is the following: class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; }; It currently support: Read/Write properties Read properties Write properties Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail. Regards Peder
Peder Holt escribió:
I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it.
The trick used is the following:
//Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x);
That's derreferencing a null pointer. Its probably what the offsetof macro does anyway, which by the way is restricted to PODs.
Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail.
Overloading operators for a property is important, I think its what makes it a "C++ Property". Keep the good work going! Agustín K-ballo Bergé.-
Peder Holt wrote:
It currently support: Read/Write properties Read properties Write properties
Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail.
I would love to see C++ properties! It may be syntactic sugar but I happen to have a sweet tooth. Will parenthesizing the properties be enough to use them with const operators? I tried to play with your code, but it won't compile on codepad: http://codepad.org/MD5knINj Thanks, -Matt
2009/10/19 Matthew Chambers <matthew.chambers@vanderbilt.edu>
I would love to see C++ properties! It may be syntactic sugar but I happen to have a sweet tooth. Will parenthesizing the properties be enough to use them with const operators? I tried to play with your code, but it won't compile on codepad:
http://codepad.org/MD5knINj Can you try it now? I think the issue has been solved. Currently, if you have a property X of type double, you have to write double(X)*double(X) to make it work, but it shouldn't be too difficult to get proper operator support into place. Regards Peder
Thanks, -Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2009/10/19 Matthew Chambers <matthew.chambers@vanderbilt.edu>
Peder Holt wrote:
I would love to see C++ properties! It may be syntactic sugar but I happen to have a sweet tooth. Will parenthesizing the properties be enough to use them with const operators? I tried to play with your code, but it won't compile on codepad: http://codepad.org/MD5knINj
It now compiles without warnings, also for classes with virtual members. Operator support is added for operator*. http://codepad.org/A4vaAMPZ Regards Peder Thanks,
-Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It now compiles without warnings, also for classes with virtual members. Operator support is added for operator*. http://codepad.org/A4vaAMPZ
Regards Peder Very nice. Do you know how reliable your reliance on UB is on the major
Peder Holt wrote: platforms? If it works on MSVC 9+, GCC 4.1, and darwin, that's enough for me. Do you plan to have a macro for defining simple/trivial properties with a single line? A more sophisticated macro could define the functions to use for the getter/setter (similar to how Managed C++ and C++/CLI do it AFAIK). Just like in C#, it encourages good design from the start of an implementation: the first iteration can use properties backed by simple member variables, while future implementations may use a more complicated backend without the interface ever needing to change (and without resorting to set/get syntax). That allows the design focus at first to be on the interface instead of worrying about doing a good job on both the interface and the implementation. -Matt
Am Tuesday 20 October 2009 22:07:28 schrieb Matthew Chambers:
Do you plan to have a macro for defining simple/trivial properties with a single line?
I think that this is the only thing that's missing from c++, and that it doesn't need a C# properties syntax. the C++ "properties" syntax is, for example (taken from tr1::unordered_map): float max_load_factor() const; void max_load_factor(float z); I wouldn't even consider your proposed properties syntax "syntactic sugar". it's just a different syntax, not a better one imho. so if there's anything missing from c++ it would be something like #define BOOST_TRIVIAL_PROPERTY(T,name) \ T name() const{ return _name; } \ void name(T __name){ _name=__name; } \ T _name; some of the problems your syntax introduces have already been mentioned. another one is that the getters and setters can not be virtual. C# and C++/CLI allow overriding setters and getters, and pure virtual properties, but I don't think that can be achieved with the same syntax in C++, since setters/getters are functions of seperate nested classes.
Hi, I've been thinking about adding properties to C++ for some time, and I've written several different Property<T> classes, so I've been following this discussion with great interest. IMO C# properties are not as useful as they should be; I think that ideally a property is a declarative expression that automatically generates getter and/or setter code. For example I've been experimenting with a syntax that looks like this: struct Example { explicit Example( std::string& strName): name( strName ), count( 0 ) { } Property< std::string, public_get, private_set> name; Property< int, public_get, public_set> count; }; Now I should be able to write: void SomeFunc( std::string& strValue ) { Example x( strValue ); x.count = 5; int I = x.count; std::string strName = x.name; } The point to this exercise is that as a developer I want to write less code, not more. Here I see an opportunity to build a system to generate code for me. So rather than emulate C# properties, I'm hoping that C++ can come up with something better. David -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Strasser Sent: Tuesday, October 20, 2009 1:30 PM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++? Am Tuesday 20 October 2009 22:07:28 schrieb Matthew Chambers:
Do you plan to have a macro for defining simple/trivial properties with a single line?
I think that this is the only thing that's missing from c++, and that it doesn't need a C# properties syntax. the C++ "properties" syntax is, for example (taken from tr1::unordered_map): float max_load_factor() const; void max_load_factor(float z); I wouldn't even consider your proposed properties syntax "syntactic sugar". it's just a different syntax, not a better one imho. so if there's anything missing from c++ it would be something like #define BOOST_TRIVIAL_PROPERTY(T,name) \ T name() const{ return _name; } \ void name(T __name){ _name=__name; } \ T _name; some of the problems your syntax introduces have already been mentioned. another one is that the getters and setters can not be virtual. C# and C++/CLI allow overriding setters and getters, and pure virtual properties, but I don't think that can be achieved with the same syntax in C++, since setters/getters are functions of seperate nested classes. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am Wednesday 21 October 2009 02:07:19 schrieb David Brownstein:
Hi, I've been thinking about adding properties to C++ for some time, and I've written several different Property<T> classes, so I've been following this discussion with great interest. IMO C# properties are not as useful as they should be; I think that ideally a property is a declarative expression that automatically generates getter and/or setter code.
For example I've been experimenting with a syntax that looks like this:
struct Example { explicit Example( std::string& strName): name( strName ), count( 0 ) { }
Property< std::string, public_get, private_set> name; Property< int, public_get, public_set> count; };
ok, I can see the benefit of that, and it solves the trivial-property-problem much better than my TRIVIAL_PROPERTY macro. but wouldn't you need an additional template argument "Example" so you could be-friend "Example" to enable private access? however, I would keep accessing the property compatible to the established C++ property syntax. so instead of...
x.count = 5;
int I = x.count;
...Example::count would be a function object and you'd write... x.count(5); int I = x.count(); ...so you can exchange the property object with accessor functions at a later time, when you need non-trivial properties.
Stefan Strasser wrote:
Am Wednesday 21 October 2009 02:07:19 schrieb David Brownstein:
Hi, I've been thinking about adding properties to C++ for some time, and I've written several different Property<T> classes, so I've been following this discussion with great interest. IMO C# properties are not as useful as they should be; I think that ideally a property is a declarative expression that automatically generates getter and/or setter code.
For example I've been experimenting with a syntax that looks like this:
struct Example { explicit Example( std::string& strName): name( strName ), count( 0 ) { }
Property< std::string, public_get, private_set> name; Property< int, public_get, public_set> count; };
ok, I can see the benefit of that, and it solves the trivial-property-problem much better than my TRIVIAL_PROPERTY macro. but wouldn't you need an additional template argument "Example" so you could be-friend "Example" to enable private access?
however, I would keep accessing the property compatible to the established C++ property syntax. so instead of...
x.count = 5;
int I = x.count;
...Example::count would be a function object and you'd write...
x.count(5); int I = x.count();
I do not believe this is the right syntax for accessing properties. The idea of a "property" is that one uses syntax to access it as if it were a data object, while it still has the backing of a function to provide constraints.
Am Wednesday 21 October 2009 06:02:23 schrieb Edward Diener:
x.count(5); int I = x.count();
I do not believe this is the right syntax for accessing properties. The idea of a "property" is that one uses syntax to access it as if it were a data object, while it still has the backing of a function to provide constraints.
why? there is no widely used practice to use public data objects. so why would you need a property to emulate that syntax? while you might not consider accessor functions a property in the language construct sense, they do represent a property of the object they're a part of. this is widely used in the C++ standard library and boost. what's the rationale for another properties syntax?
Stefan Strasser wrote:
Am Wednesday 21 October 2009 06:02:23 schrieb Edward Diener:
x.count(5); int I = x.count(); I do not believe this is the right syntax for accessing properties. The idea of a "property" is that one uses syntax to access it as if it were a data object, while it still has the backing of a function to provide constraints.
why? there is no widely used practice to use public data objects. so why would you need a property to emulate that syntax?
while you might not consider accessor functions a property in the language construct sense, they do represent a property of the object they're a part of. this is widely used in the C++ standard library and boost. what's the rationale for another properties syntax?
Properties are just syntactic sugar for accessors to retrieve or set a "data" value which is part of an object. In other languages in which properties exist, such as C#, C++/CLI, C++ Builder, and Python, the syntax uses the form of "x = value" to set the "data" value x and "variable = x" to retrieve the "data" value x. There is nothing which intrinsically makes this form of syntactic sugar better or worse than "x = value()" and "variable = x()", as you suggest, other than common usage in other languages and the concept that a property represents at least theoretically some piece of "data" of that object, even though that "data" may not actually exist. I think it would be wise to keep the same syntactical form for property in C++ which commonly exists in other languages.
Am Wednesday 21 October 2009 10:27:08 schrieb Edward Diener:
Properties are just syntactic sugar for accessors to retrieve or set a "data" value which is part of an object. In other languages in which properties exist, such as C#, C++/CLI, C++ Builder, and Python, the syntax uses the form of "x = value" to set the "data" value x and "variable = x" to retrieve the "data" value x. There is nothing which intrinsically makes this form of syntactic sugar better or worse than "x = value()" and "variable = x()", as you suggest, other than common usage in other languages and the concept that a property represents at least theoretically some piece of "data" of that object, even though that "data" may not actually exist.
I think it would be wise to keep the same syntactical form for property in C++ which commonly exists in other languages.
I don't think that's wise at all. standard practices exist for a reason. that's like using UpperCaseNaming in the public interface of your classes, rather than lower_case_naming, because other languages do and you think it looks nicer. you might be right about that, but it requires everyone who uses your classes to know your syntax preferences, instead of just the standard. I've used properties in C# and there is no reason not to use them. in C++, I wouldn't use a C#-like properties syntax for this reason alone, even if all previously mentioned problems could be solved - there is an established C++ properties syntax. std::vector<int> stl_container; my_container_type my_container; size1=stl_container.size(); size2=my_container.size; //no "()"?! class author was using C# properties.
Stefan Strasser wrote:
Am Wednesday 21 October 2009 10:27:08 schrieb Edward Diener:
Properties are just syntactic sugar for accessors to retrieve or set a "data" value which is part of an object. In other languages in which properties exist, such as C#, C++/CLI, C++ Builder, and Python, the syntax uses the form of "x = value" to set the "data" value x and "variable = x" to retrieve the "data" value x. There is nothing which intrinsically makes this form of syntactic sugar better or worse than "x = value()" and "variable = x()", as you suggest, other than common usage in other languages and the concept that a property represents at least theoretically some piece of "data" of that object, even though that "data" may not actually exist.
I think it would be wise to keep the same syntactical form for property in C++ which commonly exists in other languages.
I don't think that's wise at all. standard practices exist for a reason.
that's like using UpperCaseNaming in the public interface of your classes, rather than lower_case_naming, because other languages do and you think it looks nicer. you might be right about that, but it requires everyone who uses your classes to know your syntax preferences, instead of just the standard. I've used properties in C# and there is no reason not to use them. in C++, I wouldn't use a C#-like properties syntax for this reason alone, even if all previously mentioned problems could be solved - there is an established C++ properties syntax.
I don't agree that what you call C++ properties are standard or widely used. I think the get/set prefix is probably just as widely used (just not in boost or std). Even in cases where one does find both get/set properties in the style you say is standard, X() and X(value), the X(value) function almost never returns X& (with both const and non-const overloads). This means that it can't be used in a chain of assignment operations like A.X(B.X(5)) which incidentally looks awful compared to A.X = B.X = 5. For properties, operator= is greater than operator() ;) -Matt
[ Stefan Strasser wrote: ] in C++, I wouldn't use a C#-like properties syntax for this reason alone, even if all previously mentioned problems could be solved - there is an established C++ properties syntax.
there is an established C++ properties syntax.
What ??? Sorry Stefan, I don't want you to feel like I'm picking on you, but I don't buy that for even one microsecond. -Sid Sacek
<snip>
I don't think that's wise at all. standard practices exist for a reason.
that's like using UpperCaseNaming in the public interface of your classes, rather than lower_case_naming, because other languages do and you think it looks nicer. you might be right about that, but it requires everyone who uses your classes to know your syntax preferences, instead of just the standard. I've used properties in C# and there is no reason not to use them. in C++, I wouldn't use a C#-like properties syntax for this reason alone, even if all previously mentioned problems could be solved - there is an established C++ properties syntax.
std::vector<int> stl_container; my_container_type my_container;
size1=stl_container.size(); size2=my_container.size; //no "()"?! class author was using C# properties.
What I am missing in C++ is the grouping of the two (getting and setting) into a logical entity. I feel this is a bit like iterators vs range. A range is one objects that represents more than the sum of two iterators. The same can be true of properties. In the code, it feels cleaner to group the two together. Whether you are using one syntax or the other doesn't matter that much to me. The important thing I would like to contribute is a way of accessing the this pointer of the containing class. This can be isolated into the following piece of code: http://codepad.org/Y0z3nEk2 Or: class my_vector { public: struct { private: BOOST_PROPERTY_ACCESS_SELF(my_vector,x); friend class my_vector; public: const double& operator()() const {return m_x;} void operator()(const double& arg) {m_x=arg;self()->refresh();} private: double m_x; } x; void refresh() {std::cout <<std::endl << "Changed x to " << x() << std::endl;} }; This way you are free to choose your syntax by what you choose to implement inside your property :) Personally I feel that the property syntax can be great, especially for GUI programming. But I agree that it may not be fit for domain logic.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sorry, Edward Diener is absolutely correct in this manner. The C# language is very clear about what properties are, why they're part of the language, and how they're used. Let me remind you that this topic is: "interest in C# like properties for C++?" x.count() is not a property usage... it is a blatant accessor function call Think about these two lines of code: int x, y; x = y = 100; Now, if x and y were properties instead of variables, you would be able to write code like this: obj.x = obj.y = 100; Now, how would you write that line of code using accessor functions? By any standard, it would be inferior to the syntax above. -Sid Sacek -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Strasser Sent: Wednesday, October 21, 2009 1:06 AM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++?
[Stefan Strasser [strasser@uni-bremen.de] wrote:]
x.count(5); int I = x.count();
[ Edward Diener [eldiener@tropicsoft.com] wrote: ]
I do not believe this is the right syntax for accessing properties. The idea of a "property" is that one uses syntax to access it as if it were a data object, while it still has the backing of a function to provide constraints.
[Stefan Strasser [strasser@uni-bremen.de] wrote:]
why? there is no widely used practice to use public data objects. so why would you need a property to emulate that syntax?
while you might not consider accessor functions a property in the language construct sense, they do represent a property of the object they're a part of. this is widely used in the C++ standard library and boost. what's the rationale for another properties syntax?
Am Wednesday 21 October 2009 19:26:55 schrieb Sid Sacek:
The C# language is very clear about what properties are, why they're part of the language, and how they're used.
if we were discussing the definition of a new language, I might agree with you. but this is C++. there is no point in a boost library that no one would use because using it results in public(!) class interfaces that differ from any widely used practice AND the standard library. the C# properties syntax has its benefits. having two syntaxes in parallel does not. so I wouldn't recommend using the property library in public interfaces. but that's its only intended use. from boost.org: "We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization." changing the standard library to use properties instead of accessor functions isn't an option. so why should another library, that is intended for eventual standardization, use properties? Am Wednesday 21 October 2009 15:20:23 schrieb Matt Chambers:
I don't agree that what you call C++ properties are standard or widely used. I think the get/set prefix is probably just as widely used (just
so there are 2 different standards, let's introduce a 3rd one?
not in boost or std). Even in cases where one does find both get/set properties in the style you say is standard, X() and X(value), the X(value) function almost never returns X& (with both const and non-const overloads)
many properties can't return a reference to their value
. This means that it can't be used in a chain of assignment operations like A.X(B.X(5)) which incidentally looks awful compared to A.X = B.X = 5. For properties, operator= is greater than operator() ;)
hmm...bool operator > (operator=,operator());
Stefan Strasser escribió:
if we were discussing the definition of a new language, I might agree with you. but this is C++. there is no point in a boost library that no one would use because using it results in public(!) class interfaces that differ from any widely used practice AND the standard library.
Boost.Parameter ? I think I recall reading in D&E that named parameters were proposed for standarization, and rejected. If C# properties were possible to implement with a library (that doesn't rely on UB), I think it should be accepted based on its quality. I would keep using regular member objects/functions, just as I keep using regular function parameters.
. This means that it can't be used in a chain of assignment operations like A.X(B.X(5)) which incidentally looks awful compared to A.X = B.X = 5. For properties, operator= is greater than operator() ;)
I could settle for A.X() = B.X() = 5, that's good enough for me. Agustín K-ballo Bergé.-
Stefan Strasser wrote:
Am Wednesday 21 October 2009 19:26:55 schrieb Sid Sacek:
The C# language is very clear about what properties are, why they're part of the language, and how they're used.
if we were discussing the definition of a new language, I might agree with you.
You're discussing the addition of a feature not in the language. It may as well be a new language.
but this is C++. there is no point in a boost library that no one would use because using it results in public(!) class interfaces that differ from any widely used practice AND the standard library.
That's a big leap.
the C# properties syntax has its benefits. having two syntaxes in parallel does not. so I wouldn't recommend using the property library in public interfaces. but that's its only intended use.
The reason we don't use public data members is because it violates encapsulation. The whole point of properties is that client code can be written *as if* there are public data members. The implementation can forward to functions if and *when* necessary without forcing a change in client code.
changing the standard library to use properties instead of accessor functions isn't an option. so why should another library, that is intended for eventual standardization, use properties?
I don't share that opinion. If we had properties in the standard library, it could well be that various classes would take advantage of them. The properties might be wired to use the existing accessors and mutators, for example, so that they are purely syntactic sugar without affecting existing clients.
Am Wednesday 21 October 2009 15:20:23 schrieb Matt Chambers:
I don't agree that what you call C++ properties are standard or widely used. I think the get/set prefix is probably just as widely used (just
so there are 2 different standards, let's introduce a 3rd one?
If the existing approaches aren't as useful or convenient, of course.
not in boost or std). Even in cases where one does find both get/set properties in the style you say is standard, X() and X(value), the X(value) function almost never returns X& (with both const and non-const overloads)
many properties can't return a reference to their value
In those cases in which it is possible and appropriate, and such functions don't do so, they violate your "standard," don't they?
. This means that it can't be used in a chain of assignment operations like A.X(B.X(5)) which incidentally looks awful compared to A.X = B.X = 5.
A.X() = B.X() = 5 isn't horrible, but A.X = B.X = 5 is what one expects when one thinks of "properties." _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
A.X() = B.X() = 5 isn't horrible, but A.X = B.X = 5 is what one expects when one thinks of "properties."
Sorry, if I jump in in the middle of the discussion. Boost.Test uses properties with syntax like this: int i = a.p_X; a.p_X.value = 1; This syntax IMO has couple advantages: 1. From encapsulation standpoint this is as good as having explicit setter and getter. 2. I do not like to allow a.p_X = 1. ".value" syntax allows me to grep easily for all the encounters of property modification. This is especially useful in situations where there are myriads of read-only access and only couple mutating ones. 3. Single line definition: readwrite_property<int> p_X; Instead of 3 lines required by data member, getter and setter. 4. I also have readonly_property, which can restrict mutating access to the property value for all classes (in which case property initialized in a constructor once and never changes). Or I can have readonly property with fixed list of classes allowed mutating access. Gennadiy
Hi, I like the setter ".value" notation. Although I prefer method-style getters and setters, if others prefer assignment notation then both can be included in a Property class. I experimented with get() and set() methods as well, and discovered that in a MS development environment (VC++ 7.1 or higher), there is a macro with the name "set" that causes problems without a #undef set statement. For this reason I stopped using get/set. I think the notation used to reference properties is less important (to me at least) than having properties be declarative, so that they automatically generate access code. After all a Property is a convenience. In my work I need to package and move a lot of data, so for me to express data members as properties has greatly reduced the amount of boiler-plate code that I have to write (i.e. getters and setters). I agree that simple property definition is desirable, as often a "symmetrical property" (public getter and setter) is desired, and in that (probably most common?) case, it should be easy to write: Property<int> counter; This is easy to do allow by defaulting template parameters. David -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: Wednesday, October 21, 2009 1:51 PM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++?
A.X() = B.X() = 5 isn't horrible, but A.X = B.X = 5 is what one expects when one thinks of "properties."
Sorry, if I jump in in the middle of the discussion. Boost.Test uses properties with syntax like this: int i = a.p_X; a.p_X.value = 1; This syntax IMO has couple advantages: 1. From encapsulation standpoint this is as good as having explicit setter and getter. 2. I do not like to allow a.p_X = 1. ".value" syntax allows me to grep easily for all the encounters of property modification. This is especially useful in situations where there are myriads of read-only access and only couple mutating ones. 3. Single line definition: readwrite_property<int> p_X; Instead of 3 lines required by data member, getter and setter. 4. I also have readonly_property, which can restrict mutating access to the property value for all classes (in which case property initialized in a constructor once and never changes). Or I can have readonly property with fixed list of classes allowed mutating access. Gennadiy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, ----- Original Message ----- From: "Gennadiy Rozental" <rogeeff@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, October 21, 2009 10:50 PM Subject: Re: [boost] [property] interest in C# like properties for C++?
A.X() = B.X() = 5 isn't horrible, but A.X = B.X = 5 is what one expects when one thinks of "properties."
Sorry, if I jump in in the middle of the discussion.
Boost.Test uses properties with syntax like this:
int i = a.p_X;
a.p_X.value = 1;
This syntax IMO has couple advantages:
1. From encapsulation standpoint this is as good as having explicit setter and getter.
2. I do not like to allow a.p_X = 1. ".value" syntax allows me to grep easily for all the encounters of property modification. This is especially useful in situations where there are myriads of read-only access and only couple mutating ones.
3. Single line definition:
readwrite_property<int> p_X;
Instead of 3 lines required by data member, getter and setter.
4. I also have readonly_property, which can restrict mutating access to the property value for all classes (in which case property initialized in a constructor once and never changes). Or I can have readonly property with fixed list of classes allowed mutating access.
I would name your class readwrite_data<> and read_only_data<> as there is no possibility to provide accessors, or are there? The main aim of a Property is exactly that, ability to provide read/write accessors to some property. I don't like too much your use of the .value to repere assignements, as the user can also use it to get the value. If you want to repare assignation to a data you should use a explicit function. I see one advantage to wrap some data type in a readwrite<T> or readonly<T> is that these classes can provide several styles: * Behave like builtin types (transparent): use assignement and conversion operators a.p_X = 1; i = a.p_X * Function like syntax for both setters and getters: use operator() to get reference or value a.p_X()=1; i = a.p_X(); * Different setter/getter methods names a.p_X.set_value(1); i = a.p_X.get_value(); Whether a single class should provide all the styles or only a particular need to be analysed, as each style has its own advantage and liabilities. Note for example that, set_value is reperable and can not be used to get the value and get_value is not ambiguous. Another way to repare the assignements is to use a free function assign_to, like we use swap, but this is out of the scope of this thread, so I will start a new one. Best, Vicente
Stewart, Robert wrote:
. This means that it can't be used in a chain of assignment operations like A.X(B.X(5)) which incidentally looks awful compared to A.X = B.X = 5.
A.X() = B.X() = 5 isn't horrible, but A.X = B.X = 5 is what one expects when one thinks of "properties."
A.X() and B.X() are the getters, not the setters, although I appreciate that they could return non-const references so they could be used like you wrote. But even these semantics do not conform with Stefan's notion of de facto "standard C++ properties." -Matt
Hi, ----- Original Message ----- From: "Sid Sacek" <ssacek@securewatch24.com> To: <boost@lists.boost.org> Sent: Wednesday, October 21, 2009 7:26 PM Subject: Re: [boost] [property] interest in C# like properties for C++?
Sorry,
Edward Diener is absolutely correct in this manner.
The C# language is very clear about what properties are, why they're part of the language, and how they're used.
Let me remind you that this topic is: "interest in C# like properties for C++?"
x.count() is not a property usage... it is a blatant accessor function call
Think about these two lines of code:
int x, y; x = y = 100;
Now, if x and y were properties instead of variables, you would be able to write code like this:
obj.x = obj.y = 100;
Now, how would you write that line of code using accessor functions? By any standard, it would be inferior to the syntax above.
-Sid Sacek
I agree completly. in TBoost.STM we are defining transactional variables, which will return the address on the transaction cache or the value itself. This transactional variable follow the same schema than the properties. tx::int_t i; atomic(_) { i = 0; } end_atomic; or int res; atomic(_) { res = i+3; } end_atomic; I think that it is very important that the user of properties don't change the way it used to use variables or fields. The oposit could be a drawback on soeme cases. For example, I have adapted the Bitfields libraries and provided some kind of trivial accessors. struct Rgb565 { uint16_t storage; BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, red, 0, 4); BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, green, 5, 10); BOOST_BITFIELD_DCL(uint16_t, storage, unsigned char, blue, 11,15); }; Rgb565 r; r.storage= 0xffff; // Write to a bitfield. Note that parenthesis are needed around the bitfield r.red() = 23; // Read from a bitfield unsigned char b = r.blue(); Recently I have ported a big project from big to little endian and I used this class, but I needed to add the cuple of parenthesis '()' in each field access. I would liked to provide instead a more natural interface so the user can do Rgb565 r; r.storage= 0xffff; // Write to a bitfield. Note that parenthesis are needed around the bitfield r.red = 23; // Read from a bitfield unsigned char b = r.blue; but I didn't know how. The trick of self could works, but the issue is that an instance of any class use a minimal storage, and this was forbiden on my particular use case. Could we define a property of a class that don't spend any memory at all in th embeeding class? Anyway, I think that a Property library will be welcome in Boost. I see two major non functional requirements to the sucess of such a library: efficiency and transaparent use. Best, Vicente
Hi, I've been thinking about adding properties to C++ for some time, and I've written several different Property<T> classes, so I've been following this discussion with great interest. IMO C# properties are not as useful as
should be; I think that ideally a property is a declarative expression
Hi, You have nailed several important points. Yes, for "private" setters and getters a class name is required so that the class can be a friend. I also share your belief that using function-style accessors rather than assignment is preferable. I'm attaching an include file that contains a Property class implementation that supports this example notation: struct TestClass { TestClass(): Alpha( 'a' ), Amount( 1001 ), AmountSetOnly( 1024 ), NumberGetOnly( 4096 ) {}; Property<bool> IsCreditCard; Property<int> Count; Property<int> Index; Property<char> Alpha; Property<int, reveal, conceal, TestClass> Number; Property<int, reveal, not_used> Amount; Property<int, not_used, reveal > AmountSetOnly; Property<int, conceal, not_used, TestClass> NumberGetOnly; }; Here "reveal" is analogous to "public" and "conceal" to private. I'm also attaching a test file, so it should be easy to build and see that this works. David -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Strasser Sent: Tuesday, October 20, 2009 8:16 PM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++? Am Wednesday 21 October 2009 02:07:19 schrieb David Brownstein: they that
automatically generates getter and/or setter code.
For example I've been experimenting with a syntax that looks like this:
struct Example { explicit Example( std::string& strName): name( strName ), count( 0 ) { }
Property< std::string, public_get, private_set> name; Property< int, public_get, public_set> count; };
ok, I can see the benefit of that, and it solves the trivial-property-problem much better than my TRIVIAL_PROPERTY macro. but wouldn't you need an additional template argument "Example" so you could be-friend "Example" to enable private access? however, I would keep accessing the property compatible to the established C++ property syntax. so instead of...
x.count = 5;
int I = x.count;
...Example::count would be a function object and you'd write... x.count(5); int I = x.count(); ...so you can exchange the property object with accessor functions at a later time, when you need non-trivial properties. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Brownstein wrote:
I also share your belief that using function-style accessors rather than assignment is preferable.
Why? What does that syntax offer you that makes it better? I understand Gennadiy's notion of searching for ".value" allowing him to find cases in which he assigns to a "property," though I fail to understand why such a search is important. I don't understand how parentheses help anything. In your code, you seem to support both syntaxes: std::string strName = Z.Name(); int iCount = Z.Count; Z.Count(3); Z.Count = 6; I see nothing gained by using parentheses. If there are to be function calls, I should think it would be functions with names like "get_value" and "set_value," though I'd lament the added verboseness. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Am Thursday 22 October 2009 16:10:59 schrieb Stewart, Robert:
David Brownstein wrote:
I also share your belief that using function-style accessors rather than assignment is preferable.
Why? What does that syntax offer you that makes it better? I understand Gennadiy's notion of searching for ".value" allowing him to find cases in which he assigns to a "property," though I fail to understand why such a search is important. I don't understand how parentheses help anything.
In your code, you seem to support both syntaxes:
std::string strName = Z.Name(); int iCount = Z.Count; Z.Count(3); Z.Count = 6;
I see nothing gained by using parentheses.
see my previous mails for arguments in favor of accessor functions, but if people don't agree with that, at the very least both syntaxes should be supported, because interfaces using properties and interfaces using accessors can overlap. take for example a GUI library that uses your proposed properties. a GUI "list" widget would probably make its list elements available through the interface of a STL container, so it must support size(). but you'd probably also want a property named "size", if that is how the rest of the GUI library is designed.
The only real difference that I see between assignment-style and function-style accessors is that if you use function-style accessors and later you replace an automatically generated accessor with a customized (manually generated) accessor, then all of the code that uses the original accessor continues to work (with a recompile). For example: struct MyClass { Property<int> counter; }; void foo() { MyClass x; x.counter( 5 ); } Now let's say that we re-define MyClass: struct MyClass { void counter( int iValue ) { counter = iValue; NotifyObserver(); } private: int counter; }; The function foo() doesn't need to be changed. This is more difficult to do with assignment-style accessors. David -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stewart, Robert Sent: Thursday, October 22, 2009 7:11 AM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++? David Brownstein wrote:
I also share your belief that using function-style accessors rather than assignment is preferable.
Why? What does that syntax offer you that makes it better? I understand Gennadiy's notion of searching for ".value" allowing him to find cases in which he assigns to a "property," though I fail to understand why such a search is important. I don't understand how parentheses help anything. In your code, you seem to support both syntaxes: std::string strName = Z.Name(); int iCount = Z.Count; Z.Count(3); Z.Count = 6; I see nothing gained by using parentheses. If there are to be function calls, I should think it would be functions with names like "get_value" and "set_value," though I'd lament the added verboseness. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Brownstein wrote: Please don't top post.
The only real difference that I see between assignment-style and function-style accessors is that if you use function-style accessors and later you replace an automatically generated accessor with a customized (manually generated) accessor, then all of the code that uses the original accessor continues to work (with a recompile).
I understood the point of properties to be that they could, at your discretion, be backed by a mutator and/or accessor function. Thus, when you want a "manually generated" accessor, you create it and inform the property declaration to use it instead of generating code for the accessor.
The function foo() doesn't need to be changed. This is more difficult to do with assignment-style accessors.
In my theoretical world, at least, the use of assignment-style accessors has nothing to do with that. After all, we're talking about proxies that forward to functions that do the accessing or mutation, right? The only issue is whether the functions are generated by the framework or provided by the client (class). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
A property is a "published data member of an object". And since a public property is "published", it's interface cannot and must not change. object.x = 10; It doesn't matter if 'object.x' is an integer or a sophisticated object impersonating an integer, whoever or whatever generates the underlying code must not break the 'publicly published' interface. So the worry about code not compiling in the future is actually unfounded. -Sid Sacek -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Brownstein
The only real difference that I see between assignment-style and function-style accessors is that if you use function-style accessors and later you replace an automatically generated accessor with a customized (manually generated) accessor, then all of the code that uses the original accessor continues to work (with a recompile).
For example:
struct MyClass { Property<int> counter; };
void foo() { MyClass x;
x.counter( 5 ); }
Now let's say that we re-define MyClass:
struct MyClass { void counter( int iValue ) { counter = iValue; NotifyObserver(); }
private: int counter; };
The function foo() doesn't need to be changed. This is more difficult to do with assignment-style accessors.
David
Hi, ----- Original Message ----- From: "David Brownstein" <dbrownstein@intrix.com> To: <boost@lists.boost.org> Sent: Thursday, October 22, 2009 6:22 PM Subject: Re: [boost] [property] interest in C# like properties for C++?
The only real difference that I see between assignment-style and function-style accessors is that if you use function-style accessors and later you replace an automatically generated accessor with a customized (manually generated) accessor, then all of the code that uses the original accessor continues to work (with a recompile).
For example:
struct MyClass { Property<int> counter; };
void foo() { MyClass x;
x.counter( 5 ); }
Now let's say that we re-define MyClass:
struct MyClass { void counter( int iValue ) { counter = iValue; NotifyObserver(); }
private: int counter; };
The function foo() doesn't need to be changed. This is more difficult to do with assignment-style accessors.
Well, this is true in this particular case. But if you think that you encapsulates the class MyClass when the Property class provides function like accessors you are wrong. Let me show you why. Don't forget, public is public, so part of the contract. If you want to encapsulate you need to make the fields private. The property class give you the illusion of providing encapsulation to MyClass, but as counter is in the public interface, the user can take the address of this field, struct MyClass { Property<int> counter; }; MyClass a; Property<int>* pt = &a.counter; play now with pt. As you can see you can not modify the class MyClass without impacts on the code as far as you modify its public part. Best, Vicente
On Thu, Oct 22, 2009 at 9:54 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Don't forget, public is public, so part of the contract.
Not everything that compiles is legal or defined behaviour. I'd love to see proper properties support, but I'm afraid that requires language support, otherwise you can't support reference properties. Olaf
What's a "Reference Property" and how would you use it in code? An example please... -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek Sent: Thursday, October 22, 2009 4:38 PM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++? On Thu, Oct 22, 2009 at 9:54 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Don't forget, public is public, so part of the contract.
Not everything that compiles is legal or defined behaviour. I'd love to see proper properties support, but I'm afraid that requires language support, otherwise you can't support reference properties. Olaf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek On Thu, Oct 22, 2009 at 10:43 PM, Sid Sacek <ssacek@securewatch24.com> wrote:
What's a "Reference Property" and how would you use it in code?
An example please...
Something like
class C;
class D { public: C& c; };
That'd be the non-property way.
Ummmm.... C++ references are irrelevant when you're already using properties... By default, properties behave just like references, unless you can show me some other usage that's not obvious. -Sid Sacek
Olaf van der Spek wrote:
On Thu, Oct 22, 2009 at 9:54 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Don't forget, public is public, so part of the contract.
Not everything that compiles is legal or defined behaviour. I'd love to see proper properties support, but I'm afraid that requires language support, otherwise you can't support reference properties.
Of course you can support reference properties along with value properties. It is just very hard, if not impossible, to support both kinds using the same template class. So really one would not a separate template class to support reference properties. Manipulating a reference property would be done purely through accessing the property. Accessing a reference property returns a T & or a T const & depending on whether the property is const or not. In the case where a T & is returned the reference property is read/write if T itself is not const, since you can manipulate T through the reference, whereas in the case where T const & is returned ( or where T & is returns but T is itself const), the reference property is read only. But one certainly does not need language support for this. In fact reference properties are very useful for user-defined types as T since the T & ( or T const & )'s data should ideally be manipulated for a T user-defined type through properties within T itself. Thus the property concept can drill down, so to speak, when the T itself is a user-defined type with is own properties.
[ Edward Diener wrote: ] Manipulating a reference property would be done purely through accessing the property. Accessing a reference property returns a T & or a T const & depending on whether the property is const or not. In the case where a T & is returned the reference property is read/write if T itself is not const, since you can manipulate T through the reference, whereas in the case where T const & is returned ( or where T & is returns but T is itself const), the reference property is read only.
Who says that's how properties work? That just happens to be your version of the implementation details. I don't think that's how properties have to work at all. -Sid Sacek.
Sid Sacek wrote:
[ Edward Diener wrote: ] Manipulating a reference property would be done purely through accessing the property. Accessing a reference property returns a T & or a T const & depending on whether the property is const or not. In the case where a T & is returned the reference property is read/write if T itself is not const, since you can manipulate T through the reference, whereas in the case where T const & is returned ( or where T & is returns but T is itself const), the reference property is read only.
Who says that's how properties work? That just happens to be your version of the implementation details.
Of course it is my version of the implementation details. Why would I explain it that way if it were not.
I don't think that's how properties have to work at all.
Good for you. Then you should posit an alternative. In my version value properties do not even have to exist as data variables either globally/static or members of a class. They can be synthesized on the fly. Reference properties OTOH have to exist as backing data somewhere, since a reference to that data is being returned. If you think, as you mentioned in another post, that "properties behave just like references" then properties must exist as backing data somewhere and the whole point of a property setter implementing a constraint is lost, since one can manipulate any property directly through the reference. Whereas with value properties ( the return is always a value of the appropriate T type and never a T & ) the only way to change the property is through the setter.
Am Friday 23 October 2009 01:41:57 schrieb Sid Sacek:
[ Edward Diener wrote: ] Manipulating a reference property would be done purely through accessing the property. Accessing a reference property returns a T & or a T const & depending on whether the property is const or not. In the case where a T & is returned the reference property is read/write if T itself is not const, since you can manipulate T through the reference, whereas in the case where T const & is returned ( or where T & is returns but T is itself const), the reference property is read only.
Who says that's how properties work? That just happens to be your version of the implementation details.
I don't understand what a "reference property" is supposed to be. a property getter can return a reference (if it chooses to do so, not in general, since there may not be an underlying data member), but what is a reference property? whether the value obtained through the getter is stored inside the object itself or only referenced by the object doesn't matter to the interface. the example given for a "reference property": struct D{ C& c; }; is equivalent to struct D{ C c; }; from the perspective of the user of the class interface. so why would there be a difference when the same thing is implemented as a "property"? and what is the difference? to the general discussion, I think there needs to be an agreed upon definition of a property first, before talking about library implementations. I defined a property to be "a property of an object" in general, e.g. the width of a rectangle, with the syntax to obtain that property from the object as an irrelevant detail, as long as it's standardized. that's why I came to the conclusion that c++ already has a syntax for properties. others seem to have the goal to emulate a C# language construct called "property" in C++. a third concern was a simpler definition of default/trivial properties, with whatever syntax to access them.
Stefan Strasser wrote:
Am Friday 23 October 2009 01:41:57 schrieb Sid Sacek:
[ Edward Diener wrote: ] Manipulating a reference property would be done purely through accessing the property. Accessing a reference property returns a T & or a T const & depending on whether the property is const or not. In the case where a T & is returned the reference property is read/write if T itself is not const, since you can manipulate T through the reference, whereas in the case where T const & is returned ( or where T & is returns but T is itself const), the reference property is read only. Who says that's how properties work? That just happens to be your version of the implementation details.
I don't understand what a "reference property" is supposed to be. a property getter can return a reference (if it chooses to do so, not in general, since there may not be an underlying data member), but what is a reference property?
In my implementation a "reference property" is a property whose getter returns a reference to the type of the property. A reference property does not have a setter. The actual backing data for a "reference property" can be a value type itself or a reference. The type T of a reference property does not need to be copy constructible. This is as opposed to what most people, and other language implementations, posit as a "property", which is generally a value type, meaning that a value is returned by the getter and a value is passed to the setter, of the particular type. The type T of a value type property does need to be copy constructible in order to pass the value back and forth. My own reasons for bifurcating the notion of a "property" between the more common value type property and the reference type property is because I do no think a clean implementation of the "property" concept can be done in C++ which allows either a reference or a value to be returned from the same C++ property implementation. I am sorry I have not posted my own "property" implementation anywhere yet, but I am still working on some other "property" issues which are important to me ( besides trying like everyone else to make a living as a software designer/programmer ). I originally added my comments about a "reference" type property because a poster in this thread felt that one could not implement this without language support and I do not believe that is the case, and wanted to explain in general how one could at least theoretically implement a "reference property". In a way I am arguing for the notion that a single implementation of the "property" concept, in other words a single template class which implements a C++ "property", while desirable from the point of view of usability, may not be practical from the point of view of flexibility and an end user's needs.
On Fri, Oct 23, 2009 at 1:30 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Of course you can support reference properties along with value properties. It is just very hard, if not impossible, to support both kinds using the same template class. So really one would not a separate template class to support reference properties.
Maybe I should've said class reference. Take std::string for example. I'd be very interested if you've got code that supports for example name.size() where name is your reference property class. name->size() is no problem, but I'd like to have name.size(). Olaf
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 1:30 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Of course you can support reference properties along with value properties. It is just very hard, if not impossible, to support both kinds using the same template class. So really one would not a separate template class to support reference properties.
Maybe I should've said class reference. Take std::string for example. I'd be very interested if you've got code that supports for example name.size() where name is your reference property class. name->size() is no problem, but I'd like to have name.size().
I understand your point, and you are right, and this is a notational weakness as compared with accessing the data directly. I don't believe that one can define a dot ( '.' ) operator in C++ but maybe there is a metaprogramming way to hijack the dot operator. If there is I would be glad to use it. Actually I have rejected defining the -> operator for my reference properties, because -> implies a pointer in standard C++ terminology and I do not think of reference properties "pointing" to their type object. Instead my reference properties have currently no built-in forwarder operator to the actual type object. One could currently use the more laborious form of: propertyReference<std::string> name; std::string & avar = name; // read/write property reference getter avar.size() = 10; // or std::string::size_type sz(avar.size()); or one could use my getter member function so one could write: propertyReference<std::string> name; name.getReference.size() = 10; // or std::string::size_type sz(name.getReference.size()); Using a member function rather than an operator in this case is just a little more inconvenient. My member function is actually currently called "getValue" for my reference property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference". ----------------------------------------------------------------------- "So really one would not a separate template class to support reference properties." This was originally mistyped by me and should have been: "So really one would need a separate template class to support reference properties." But I think you read through my error anyway without any problems. -----------------------------------------------------------------------
On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Maybe I should've said class reference. Take std::string for example. I'd be very interested if you've got code that supports for example name.size() where name is your reference property class. name->size() is no problem, but I'd like to have name.size().
I understand your point, and you are right, and this is a notational weakness as compared with accessing the data directly.
I don't believe that one can define a dot ( '.' ) operator in C++ but maybe there is a metaprogramming way to hijack the dot operator. If there is I would be glad to use it.
Actually I have rejected defining the -> operator for my reference properties, because -> implies a pointer in standard C++ terminology and I do not think of reference properties "pointing" to their type object. Instead my reference properties have currently no built-in forwarder operator to the actual type object. One could currently use the more laborious form of:
propertyReference<std::string> name; std::string & avar = name; // read/write property reference getter avar.size() = 10; // or std::string::size_type sz(avar.size());
Unacceptable
or one could use my getter member function so one could write:
propertyReference<std::string> name; name.getReference.size() = 10; // or std::string::size_type sz(name.getReference.size());
Unacceptable
Using a member function rather than an operator in this case is just a little more inconvenient.
For me, the access syntax of properties is *the* reason for using them. Otherwise you might as well just add string& name() and void set_name(const string&) functions to your class. What are your goals/reasons to use properties?
My member function is actually currently called "getValue" for my reference property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference".
How about just get()?
-----------------------------------------------------------------------
"So really one would not a separate template class to support reference properties."
This was originally mistyped by me and should have been:
"So really one would need a separate template class to support reference properties."
But I think you read through my error anyway without any problems.
Probably. ;)
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Maybe I should've said class reference. Take std::string for example. I'd be very interested if you've got code that supports for example name.size() where name is your reference property class. name->size() is no problem, but I'd like to have name.size(). I understand your point, and you are right, and this is a notational weakness as compared with accessing the data directly.
I don't believe that one can define a dot ( '.' ) operator in C++ but maybe there is a metaprogramming way to hijack the dot operator. If there is I would be glad to use it.
Actually I have rejected defining the -> operator for my reference properties, because -> implies a pointer in standard C++ terminology and I do not think of reference properties "pointing" to their type object. Instead my reference properties have currently no built-in forwarder operator to the actual type object. One could currently use the more laborious form of:
propertyReference<std::string> name; std::string & avar = name; // read/write property reference getter avar.size() = 10; // or std::string::size_type sz(avar.size());
Unacceptable
or one could use my getter member function so one could write:
propertyReference<std::string> name; name.getReference.size() = 10; // or std::string::size_type sz(name.getReference.size());
Unacceptable
Using a member function rather than an operator in this case is just a little more inconvenient.
For me, the access syntax of properties is *the* reason for using them. Otherwise you might as well just add string& name() and void set_name(const string&) functions to your class. What are your goals/reasons to use properties?
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it. My interpetation of the access syntax of properties is: 1) For a readable value property, one can use the name of the property to return the underlying value of the property and assign that value to a variable. 2) For a writable value property one can set the value of a property by assigning a value to it. 3) For a readable reference property, one can get a reference to the property. 4) For a writable reference property, one can get a non-const reference to the property. My main goals/reasons for properties are: 1) Syntactically treat a property as close as one can as a data member while providing the ability to control the accessing of the data and the setting of the data through callables ( functions, member functions, functors, boost::function ). 2) Have properties be a type. 3) Have all value properties of an underlying T type share an underlying base class and have all reference properties of an underlying T type share an underlying base class. 4) Provide means beyond just member functions for getting and setting values and getting references. I have more than just these goals, but the above are the main ones. Properties are in one way syntactic sugar for the plethora of get/retrieve/etc. and set/put/etc. member functions. I also acknowledge that it is syntactically impossible to manipulate properties as directly as one can manipulate data members as far as I can see. But properties are really not a substitute for data members but rather for get-like and set-like functions whose purpose is to access and manipulate a data value. After all, in my view of value properties, the data does not have to exist in memory at all, and I believe this is consistent with the implementation of properties in other languages. Of course you can use "string & name()" and "void set_name(const string &)" if you like instead, or you can even just have a public variable of "string name" you directly access and manipulate. I can offer my criticism of the first choice or the second choice but I think it is already well known.
My member function is actually currently called "getValue" for my reference property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference".
How about just get()?
I rejected this because of a feeling that some implementations of C++ may macroize ( create a C++ preprocessor macro ) from such a common term as "get". The same goes for "set". I am aware that ideally macros should be all uppercase, but many implementations and header files which should know better are deficient and forget this. Of course I can use "get" and "set" as the OP did in his C#-like property implementation, but I felt that getValue, setValue, getReference, and setReference were less likely to clash.
On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it.
Don't you agree that string& name = c.name; name.size() is kinda ugly/unusable compared to just c.name->size() (possible) or c.name.size() (not possible, but ideal)?
My main goals/reasons for properties are: 1) Syntactically treat a property as close as one can as a data member while providing the ability to control the accessing of the data and the setting of the data through callables ( functions, member functions, functors, boost::function ). 2) Have properties be a type. 3) Have all value properties of an underlying T type share an underlying base class and have all reference properties of an underlying T type share an underlying base class. 4) Provide means beyond just member functions for getting and setting values and getting references.
The main goal I guess is 1, as the others can be achieved with traditional get/set functions, right?
I have more than just these goals, but the above are the main ones.
Properties are in one way syntactic sugar for the plethora of get/retrieve/etc. and set/put/etc. member functions. I also acknowledge that it is syntactically impossible to manipulate properties as directly as one can manipulate data members as far as I can see. But properties are really not a substitute for data members but rather for get-like and set-like functions whose purpose is to access and manipulate a data value. After all, in my view of value properties, the data does not have to exist in memory at all, and I believe this is consistent with the implementation of properties in other languages.
That's right. And actually why I wanted to use a class reference property.
Of course you can use "string & name()" and "void set_name(const string &)" if you like instead, or you can even just have a public variable of "string name" you directly access and manipulate. I can offer my criticism of the first choice or the second choice but I think it is already well known.
I know, and I agree.
My member function is actually currently called "getValue" for my reference property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference".
How about just get()?
I rejected this because of a feeling that some implementations of C++ may macroize ( create a C++ preprocessor macro ) from such a common term as "get". The same goes for "set". I am aware that ideally macros should be all uppercase, but many implementations and header files which should know
Hmm, I'd consider such C++ implementations broken by design. Olaf
Speaking of which... Does anybody know what that file 'Property.hpp' is for; in the 'Pending' folder of the trunk? -Sid
It looks like this is Boost.Graph code that was probably intended to be reused in other libraries but probably never was actually reused. Should it be moved into boost/graph/? Does anyone use it outside Boost.Graph? -- Jeremiah Willcock On Fri, 23 Oct 2009, Sid Sacek wrote:
Speaking of which...
Does anybody know what that file 'Property.hpp' is for; in the 'Pending' folder of the trunk?
-Sid _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Oct 23, 2009 at 2:04 PM, Jeremiah Willcock <jewillco@osl.iu.edu>wrote:
It looks like this is Boost.Graph code that was probably intended to be reused in other libraries but probably never was actually reused. Should it be moved into boost/graph/? Does anyone use it outside Boost.Graph?
If it's not used anywhere outside of the BGL then probably, yes. It may be worth noting that the technique used for constructing properties may be deprecated by more advanced MPL features and certainly variadic templates. Andrew Sutton andrew.n.sutton@gmail.com
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it.
Don't you agree that string& name = c.name; name.size() is kinda ugly/unusable compared to just c.name->size() (possible) or c.name.size() (not possible, but ideal)?
No I don't think it is unusable, and its ugliness is petty subjective. The c.name.size() is terser, I grant you, but my alternative of c.name.getReference().size(), with that extra "getReference()", does not seem to me so terrible. If I accede to "get" rather than "getReference" then it is even shorter as c.name.get().size() with that extra "get()". Of course I can program in some operator symbol, such as ->, with very little effort so it becomes c.name->size() but I am uncomfortable with an operator in this case because there is little precedence what operator would make easy mnemonic sense. I would love to be able to say c.name.size() but it can't be done in C++ AFAICS. BTW I very much like user-defined operators and have been a vociferous critic of Java's refusal to add them to that language, so I could probably be convinced to add a user-defined operator to my eventually published implemetation of property if I felt others would find one understandable. But it appears to me that the -> user-defined operator is too embedded with the notion of "pointer" to use in my case.
My main goals/reasons for properties are: 1) Syntactically treat a property as close as one can as a data member while providing the ability to control the accessing of the data and the setting of the data through callables ( functions, member functions, functors, boost::function ). 2) Have properties be a type. 3) Have all value properties of an underlying T type share an underlying base class and have all reference properties of an underlying T type share an underlying base class. 4) Provide means beyond just member functions for getting and setting values and getting references.
The main goal I guess is 1, as the others can be achieved with traditional get/set functions, right?
Traditional get/set functions are not to my mind always the clearest way of implementing properties, even if they are the most popular. Furthermore 2) and 3) were also done because I envision properties being types as important to future standard C++ RAD programming environments.
I have more than just these goals, but the above are the main ones.
Properties are in one way syntactic sugar for the plethora of get/retrieve/etc. and set/put/etc. member functions. I also acknowledge that it is syntactically impossible to manipulate properties as directly as one can manipulate data members as far as I can see. But properties are really not a substitute for data members but rather for get-like and set-like functions whose purpose is to access and manipulate a data value. After all, in my view of value properties, the data does not have to exist in memory at all, and I believe this is consistent with the implementation of properties in other languages.
That's right. And actually why I wanted to use a class reference property.
If there is a better way to do it than what I have imagined and implemented in my own version, I would consider it, but reference properties AFAICS means that the underlying data is returned by reference. I don't see any way to get around that. In my original implementation I did not have reference properties at all. The value properties I currently implement can be used with backing data which is actually a reference. The T type of the reference just needs to be copy constructible in that case, that's all. But then I thought about it longer and realized that if one did have a T & ( or T const & ) as backing data one should be able to implement a reference property which simply returned that reference. I further realized that if the reference property was returned as T & and T were not const, the property is read/write, otherwise it is just readable, which fits in well with he trsditional concept of properties in other languages being readable, writable, or read/write. In the case of a reference property as I have implemented it there is no such thing as just a writable reference property, but in the case of a value property there is. Finally I wanted reference properties because user-defined classes themselves could easily have their own properties and the theoretically best way of setting class objects is by setting the properties in the class and not by trying to set an object of that class as a whole.
Of course you can use "string & name()" and "void set_name(const string &)" if you like instead, or you can even just have a public variable of "string name" you directly access and manipulate. I can offer my criticism of the first choice or the second choice but I think it is already well known.
I know, and I agree.
My member function is actually currently called "getValue" for my reference property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference". How about just get()? I rejected this because of a feeling that some implementations of C++ may macroize ( create a C++ preprocessor macro ) from such a common term as "get". The same goes for "set". I am aware that ideally macros should be all uppercase, but many implementations and header files which should know
Hmm, I'd consider such C++ implementations broken by design.
I do too and perhaps my reticence to use "get" ( and "set" ) is ill-founded. I would still defend it by saying that "getValue" and "getReference" are clearer mnemonically than just "get" even if I am forcing the end user to type some extra characters if they find it necessary to call the underlying function rather than use the operator T conversion operator.
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it.
Don't you agree that string& name = c.name; name.size() is kinda ugly/unusable compared to just c.name->size() (possible) or c.name.size() (not possible, but ideal)?
I might be stupid here, but can not see any advantage at all for using c.name->size() over the traditional c.name().size(). And why is the "ideal" c.cname.size(), should it not be c.name.size with size being a property of the string? Bo Persson
On Sat, Oct 24, 2009 at 4:11 AM, Bo Persson <bop@gmb.dk> wrote:
Don't you agree that string& name = c.name; name.size() is kinda ugly/unusable compared to just c.name->size() (possible) or c.name.size() (not possible, but ideal)?
I might be stupid here, but can not see any advantage at all for using c.name->size() over the traditional c.name().size().
Since references can't be rebound, I'm using a pointer to store the actual value. So the first syntax doesn't require any modification of call sites. The first one looks more natural to me without the ().
And why is the "ideal" c.cname.size(), should it not be c.name.size with size being a property of the string?
Yes, if std::string::size indeed becomes a property. That's unlikely to happen any time soon though. :( Olaf
Hello, Olaf. Friday, October 23, 2009 at 8:22:41 PM you wrote: OvdS> On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener OvdS> <eldiener@tropicsoft.com> wrote:
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it.
OvdS> Don't you agree that string& name = c.name; name.size() is kinda OvdS> ugly/unusable compared to just c.name->size() (possible) or OvdS> c.name.size() (not possible, but ideal)? First case (i. e. c.name->size()) I already implemented in my version of properties. Properties supports several access interfaces: 1. Like regular datamembers: string str = c.name; 2. Similar to smart pointers: string str = *c.name; 3. Function-call like syntax: string str = c.name(); 4. set/get syntax: string str = c.name.get(); 5. Member-access interface: size_t sz = c.name->size(); Last for cases breaks traditional datameber access inteface. But! During regular usage in live project it does not matter. I mean that properties (in such implementation) are another kind of the class interface. Your are always keeping in mind (almost automatically) what such kind of member in the public class interface is not usual datamember and can have specific access rules. It is simple. :) -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Friday, October 23, 2009 8:33 AM To: boost@lists.boost.org Subject: Re: [boost] [property] interest in C# like properties for C++? Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Maybe I should've said class reference. Take std::string for example. I'd be very interested if you've got code that supports for example name.size() where name is your reference property class. name->size() is no problem, but I'd like to have name.size(). I understand your point, and you are right, and this is a notational weakness as compared with accessing the data directly.
I don't believe that one can define a dot ( '.' ) operator in C++ but maybe there is a metaprogramming way to hijack the dot operator. If there is I would be glad to use it.
Actually I have rejected defining the -> operator for my reference properties, because -> implies a pointer in standard C++ terminology and I do not think of reference properties "pointing" to their type object. Instead my reference properties have currently no built-in forwarder operator to the actual type object. One could currently use the more laborious form of:
propertyReference<std::string> name; std::string & avar = name; // read/write property reference getter avar.size() = 10; // or std::string::size_type sz(avar.size());
Unacceptable
or one could use my getter member function so one could write:
propertyReference<std::string> name; name.getReference.size() = 10; // or std::string::size_type sz(name.getReference.size());
Unacceptable
Using a member function rather than an operator in this case is just a little more inconvenient.
For me, the access syntax of properties is *the* reason for using them. Otherwise you might as well just add string& name() and void set_name(const string&) functions to your class. What are your goals/reasons to use properties?
You are not talking about the access syntax of properties, as I define it, so your "Unacceptable"s mean little to me. Of course if the syntax limitations of a property implementation vis-a-vis direct manipulation of a data value is unacceptable to you, then you just wouldn't use it. My interpetation of the access syntax of properties is: 1) For a readable value property, one can use the name of the property to return the underlying value of the property and assign that value to a variable. 2) For a writable value property one can set the value of a property by assigning a value to it. 3) For a readable reference property, one can get a reference to the property. 4) For a writable reference property, one can get a non-const reference to the property. My main goals/reasons for properties are: 1) Syntactically treat a property as close as one can as a data member while providing the ability to control the accessing of the data and the setting of the data through callables ( functions, member functions, functors, boost::function ). 2) Have properties be a type. 3) Have all value properties of an underlying T type share an underlying base class and have all reference properties of an underlying T type share an underlying base class. 4) Provide means beyond just member functions for getting and setting values and getting references. I have more than just these goals, but the above are the main ones. Properties are in one way syntactic sugar for the plethora of get/retrieve/etc. and set/put/etc. member functions. I also acknowledge that it is syntactically impossible to manipulate properties as directly as one can manipulate data members as far as I can see. But properties are really not a substitute for data members but rather for get-like and set-like functions whose purpose is to access and manipulate a data value. After all, in my view of value properties, the data does not have to exist in memory at all, and I believe this is consistent with the implementation of properties in other languages. Of course you can use "string & name()" and "void set_name(const string &)" if you like instead, or you can even just have a public variable of "string name" you directly access and manipulate. I can offer my criticism of the first choice or the second choice but I think it is already well known.
My member function is actually currently called "getValue" for my
reference
property but I have decided that it is a confusing name since one is really getting a reference, and have changed it to "getReference".
How about just get()?
I rejected this because of a feeling that some implementations of C++ may macroize ( create a C++ preprocessor macro ) from such a common term as "get". The same goes for "set". I am aware that ideally macros should be all uppercase, but many implementations and header files which should know better are deficient and forget this. Of course I can use "get" and "set" as the OP did in his C#-like property implementation, but I felt that getValue, setValue, getReference, and setReference were less likely to clash. Regarding goals for implementing properties, it seems to me that if a properties implementation only provides convenient notation for accessing, that would be unfortunate. IMO properties could be very useful by providing a code generation facility so that users won't have to manually implement setters and getters. This is my primary motivation for defining and using properties - it was important enough that I wrote a simple property implementation. David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Stefan Strasser wrote:
Am Tuesday 20 October 2009 22:07:28 schrieb Matthew Chambers:
Do you plan to have a macro for defining simple/trivial properties with a single line?
I think that this is the only thing that's missing from c++, and that it doesn't need a C# properties syntax.
the C++ "properties" syntax is, for example (taken from tr1::unordered_map):
float max_load_factor() const; void max_load_factor(float z);
I wouldn't even consider your proposed properties syntax "syntactic sugar". it's just a different syntax, not a better one imho.
so if there's anything missing from c++ it would be something like
#define BOOST_TRIVIAL_PROPERTY(T,name) \ T name() const{ return _name; } \ void name(T __name){ _name=__name; } \ T _name;
I don't believe a trivial property does very much. While a trivial style property such as you mention above could be part of any C++ "property" implementation, what is minimally needed beyond that is what the OP's property implementation provides, which is the ability to have some sort of backing function to set the property at the very least.
Am Wednesday 21 October 2009 05:51:39 schrieb Edward Diener:
the C++ "properties" syntax is, for example (taken from tr1::unordered_map):
float max_load_factor() const; void max_load_factor(float z);
I wouldn't even consider your proposed properties syntax "syntactic sugar". it's just a different syntax, not a better one imho.
so if there's anything missing from c++ it would be something like
#define BOOST_TRIVIAL_PROPERTY(T,name) \ T name() const{ return _name; } \ void name(T __name){ _name=__name; } \ T _name;
I don't believe a trivial property does very much. While a trivial style property such as you mention above could be part of any C++ "property" implementation, what is minimally needed beyond that is what the OP's property implementation provides, which is the ability to have some sort of backing function to set the property at the very least.
I'm not sure if we misunderstood each other or if we just disagree. so for clarification: a "backing function to set the property" would be implemented in pure c++, without any property class: void max_load_factor(float z){ ... } and replaces the formerly used BOOST_TRIVIAL_PROPERTY(float,max_load_factor); (or better, the property object David proposed) so what I was trying to say is that C++ already has an established syntax for properties, except for trivial properties that automatically implement getters/setters. and that there is no need for another, incompatible, properties syntax, which I don't even consider "better", just "different".
2009/10/20 Matthew Chambers <matthew.chambers@vanderbilt.edu>
Peder Holt wrote:
It now compiles without warnings, also for classes with virtual members. Operator support is added for operator*. http://codepad.org/A4vaAMPZ
Regards Peder
Very nice. Do you know how reliable your reliance on UB is on the major
platforms? If it works on MSVC 9+, GCC 4.1, and darwin, that's enough for me.
I guess the only way to find out is testing the method on several compilers and setups. My assumptions are as follows: I assume that the address of a member in class A relative to the address of A is the same for all instances of A. I also assume that if you have multiple inheritance etc. this will hold for all classes in the inheritance hierarchy.
This holds for the simple test cases that I have made, but I have no guarantee that this is true for all cases. Here is a link to the test battery that I have been using to test this with GCC and VC8. If anyone has suggestions to scenarios that I haven't covered or wants to try this out on their favorite compiler, please do so. http://codepad.org/xDx64zRE Do you plan to have a macro for defining simple/trivial properties with a
single line? A more sophisticated macro could define the functions to use for the getter/setter (similar to how Managed C++ and C++/CLI do it AFAIK). Just like in C#, it encourages good design from the start of an implementation: the first iteration can use properties backed by simple member variables, while future implementations may use a more complicated backend without the interface ever needing to change (and without resorting to set/get syntax). That allows the design focus at first to be on the interface instead of worrying about doing a good job on both the interface and the implementation.
Creating the simple macros is no problem, but we first have to find out if properties has a place in C++ and with what syntax, and if this is the way to go to solve the problem.
-Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello, Matthew. Wednesday, October 21, 2009 at 12:07:28 AM you wrote: MC> Peder Holt wrote:
It now compiles without warnings, also for classes with virtual members. Operator support is added for operator*. http://codepad.org/A4vaAMPZ
Regards Peder MC> Very nice. Do you know how reliable your reliance on UB is on the major MC> platforms? If it works on MSVC 9+, GCC 4.1, and darwin, that's enough MC> for me.
MC> Do you plan to have a macro for defining simple/trivial properties with MC> a single line? A more sophisticated macro could define the functions to MC> use for the getter/setter (similar to how Managed C++ and C++/CLI do it MC> AFAIK). Just like in C#, it encourages good design from the start of an MC> implementation: the first iteration can use properties backed by simple MC> member variables, while future implementations may use a more MC> complicated backend without the interface ever needing to change (and MC> without resorting to set/get syntax). That allows the design focus at MC> first to be on the interface instead of worrying about doing a good job MC> on both the interface and the implementation. FYI: http://lists.boost.org/Archives/boost/2008/07/139609.php I use this library during last year in two quite big projects. Now this library supports: - Triviral properties (also support property initialization inside declaration) - Properties with setters/getters - Indexable properties (up to three dimensions) - Abstract properties - Runtime properties enumeration - Generic setters/getters by property name (in runtime) - Generic setters/getters with conversion from/to string (but not for all cases) - Generic serialization with boost::serialization-like interface. Properties supports full set of unary/binary operators, 'member access' operator, and some other useful things. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru
Sorry, but your design is flawed. This code should compile according to your design and the C# rules, but it doesn't. For it to actually be C# compliant, a property must take up no space at all, but yours does, unfortunately. Since you're embedding an object inside another object, I don't see how you can use this design to achieve that goal. No disrespect. -Sid Sacek struct driving { double distance; double time; driving( double d, double t ) : distance( d ), time( t ) {} template< typename Base > class driving_statistic : public Base { public: const double get() const { return self()->distance / self()->time; } }; BOOST_PROPERTY( driving, driving_statistic, speed ); }; //And usage: void test() { driving drv( 500, 10 ); double speed = drv.speed; size_t sz = sizeof( driving ); BOOST_STATIC_ASSERT( sizeof( driving ) == sizeof( double ) * 2 ); } -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peder Holt Sent: Monday, October 19, 2009 1:04 PM To: boost@lists.boost.org Subject: [boost] [property] interest in C# like properties for C++? I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it. Code sample: #include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream> class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused. BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); }; //And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); } The trick used is the following: class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; }; It currently support: Read/Write properties Read properties Write properties Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail. Regards Peder
Sid Sacek escribió:
Sorry, but your design is flawed.
This code should compile according to your design and the C# rules, but it doesn't. For it to actually be C# compliant, a property must take up no space at all, but yours does, unfortunately. Since you're embedding an object inside another object, I don't see how you can use this design to achieve that goal. No disrespect.
This is indeed true, but it will always be the case for a member object. Since the technique already relies on undefined behaviour (derreferencing a null pointer or calling offsetof on a non-POD type), it may do so again and pack all properties inside a union. This will fix the space overhead to the minimum, regardless of the number of properties. Check Boost.Proto internals for the definition of virtual_member, it applies such trick. I don't think I'll choose syntactic sugar if the cost is relying on undefined behaviour. Agustín K-ballo Bergé.-
2009/10/20 Agustín K-ballo Bergé <kaballo86@hotmail.com>
Sid Sacek escribió:
Sorry, but your design is flawed.
This code should compile according to your design and the C# rules, but it doesn't. For it to actually be C# compliant, a property must take up no space at all, but yours does, unfortunately. Since you're embedding an object inside another object, I don't see how you can use this design to achieve that goal. No disrespect.
This is indeed true, but it will always be the case for a member object.
Since the technique already relies on undefined behaviour (derreferencing a null pointer or calling offsetof on a non-POD type), it may do so again and pack all properties inside a union. This will fix the space overhead to the minimum, regardless of the number of properties. Check Boost.Proto internals for the definition of virtual_member, it applies such trick.
Thank you! I'll look into that. I hadn't thought of using unions to get the size down. I'll look into this.
I don't think I'll choose syntactic sugar if the cost is relying on undefined behaviour.
I actually tend to agree with you, but I thought the idea was kind of neat,
so I thought I should post it. Using properties like this will be syntactic sugar, but the implementation is black box. It would be interesting to see for what cases and compilers this will fail. I have tested it for different scenarios (virtual base classes, multiple base classes, classes with rtti etc) for VC8 and GCC (online compiler) and they do the right thing.
Agustín K-ballo Bergé.- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it.
Code sample:
#include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream>
class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused.
BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); };
//And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); }
The trick used is the following:
class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; };
It currently support: Read/Write properties Read properties Write properties
Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail.
Thanks ! Very clever. The self() idea is very worthy, and I may steal it for my own idea/implementation about "property" in C++, which I have been working on indefinitely ( may never get completed to my satisfaction ). The metaprogramming is breathtaking, if I can slowly figure it out <g> . In my own implementation a "property" does not need to be nested class but can exist as a global/static object, so I don't know how I can use your self() idea but I really appreciate your doing it and publishing it.
<snip>
Thanks ! Very clever. The self() idea is very worthy, and I may steal it for my own idea/implementation about "property" in C++, which I have been working on indefinitely ( may never get completed to my satisfaction ). The metaprogramming is breathtaking, if I can slowly figure it out <g> . In my own implementation a "property" does not need to be nested class but can exist as a global/static object, so I don't know how I can use your self() idea but I really appreciate your doing it and publishing it.
Thank you :) It would be very interesting to look at your implementation to see how you tackle the problem. Have you posted your code anywhere that I can look? Actually, the property implementation does not have to be a nested class. The following: template<typename Base> class Property_Length : public Base { public: const double& get() const { return sqrt( Base::self()->X*Base::self()->X+ Base::self()->Y*Base::self()->Y+ Base::self()->Z*Base::self()->Z ); } }; template<typename Base> class Property_Double : public Base { public: const double& get() const {return m_arg;} void set(const double& arg) {m_arg=arg;} private: double m_arg; }; class Vector { public: BOOST_PROPERTY(Vector,Property_Double,X); BOOST_PROPERTY(Vector,Property_Double,Y); BOOST_PROPERTY(Vector,Property_Double,Z); BOOST_PROPERTY(Vector,Property_Length,Length); }; is legal. (but untested.) Regards Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
<snip>
Thanks ! Very clever. The self() idea is very worthy, and I may steal it for my own idea/implementation about "property" in C++, which I have been working on indefinitely ( may never get completed to my satisfaction ). The metaprogramming is breathtaking, if I can slowly figure it out <g> . In my own implementation a "property" does not need to be nested class but can exist as a global/static object, so I don't know how I can use your self() idea but I really appreciate your doing it and publishing it.
Thank you :)
It would be very interesting to look at your implementation to see how you tackle the problem. Have you posted your code anywhere that I can look?
No, I have no posted it anywhere yet. I also have still to test all of it, and the parts I have tested have been only on VC9 although I feel confident it should work on gcc and Comeau also. I am unfortunately, in a way, one of those people who feel that an implementation of mine must be complete as far as code, documentation, and testing are concerned before I can post/release it anywhere. I am also much less of a template metaprogrammer, largely by practice, than you and other Boost programmers so my implementation of "property" is much simpler in template metaprogramming techniques than what you present. Also my goals are different. If you are still interested I would be glad to zip up what I have done so far, albeit with no documentation as yet although I would be willing to discuss it privately, and send it directly to you, but I fear this private exchange is not in the spirit of Boost. You of course would have no obligation to pay any attention to it if you like, especially since my goals for a C++ "property" implementation are somewhat different. I can not see posting it anywhere until I am happy that my implementation is complete given my goals, but I can assure you that my reply was not an effort to "tease" you or anyone with my own implementation but rather simply to show my interest in a C++ "property" implementation and in appreciation of you own techniques in implementing your C#-like property.
Actually, the property implementation does not have to be a nested class.
What I should have said is that my "property" does not have to be a variable which is a member of a class. It can be a global/static variable. So there is not necessarily a "self", which is an enclosing class pointer. Also my property comes in many flavors, with slightly different names, corresponding to the various ways in which one can refer to the backing "data". In some of those flavors no actual data in memory needs to even exist. This latter may of course be seen as overkill. However I intend to study your code to see if it is possible to use the self() technique when a flavor of my property is used as a member of a class, and still be able go discard the self() implementation when it is not used as a member of a class, without having to bifurcate my property flavors under more different names.
The following: template<typename Base> class Property_Length : public Base { public: const double& get() const { return sqrt( Base::self()->X*Base::self()->X+ Base::self()->Y*Base::self()->Y+ Base::self()->Z*Base::self()->Z ); } }; template<typename Base> class Property_Double : public Base { public: const double& get() const {return m_arg;} void set(const double& arg) {m_arg=arg;} private: double m_arg; }; class Vector { public: BOOST_PROPERTY(Vector,Property_Double,X); BOOST_PROPERTY(Vector,Property_Double,Y); BOOST_PROPERTY(Vector,Property_Double,Z); BOOST_PROPERTY(Vector,Property_Length,Length); };
is legal. (but untested.)
Yes, this is understandable, thanks ! Your BOOST_PROPERTY properties must still be members of a class, but that follows perfectly your design goals of emulating C#-style properties.
I have written another example that override the assign operator, take a look http://tiannocky.spaces.live.com/blog/cns!D80340372C1B949E!346.entry Though, the comments are in Chinese, the code is C++
Date: Mon, 19 Oct 2009 19:03:52 +0200 From: peder.holt@gmail.com To: boost@lists.boost.org Subject: [boost] [property] interest in C# like properties for C++?
I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it.
Code sample:
#include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream>
class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused.
BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); };
//And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); }
The trick used is the following:
class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; };
It currently support: Read/Write properties Read properties Write properties
Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail.
Regards Peder
_________________________________________________________________ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/soc...
participants (17)
-
Agustín K-ballo Bergé -
Andrew Sutton -
Bo Persson -
David Brownstein -
Edward Diener -
Gennadiy Rozental -
Jeremiah Willcock -
Matt Chambers -
Matthew Chambers
-
Nocky Tian -
Olaf van der Spek -
Peder Holt -
Sergey Sadovnikov -
Sid Sacek -
Stefan Strasser -
Stewart, Robert -
vicente.botet