No, they're not. Properties are just pairs of methods (get and set,
where either is optional) - you can have properties which don't have
any variables at all.

The *syntax* is similar to field access (for the most part) but they're
not conceptually the same.

To use a "public void function" to get a value from a class, you'd have to  
pass another parameter by reference.  That seems kind of messy to me.

Ignoring that though, yes, you're right...in other languages that do not  
explicitly define the concept of a property, you can still effectively do  
the same thing by implementing setter and getter functions.  For example,  
instead of this C# code:

    private int _i;

    public int I
    {
        get { return _i; }
        set { _i = value; }
    }

You could write this C++ code:

    private: int _i;

    public:
        int GetI() { return _i; }
        void SetI(int i) { _i = i; }

However, those functions don't mean anything special to the compiler in  
C++.  One thing about properties is that they alert the compiler that the  
member is essentially a public value member of the class, as opposed to  
some method that just returns some value (whether that's a number that's a  
result of a calculation, an instance of something being instantiated,  
etc.)  That is, it's not just the result of some computation, but rather  
some value inherent in the state of the class.  Thus the name "property".

There are a variety of benefits to this, most of them relating to code  
maintainability.  But one of the most obvious, non-maintenance-related  
benefits is that the property can be treated specially by various things.  
Class serialization works because of properties, as does data binding.  
You could shoe-horn stuff like that into regular C++ code, but it would be  
clumsy and clearly hacked in.  Properties provide a nice, clean way to  
construct behavior around the idea of properties of a class.

There's a lot of stuff in .NET, and especially in C# (though I guess  
managed C++ has its own versions of much of this...haven't used it much  
myself, so I don't know firsthand), that does really do anything that you  
couldn't do some other way.  What it does do is make it a lot easier, and  
maintainable.

Where you see something that "complicates the program" I see something  
that actually simplifies it.  Yes, it introduces yet another new concept  
to the language (potentially complicating the language), but that new  
concept allows you to in a much simpler way implement the same thing that  
you should have been doing all along, in a way that makes that  
implementation more explicit both to you, the compiler, and other  
components within .NET.  That very much simplifies a lot of things.

Pete

This is actually how it works behind the scene. But for example the object browser and the language will see this as single property instead of having two unrelated functions. Also they could be inconsistant in scope or types. Plus a tool couldn't relate those two functions as being paired unless you are using strict convention, plus you could use unrelated types etc.... Plus you would have to put attributes where ? etc... etc...

IMO this is simplficaiton rather than than a complication.

--
Patrice

 I know,
 Let me clarify. What I am trying to say is that I can still use a public void function to set and get the value of a private variable instead of public property in class implementation.

 So, why should I use "property" in c++.net and even Visual Basic 6.0 ? It seems to complicate the program.

 "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message news:b0ac48a016afc8c99698918b0ed0@msnews.microsoft.com...
 > > Thanks, I see,
 > > but what about in traditional Visual C++, (ie Viusal C++ 6.0 ) and
 > > even Java
 > > ?
 >
 > All these languages CAN do this.
 >
 > The point is that good programming avoids this technique.
 >
 > Properties hide/protect the internals of the class.
 >
 > Public variables are as bad as global variables.
 >
 > There is no way to determine or limit their access.
 >
 > --
 > Rory
 >
 >