Thread: No properties in c++?

In a true OOP approach, the interface to data members is provided by access labels and member functions, instead. Check the tutorials on classes on this website.

Originally Posted by twomers

There are some people*who don't know what properties are, so perhaps a brief description would be handy ...

A somewhat ugly technique, in my opinion, derived from Visual Basic that manages access to data members.

get() and set() functions provide read and write access respectively to a class data member. They indirectly end up controlling the class interface. They also alter the syntax needed to access the members from what is common in C++. Once defined a data member is read and written like so,

int a = myClass.myMember // read

myClass.myMember = 10 // write

note the absence of the function call operator.

I didn't know C# imported that. You would expect it didn't, since the objective of the language was to provide C++ programmers a more comfortable medium to .Net.

However it can just happen that C# get and set implementations are more powerful than they were in Visual Basic. And the syntax to call them (they are always called indirectly) may have also been altered to include ().

>As far as I can see, c++ does not implement properties... At least not the way c# does?!
Correct. There are many things that C# has which C++ doesn't, and vice versa. You shouldn't have any expectations when learning a new language.

>Can you do this in a somewhat similar way in C++?
Use public member functions to gain access to private data members. C# properties are an elegant way of doing this safely, though it's an extraneous feature that only serves to complicate the language IMO.

>Doesn't that break encapsulation or something?
Not at all. In fact, it's identical to using member functions like we would in C++, except with a more convenient interface. Just because the most common description of properties looks like this:

Code:

get {
  return data_member;
}

set {
  data_member = value;
}

It doesn't mean that such a simpleminded approach is always, or even usually used. For example, both set and get don't have to be implemented, and their access levels can be different. Also, the block can contain as much code as you'd like to maintain control over how the actual data members are used. This is far from breaking encapsulation, which is more or less giving external users full control over the member, as if it were public.

>Whatever fucntion is needing those values should probably be a member of the class where the variables live.
This is another symptom of bad design that promotes monolithic classes. Naturally, any good programmer will refrain from abusing features. Judicious use of getters and setters is just fine, ne?

Originally Posted by Prelude

>Can you do this in a somewhat similar way in C++?
Use public member functions to gain access to private data members. C# properties are an elegant way of doing this safely, though it's an extraneous feature that only serves to complicate the language IMO.

One can even mimic the lack of a function call operator with the aid of references:

Code:

class myClass {
private:
    int val;

public:
    myClass(): val(0), value(val) {}
    myClass(int x): val(x), value(val) {}

    int &value;
};

int main() {

    myClass test;
    test.value = 12;
    std::cout << test.value;
}

>One can even mimic the lack of a function call operator with the aid of references:
Though that does break encapsulation.

completely