Click here to Skip to main content
11,635,098 members (74,849 online)
Click here to Skip to main content

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

, 11 May 2005 CPOL 151.7K 22
Rate this:
Please Sign up or sign in to vote.
Looks at the syntax for the declaration and use of properties in C++/CLI

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 Smile | :)

/*** 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Nish Nishant
United States United States
Nish Nishant is a Software Architect/Consultant based out of Columbus, Ohio. He has over 15 years of software industry experience in various roles including Lead Software Architect, Principal Software Engineer, and Product Manager. Nish is a recipient of the annual Microsoft Visual C++ MVP Award since 2002 (13 consecutive awards as of 2014).

Nish is an industry acknowledged expert in the Microsoft technology stack. He authored
C++/CLI in Action for Manning Publications in 2005, and had previously co-authored
Extending MFC Applications with the .NET Framework for Addison Wesley in 2003. In addition, he has over 140 published technology articles on CodeProject.com and another 250+ blog articles on his
WordPress blog. Nish is vastly experienced in team management, mentoring teams, and directing all stages of software development.

Contact Nish : You can reach Nish on his google email id voidnish.

Website and Blog

You may also be interested in...

Comments and Discussions

 
QuestionHow do I define the default indexer property in a cpp file? Pin
GreenKnight26-Oct-10 4:45
memberGreenKnight26-Oct-10 4:45 
AnswerRe: How do I define the default indexer property in a cpp file? Pin
Nishant Sivakumar26-Oct-10 5:05
mvpNishant Sivakumar26-Oct-10 5:05 
QuestionPossibility to define property in .cpp file? Pin
atzplzw13-Dec-07 14:27
memberatzplzw13-Dec-07 14:27 
AnswerRe: Possibility to define property in .cpp file? Pin
Saurabh.Garg22-Apr-08 16:29
memberSaurabh.Garg22-Apr-08 16:29 
GeneralGood articles on C++/CLI Pin
Andyb19798-Oct-07 23:50
memberAndyb19798-Oct-07 23:50 
Question"Is Much Easier to Write and Understand" - say what? Pin
Kevmeister6814-Feb-07 11:13
memberKevmeister6814-Feb-07 11:13 
I for one don't find the new property syntax "Much easier to write and understand", to use your term.

Simple example:

Old style:

__property int get_MyPropertyName( );
__property void set_MyPropertyName( int _value );

New style:

property int MyPropertyName
{
int get( );
void set( int _value );
}

My property declaration is now 5 lines long instead of 2 lines, and I have had to repeat the property type one more time.

But really, that's nothing compared to the VIRTUAL property accessors:

Whereas previously I would put "virtual" in front of my method name, and simply redefine the method like I normally would in C++ (I don't even need to repeat "virtual" in the derived class, since that is now implied), now I have to:

a. Muck around with this override keyword and specify the base-class function I am overriding.
b. Hope like hell that I don't forget to do this otherwise C++ "assumes" a new function.

And, finally, I used to be able to do this in Managed C++:

__property int get_MyPropertyName( );
__property void set_MyPropertyName( int _Value );
__property void set_MyPropertyName( AnotherType _Value );

And now it doesn't look like (but unconfirmed) that I can do this with C++/CLI.

I like a lot of the changes that C++/CLI has brought, but this isn't really one of them.
GeneralC++/CLI Properties implmentaion in cpp Pin
Blue Face6-Feb-06 7:03
memberBlue Face6-Feb-06 7:03 
GeneralRe: C++/CLI Properties implmentaion in cpp Pin
Nishant Sivakumar6-Feb-06 7:12
staffNishant Sivakumar6-Feb-06 7:12 
GeneralRe: C++/CLI Properties implmentaion in cpp Pin
Blue Face6-Feb-06 7:16
memberBlue Face6-Feb-06 7:16 
GeneralRe: C++/CLI Properties implmentaion in cpp Pin
Nishant Sivakumar6-Feb-06 14:01
staffNishant Sivakumar6-Feb-06 14:01 
QuestionRe: C++/CLI Properties implmentaion in cpp Pin
2bee22-Feb-06 23:53
member2bee22-Feb-06 23:53 
AnswerRe: C++/CLI Properties implmentaion in cpp Pin
Nishant Sivakumar23-Feb-06 0:59
staffNishant Sivakumar23-Feb-06 0:59 
GeneralRe: C++/CLI Properties implmentaion in cpp Pin
2bee23-Feb-06 3:13
member2bee23-Feb-06 3:13 
GeneralCpp and Header files Pin
Majid Shahabfar24-Jul-05 7:38
memberMajid Shahabfar24-Jul-05 7:38 
GeneralRe: Cpp and Header files Pin
Nishant Sivakumar24-Jul-05 18:37
staffNishant Sivakumar24-Jul-05 18:37 
GeneralRe: Cpp and Header files Pin
sgheeren14-Feb-07 7:54
membersgheeren14-Feb-07 7:54 
GeneralRe: Cpp and Header files Pin
Shivian4-Oct-07 19:52
memberShivian4-Oct-07 19:52 
GeneralRe: Cpp and Header files Pin
slimtim4-Oct-07 20:09
memberslimtim4-Oct-07 20:09 
GeneralRe: Cpp and Header files Pin
Shivian15-Oct-07 15:52
memberShivian15-Oct-07 15:52 
GeneralRe: Cpp and Header files Pin
Member 25334949-Feb-10 5:02
memberMember 25334949-Feb-10 5:02 
GeneralC#-ers Pin
SeveredCross13-May-05 18:43
memberSeveredCross13-May-05 18:43 
GeneralRe: C#-ers Pin
Nishant Sivakumar14-May-05 21:42
staffNishant Sivakumar14-May-05 21:42 
GeneralRe: C#-ers Pin
Jeffrey Sax17-May-05 15:02
memberJeffrey Sax17-May-05 15:02 
GeneralRe: C#-ers Pin
Nishant Sivakumar17-May-05 19:35
staffNishant Sivakumar17-May-05 19:35 
GeneralRe: C#-ers Pin
MattyT17-May-05 20:35
memberMattyT17-May-05 20:35 
GeneralRe: C#-ers Pin
Tom Archer30-May-05 17:35
memberTom Archer30-May-05 17:35 
GeneralRe: C#-ers Pin
Nishant Sivakumar2-Jun-05 18:47
staffNishant Sivakumar2-Jun-05 18:47 
GeneralRe: C#-ers Pin
terwin14-Sep-05 7:36
memberterwin14-Sep-05 7:36 

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

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

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.150728.1 | Last Updated 11 May 2005
Article Copyright 2005 by Nish Nishant
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid