Object properties for C++

Hello and thanks for the comments.

I personally believe that this line of solutions will not help as much as you probably hope it will. The trouble is that it requires (even) more typing then just writing the accessor methods and declaring the private member variable to persist the property.

I don't think so, for the following reasons:

1. in 99% of cases properties will be of read-write 'variable' type, so the actual code to write is

   property[class, type] name;

   and

   name(this, &class::name_changed)

   . The actual function to call when the property is changed it can be an already existing function. For example, in a GUI toolkit, most properties will be tied either to method 'redraw/update' or 'resizeFromContent'.
2. Using properties has the advantage of a non-bloated API. The user of the library only knows the property name. There is no need to remember naming conventions like 'get' or 'is' or 'has'.
3. The header file becomes less bloated.
4. It becomes easier to maintain documentation, as there exists one piece of documentation of the property. With methods, one needs to put the same information in the getter and setter method, or put the information in one of them and a link in the other.
5. Documentation becomes easier to read. The docs are not bloated with tens of little functions that do nothing more than setting and getting data.
6. It is easier to prototype a class, because the class can start with plain data members, and then data members can later be replaced with properties, without breaking the code.
7. Intellisense works better and faster since a class has less members.
8. A reflection library can be made that registers the properties in a class object.

class *property* is totally unnecessary.

Again, I disagree. Having the word 'property' on the source code makes the thing easier on the eye, especially after you come back to the code. For example:

class Foo {
public:
    property[Foo, int] data1;
    property[Foo, float] data2;
    property[Foo, double] data3;
};

class Foo {
public:
    read_write[Foo, int] data1;
    read_write[Foo, float] data2;
    read_write[Foo, double] data3;
};

It's clear that using 'property' has the advantage of showing immediately what the member is about. The term 'read_write' is not so obvious.

It also offers constructors which if you try to use will cause compiler errors.

That is a design decision: you can't construct the wrong property. Furthermore, the wrong constructor thing will not go away if the policy classes are used directly.

1. remove class property completely, and 2. define a few types instead. Something like this:

I don't think that what you propose is an improvement. Let's see it with an example:

class Foo {
public:
    property[Foo, int] data1;
    property[Foo, float] data2;
    property[Foo, double] data3;
};

class Foo {
public:
    property[Foo, int]::rwv data1;
    property[Foo, float]::rwv data2;
    property[Foo, double]::rwv data3;
};

It's clear to me that my approach is better. You type less, with the exact same functionality.

Too bad C++ does not support templated templates

Actually, C++ 98 does. It is MSVC 6.0 that does not. I can do the following with VC 7.0 and GCC:

class Foo {
public:
    property[Foo, int, read_write, variable] data1;
};

Since that does not work for all C++ compilers, I may put there a macro:

#define PROPERTY(CLASS, TYPE, ACCESS, STORAGE)\
    property[CLASS, TYPE, ACCESS[CLASS, TYPE, [STORAGE[CLASS, TYPE ] ] ]

The classes *variable* and *interface* "feel" a little strange with no public part, don't they ?

No more strange than abstract classes. In fact, with C++, declaring no public members is a legal way of doing abstract classes that also provide some implementation.

What would be probably better is to declare instances of those classes as member variables in the corresponding policy classes. After all the relationship between the policy classes and the implementation classes is IS_IMPLMENTED_IN_TERMS_OF and not IS_A.

Again, I disagree: a property IS_A variable or IS_An interface to a data member. A property IS_A read-write/read-only/write-only construct.

They are merely a better, safer design considerations.

Thanks a lot for the input. I think I have found a way to do what GCC/VC++ 7.0 does. Stay tuned!

I believe what is necessary is an extension to the language, something "native".

Of course, something native is much better, there is no need to say that. But I don't see it coming in the C++ world anytime soon.

I meant that the property class did not add or change anything on top of the policy class.

Syntactic sugar is important, otherwise we would all be programming in assembly.

If I *should not*, then you should not be offering it.

You're right, but C++ does not have constructor promotion from base to inheriting class. Therefore constructors need to be there in the derived class, too. It's a C++ limitation. Fortunately, the error is caught at compile-time.

As far as I remember the policy classes did have only the correct constructors.

Yes, but in either case (either in your way, or in mine), if the correct constructing call is not called, the compiler will complain. There is no actual difference.

Exceptional C++, item 24: Uses and abuses of Inheritance

Effective C++, Item 40: Model "has-a" or "is-implemented-in-terms-of" through layering.

Effective C++, Item 44: Say what you mean; understand what you're saying.

Effective C++, Item 27: Explicitly disallow use of implicitly generated member functions you don't want

Thanks a lot for the tips, but I have quite a big experience in C++ to know what I am doing (and support my view with concrete arguments). I may not remember all of C++ in one go, but I have used all its capabilities in one way or another. The problem is I have to work around the serious limitations of VC++ 6.0 and GCC, especially regarding templates.

property<MyClass, int, read_write, interface> data;

property<MyClass, int, read_write, other_way> data;

property<MyClass, int> data;

property<MyClass, int>::rwv data;

property<MyClass, int, read_write, interface> data;

property<MyClass, int> data;

property<MyClass, int, read_write, interface> data;

property<MyClass, int>::rwv data;

property<MyClass, int>::rwi data;

rwv
rwi
rwr
rov
roi
ror
wov
woi
wor

read_write
read_only
write_only
variable
interface
remote

rwv
rwi
rwr
rwd
rov
roi
ror
rod
wov
woi
wor
wod

read_write
read_only
write_only
variable
interface
remote
debug

rwv
rwi
rwr
rov
roi
ror
wov
woi
wor
rwvd
rwid
rwrd
rovd
roid
rord
wovd
woid
word

read_write
read_only
write_only
variable
interface
remote
debug<variable>
debug<interface>
debug<remote>

class Foo {
public:
   int data();
};

class Bar : public Foo {
public:    
};

class Foo {
public:
   int data();
};

class Bar {
public:    
   int data() { return foo.data(); }

private:
    Foo foo;
};

1. It allows for less typing, since the user would not have to type the property kind in 99% of cases (not even bother with intellisense).
2. It makes intellisense faster.
3. It is more intuitive to combine things together than choosing from a list of predefined configurations. The mental model is better: the programmer selects behaviours by mixing and matching, instead of selecting from a ready-made recipie.
4. It is easier to extend for the API user, since the user will only need to know new selector keywords.
5. Extending the library with new keywords will not force old code to be recompiled. It's better for backwards compatibility.

• you should be more honest, more sincere. If you think my design sucks, tell me that "your design sucks". Don't wrap it up in a few "intelligent" wordisms.
• learn how to debate. Debating means presenting arguments. You don't have arguments? shut the f*** up then. I know I do so when I don't have arguments.