Click here to Skip to main content
12,886,892 members (34,701 online)
Click here to Skip to main content
Add your own
alternative version


30 bookmarked
Posted 19 May 2005

Object properties for C++

, 19 May 2005
Rate this:
Please Sign up or sign in to vote.
A small library that gives C++ objects the ability to have properties.


The purpose of this library is to provide object properties. Instead of coding setter and getter methods, it is better to use properties because it is a more intuitive interface. Unfortunately, C++ does not offer native properties, but they can be emulated using templates and operator overloading, with a small memory overhead.


In order to use properties, you have to do include the file "property.hpp" in your project, then use the following fragment in your code:

#include "property.hpp"
using namespace cpp::properties;

The library is documented using Doxygen.

Declaring properties

The main class of this library is the class 'property'. It can be used to declare a property member. For example:

class MyClass {
    property<MyClass, int> data;

    MyClass() : data(this, &MyClass::data_changed, 5) {

    virtual void data_changed() {

In the above example, a property 'data' is declared. The property class has two main parameters: the type of owner class (needed in order to make a typesafe callback interface) and the type of the property value.

The property's callback (and optional initial value) must be declared at construction time. It can not be changed afterwards. Callback parameters must not be null, otherwise your application will crash.

Using properties

Usage of properties is like data members. For example:

MyClass obj; = 5;
int i = + 1;
cout << << endl;

Advanced options

The default property declaration declares a property that has a read-write value stored inside the property. The type of access (read-write, read-only, write-only) and the type of storage (variable or interface) can be changed by supplying different template parameters.

Interface properties are properties that don't store the value, but they call the owner object for getting and setting the value of the property.

For example, a read-write interface property must be declared like this:

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

    MyClass() :
        data(this, &MyClass::data_get, &MyClass::data_set) {

    int m_data;

    const int &data_get() const {
        return m_data;

    void data_set(const int &value) {
        m_data = value;

Usage of interface properties is exactly the same as variable properties. You can do different combinations of read_write, read_only, write_only and variable, interface to provide your own taste of a property.


As the included readme.txt explains, it's freeware, i.e. you can do whatever you like with it, except claim it for yours (of course!).


I have modified the library so that the declaration of different flavors of properties has become simpler. It works under MS VC++ 6.0 and DevCpp 4.9.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Achilleas Margaritis
Software Developer (Senior)
Greece Greece
No Biography provided

You may also be interested in...

Comments and Discussions

GeneralMy vote of 2 Pin
ColdShine24-Nov-08 10:36
memberColdShine24-Nov-08 10:36 
GeneralSize increase Pin
Michel Helms22-Nov-06 0:52
memberMichel Helms22-Nov-06 0:52 
GeneralMSVC versions Pin
Ernesto Savoretti7-Jun-06 15:31
memberErnesto Savoretti7-Jun-06 15:31 
GeneralNice, but... Pin
Yevhen Fedin26-May-05 23:11
memberYevhen Fedin26-May-05 23:11 
Generalimprovement! Pin
Achilleas Margaritis20-May-05 2:19
memberAchilleas Margaritis20-May-05 2:19 
GeneralRe: improvement! Pin
Chau<red>Johnthan20-May-05 8:05
memberChauJohnthan20-May-05 8:05 
GeneralRe: improvement! Pin
Achilleas Margaritis20-May-05 8:41
memberAchilleas Margaritis20-May-05 8:41 
GeneralMS specific solution Pin
cmk20-May-05 0:25
membercmk20-May-05 0:25 
GeneralNot bad Pin
Petar K. Shomov19-May-05 13:26
memberPetar K. Shomov19-May-05 13:26 
GeneralRe: Not bad Pin
Achilleas Margaritis19-May-05 23:00
memberAchilleas Margaritis19-May-05 23:00 

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;
    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 {
    property[Foo, int] data1;
    property[Foo, float] data2;
    property[Foo, double] data3;

class Foo {
    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 {
    property[Foo, int] data1;
    property[Foo, float] data2;
    property[Foo, double] data3;

class Foo {
    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 {
    property[Foo, int, read_write, variable] data1;

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


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!

GeneralRe: Not bad Pin
Petar K. Shomov20-May-05 6:29
memberPetar K. Shomov20-May-05 6:29 
GeneralRe: Not bad Pin
Achilleas Margaritis20-May-05 8:55
memberAchilleas Margaritis20-May-05 8:55 
GeneralRe: Not bad Pin
Petar K. Shomov20-May-05 12:55
memberPetar K. Shomov20-May-05 12:55 
GeneralRe: Not bad Pin
Achilleas Margaritis21-May-05 3:43
memberAchilleas Margaritis21-May-05 3:43 
GeneralRe: Not bad Pin
Petar K. Shomov22-May-05 8:05
memberPetar K. Shomov22-May-05 8:05 
GeneralRe: Not bad Pin
Achilleas Margaritis23-May-05 6:18
memberAchilleas Margaritis23-May-05 6:18 
GeneralRe: Not bad Pin
Tutu24-May-05 13:26
memberTutu24-May-05 13:26 
GeneralRe: Not bad Pin
barok25-May-05 20:52
memberbarok25-May-05 20:52 
GeneralRe: Not bad Pin
Achilleas Margaritis26-May-05 2:03
memberAchilleas Margaritis26-May-05 2:03 
GeneralRe: Not bad Pin
Achilleas Margaritis26-May-05 1:59
memberAchilleas Margaritis26-May-05 1:59 
GeneralRe: Not bad Pin
Anonymous14-Jul-05 14:53
sussAnonymous14-Jul-05 14:53 
GeneralNice Pin
Anonymous19-May-05 5:49
sussAnonymous19-May-05 5:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170424.1 | Last Updated 19 May 2005
Article Copyright 2005 by Achilleas Margaritis
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid