C#-Like Properties in Native C++

C#-like properties in native C++?

In .NET properties are syntactic sugar for the real get and set functions which are emitted behind the scenes (in fact they are more than syntactic sugar because properties are emitted in the resulting IL and could be used with Reflection). So in C++ you would need to explicitly write those functions as there's no such notion as property.

public fields or C# like properties in C++?

Rather than creating separate getter and setter functions, you can have a function which returns a reference which can be used either way:

public:   
    int &max_hp() { return maxHP; }

Unlike just delaring maxHP public, this allows you to place a breakpoint to see when the variable is accessed, and if you later want to add conditions or logging you can do so without changing your class interface.

Can I marshal data from a C/C++ struct into a C# struct with properties?

For anyone who comes here in future, my solution was to add the properties after the struct fields (as suggested by GSerg, David Heffernan and Simon Mourier in the comments).

So my struct now looks a little something like this:

struct MyNativeStruct 
{
    private double ExampleField;
    public double ExampleProperty => ExampleField;
}

Possible to convert C# get,set code to C++

Are you using C++/CLI? If so this is the property syntax

public:
  property std::string Temp { 
    std::string get() { return sTemp; }
    void set(std::string value) { sTemp = value; this->ComputeTemp(); } 
  }

If you are trying to use normal C++ then you are out of luck. There is no equivalent feature for normal C++ code. You will need to resort to getter and setter methods

public:
  std::string GetTemp() const { return sTemp; } 
  void SetTemp(const std::string& value) { 
    sTemp = value;
    this->ComputeTemp();
  }

Use C# properties in unmanaged C++ code

I am dealing with similar issues at my work where my primary task is to write managed interfaces to certain high perfromance, low latency dlls, this involves simple cases where I have to wrap the native classes using simple c++/cli containing a raw pointer to the native class or more complex issues where the native code is a server side publisher and the managed code has to subscribe to it using delegates ie they have to be converted to native callbacks.
.NET under the hood is a sophisticated COM server as far as I know. It is possible to write .net assemblies with the ComVisible attribute set to true then it acts as a classic COM component and then it is possible to use it from the native C++ code as a COM component. The reverse that is to use native code from managed can be achieved using the DllImport attributes and all the Marshaling can be fine tuned by the various attributes like the StructLayoutAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx) and the MarshalAsAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx)
I am also using sometimes the unsafe keyword as well. I have to deal with high performance code so in some cases it is that after profiling that I know which is the best solution. Whether it is the warpper class solution that you have mentioned or the classic COM way, or some kind of hybrid with some caching, object pooling etc.

Hope that helps. :)

Apologies if that looks a bit disorganised. It is very late here. :)

Does java have something similar to C# properties?

No, Java does not have the equivalence. It only has accessor and mutator methods, fancy names for getter and setter methods. For example:

public class User {
    private String name;

    public String getName() { return this.name; }
    public void setName(String name) { this.name = name; }
}

properties in C#

This feature is called Auto implemented properties and introduced with C# 3.0

In C# 3.0 and later, auto-implemented properties make
property-declaration more concise when no additional logic is required
in the property accessors. They also enable client code to create
objects. When you declare a property as shown in the following
example, the compiler creates a private, anonymous backing field
that can only be accessed through the property's get and set
accessors.

class Customer
{
    // Auto-Impl Properties for trivial get and set 
    public double TotalPurchases { get; set; }
    public string Name { get; set; }
    public int CustomerID { get; set; }

For your question

What is the difference between the two?

In your case, none. Since you are not doing anything while setting or retrieving the value, but suppose you have want to do some validation or want to perform other types of check then :

private int someInt;
public int RetInt
{
    get
    {
        if (someInt > 0)
            return someInt;
        else
            return -1;
    }
    set { someInt = value; } // same kind of check /validation can be done here
}

The above can't be done with Auto implemented properties.

One other thing where you can see the difference is when initializing a custom class type property.

If you have list of MyClass
Then in case of Normal property, its backing field can be initialized/instantiated other than the constructor.

private List<MyClass> list = new List<MyClass>();
public List<MyClass> List
{
    get { return list; }
    set { list = value; }
}

In case of Auto implemented property,

public List<MyClass> SomeOtherList { get; set; }

You can only initialize SomeOtherList in constructor, you can't do that at Field level.

IEnumerable or List Property in a C# interface

If I understand your question correctly, you want to expose the list of Viewports. If that is the case, then you can:

1. Create a wrapper ref class for your native Viewport objects (just like you did for CLIOgreRenderWindow.
2. Have the IRenderWindow expose a IEnumerable with a getter.
3. In your C++/CLI implementation you could create a managed Array/List of the wrapper objects (based on the native objects), and return that.

Item #3 above is where you can do something different depending on your requirements (i.e. you could implement IEnumerable to yield one result at a time--though that's a bit more work).

---

Related Topics