On 1 Mar 2010, at 20:03, Daniel Larimer wrote:
On Mar 1, 2010, at 2:48 PM, Zachary Turner wrote:
On Mar 1, 2010, at 1:39 PM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 1 Mar 2010, at 18:24, Germán Diago wrote:
for trivial properties it's the same. But maybe in the future properties will be extended with some metadata. anyway, for trivial properties it's the same.
I don't understand what your library does. Having your most simple example say it does nothing at all is not helpful!
Where properties are useful is eliminating the need to define "setters/getters" while ensuring that no one ever gets a direct reference to the actual data. This is critical for multi-threaded programs where you want to reduce "shared state".
My issue with the approach is that it drastically increases the size of your object and the cost of calling constructors.
Presumably each "int" now has 2 member function pointers. Thus 4 bytes becomes 20 bytes (best case, 64 bit ptrs) and more on compilers that have bigger member function pointers.
What exactly do you mean? struct X { int i; }; class X { int i; public: int geti() { return i; } void seti(int _i) { i = _i;} }; Are both the same size (sizeof(int)). Further, on any reasonable compiler geti, seti and in fact X itself will be totally optimised away, leaving just the same code as if we had used a raw int. Chris