C++/CLI Properties - Syntactic sugar for accessor methods

Introduction

Properties are entities that behave like fields but are internally handled by getter and setter accessor functions. They can be scalar properties (where they behave like a field) or indexed properties (where they behave like an array). In the old syntax, we had to specify the getter and setter methods directly in our code to implement properties - wasn't all that well received as you might guess. In C++/CLI, the syntax is more C#-ish (purely coincidental I am sure) and is easier to write and understand. This article goes through the syntax for both scalar and indexed properties with examples where suitable.

Scalar properties

private:
    int _StudRank = 0;
public:
    property int StudRank
    {
        int get()
        {
            return _StudRank;
        }
        
        void set(int x)
        {
            _StudRank = x;
        }
    }

The get method is called when the property is read and the set method is called when the property is written into, thereby giving us an option for data-hiding within the class. The compiler emits methods get_StudRank and set_StudRank as the getter and setter methods - but it won't let you access these functions directly - you'll have to use the property name (just like you'd use a field). You can optionally omit either the get method (in which case you have a write-only property) or the set method (a read-only property).

Trivial properties

For trivial properties, the compiler emits the getter and setter methods for you :-

property String^ TrivialString;

A private field of the same type as the property is generated in the IL called '<backing_store>TrivialString' - note how quotes are used, so that there's no great risk of any CLI language allowing a variable of the same name thereby causing a collision. Bare-minimum getter and setter methods are generated - the getter simply returns this private field and the setter sets the passed in value to the private field. Trivial properties are useful when you have a situation where you might need to customize a field's accessor functions in future, but at present you have no specific customization to do. Using trivial properties eliminates the need to use a public field for now and having to later convert it to a property - this could cause problems as it changes the very signature of the class - for example reflection treats fields and properties separately.

Properties and inheritance

Properties can be virtual (which results in virtual getter and setter methods) though the derived class needs to have a property with the same name and the same type. Below sample should make it clear :-

ref class Base
{
public:
    ref struct SBaseData
    {
    public:
        SBaseData()
        {
            x = 0;
        }
        SBaseData(int n)
        {
            x = n;
        }
        int x;        
    };
private:
    SBaseData^ _bd;
public:
    Base()
    {
        _bd = gcnew SBaseData();
    }
    virtual property SBaseData^ Data
    {
        SBaseData^ get()
        {
            return _bd;
        }
        void set(SBaseData^ val)
        {
            _bd->x = val->x;
        }
    }
};

Notice the property definition in the above code (bolded out for your convenience). Now here's the derived class :-

ref class Derived : Base
{
public:
    ref struct SDerivedData : Base::SBaseData
    {
    public:
        SDerivedData(int n1, int n2) : SBaseData(n1)
        {
            y = n2;
        }
        SDerivedData() : SBaseData()
        {
            y = 0;
        }
        int y;        
    };
private:
    SDerivedData^ _bd;
public:
    Derived()
    {
        _bd = gcnew SDerivedData();
    }
    
    virtual property SBaseData^ Data
    {
        SBaseData^ get() override = Base::Data::get
        {
            return _bd;
        }
        void set(SBaseData^ val) override = Base::Data::set
        {
            try
            {
                _bd->x = val->x;
                _bd->y = safe_cast<SDerivedData^>(val)->y;
            }
            catch(InvalidCastException ^)
            {
                //log an error

            }
        }
    }
};

Notice how we've explicitly used the override keyword for both the get and the set (if we don't then new is assumed). Also note the use of the safe_cast (chances are low that this method gets called for a non-Derived object and if at all so, it'll be due to a programming error).

Static properties

private:
    static int _InstanceCount = 0;
public:
    static property int InstanceCount
    {
        int get()
        {
            return _InstanceCount;
        }
    }

Properties can be static (in which case the generated accessor methods are static too). Off-topic perhaps, but note how static fields can be directly initialized (pretty handy).

What if I have a get_ or set_ method matching the name of a property?

You'll get a C3675 error :-)

/*** This won't compile - Error C3675 
    static int get_InstanceCount() { return 0; }
***/

It's very strict about this, in fact it won't even let you have a method with different return type and arguments.

char get_InstanceCount(char) { return 0; } // won't compile either 

Indexed properties

Indexed properties allow array like access on an object and there's also support for a default indexed property - essentially a nameless property which lets you directly use [] on the object. Below example features both named and default index properties. I believe C#ers call indexed properties as indexors so perhaps you might see these two words used interchangeably.

ref class R
{
private:
    Hashtable^ h;
public:
    R()
    {
        h = gcnew Hashtable();
    }

    //Named property

    property int Age[String^]
    {
    protected:
        int get(String^ s)
        {
            if(h->ContainsKey(s))
            {
                for each(DictionaryEntry de in h)
                {
                    if(s->CompareTo(de.Key) == 0)
                        return (int)de.Value;
                }
            }
            return 0;
        }    

        void set(String^ s, int age)
        {
            h->Add(s,age);
        }
    }

    //Default property

    property int default[String^]
    {
        int get(String^ s)
        {
            return Age[s];
        }

        void set(String^ s, int age)
        {
            Age[s] = age;
        }
    }    
};

Notice how I've specified the named property accessor methods as protected. In fact you can have different access levels for get and set methods if you want to. For the default property, specify default as the name of the property. The default property gets compiled to a property called Item in the resulting IL and the class is given the custom attribute System::Reflection::DefaultMemberAttribute as follows - System::Reflection::DefaultMemberAttribute("Item").

You can use it like :-

R^ r = gcnew R();

r["Nish"] = 27;
r["Smitha"] = 15;
r["Chris"] = 21;
r["Don"] = 87;

Console::WriteLine(r["Nish"]);
Console::WriteLine(r["George"]);
Console::WriteLine(r["Smitha"]);
Console::WriteLine(r["Don"]);
Console::WriteLine(r["Bert"]);

Conclusion

While properties are basically syntactic sugar for accessor functions, the new syntax is definitely a far improved one over the old syntax. I personally wish that they hadn't decided to compile default indexed properties into a property called Item - this prevents you from using Item as a named indexed property - they could easily have generated a GUID or something as the name for the default indexed property and allowed us to use Item for our own purposes. Considering that MSIL uses the DefaultMemberAttribute attribute to identify the default indexed property, I am pretty sure they were forced to do it this way to be as compatible with C# as possible. Feedback is appreciated including heavily critical ones.