Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C# properties using C++ Templates, is it Possible?

Reply
Thread Tools

C# properties using C++ Templates, is it Possible?

 
 
Brent Ritchie
Guest
Posts: n/a
 
      11-21-2005
Hello all,

I have been using C# in my programming class and I have grown quite fond
of C# properties. Having a method act like a variable that I can control
access to is really something. As well as learning C#, I think that it's way
overdue for me to start learning C++ Templates (I've been learning it for
about 5 years now).

I think that adding this type of functionality would be a good exercise
to help learn template programming. But befor I start, does anyone know if
it's even possible to add the functionality of C# properties to C++ using
templates? If so then that is all I need, but if not, can anyone suggest an
easy assignment to help learning template programming?


 
Reply With Quote
 
 
 
 
Matthias Kaeppler
Guest
Posts: n/a
 
      11-21-2005
Brent Ritchie wrote:
> Hello all,
>
> I have been using C# in my programming class and I have grown quite fond
> of C# properties. Having a method act like a variable that I can control
> access to is really something. As well as learning C#, I think that it's way
> overdue for me to start learning C++ Templates (I've been learning it for
> about 5 years now).
>
> I think that adding this type of functionality would be a good exercise
> to help learn template programming. But befor I start, does anyone know if
> it's even possible to add the functionality of C# properties to C++ using
> templates? If so then that is all I need, but if not, can anyone suggest an
> easy assignment to help learning template programming?
>
>


Hi, this is a very interesting question, and since I very much like the
concept of properties in C# (I generally think it's a very nice
language), I came up with this in C++:

---------- 8< --------------------------

class Foo {
public:
Foo(): X(0), Y(0), Z(0) {}
Property<int, GET> X;
Property<int, SET> Y;
Property<int> Z;
};

int main()
{
Foo f;
int val;

f.X = 5; // error, read only
val = f.X; // OK

f.Y = 5; // OK
val = f.Y; // error, write only

f.Z = 5; // OK
val = f.Z; // OK
}

---------- 8< --------------------------

Below is the code which realizes the Property class. It may still be
dirty in one way or another, it's just what I came up by hacking around:

---------- 8< --------------------------

enum permission { GET, SET, GETSET };

template <typename T, permission perm = GETSET>
class Property {
public:
Property(const T& val): value(val) {}
virtual operator T() { return value; }
protected:
T value;
};

template <typename T>
class Property<T, GET> {
public:
explicit Property(const T& val): value(val) {}
virtual operator T() { return value; }
protected:
T value;
};

template <typename T>
class Property<T, SET> {
public:
Property(const T& val): value(val) {}
protected:
T value;
};

---------- 8< --------------------------

For example, it may be a better idea to realize permissions through
inheritance, I don't know, maybe someone else can come up with something
more pleasing, but at least it already works.

Tell me what you think.

Regards,
Matthias
 
Reply With Quote
 
 
 
 
Roland Pibinger
Guest
Posts: n/a
 
      11-21-2005
On Mon, 21 Nov 2005 19:41:11 +0100, Matthias Kaeppler <(E-Mail Removed)>
wrote:
>
>For example, it may be a better idea to realize permissions through
>inheritance, I don't know, maybe someone else can come up with something
>more pleasing, but at least it already works.
>
>Tell me what you think.


There are some property implementations floating around the internet,
e.g. http://www.open-std.org/jtc1/sc22/wg...2004/n1615.pdf

Best wishes,
Roland Pibinger
 
Reply With Quote
 
Brent Ritchie
Guest
Posts: n/a
 
      11-22-2005
"Matthias Kaeppler" <(E-Mail Removed)> wrote in message
news:dlt4c7$ap4$01$(E-Mail Removed)-online.com...
> Brent Ritchie wrote:
>> Hello all,
>>
>> I have been using C# in my programming class and I have grown quite
>> fond of C# properties. Having a method act like a variable that I can
>> control access to is really something. As well as learning C#, I think
>> that it's way overdue for me to start learning C++ Templates (I've been
>> learning it for about 5 years now).
>>
>> I think that adding this type of functionality would be a good
>> exercise to help learn template programming. But befor I start, does
>> anyone know if it's even possible to add the functionality of C#
>> properties to C++ using templates? If so then that is all I need, but if
>> not, can anyone suggest an easy assignment to help learning template
>> programming?

>
> Hi, this is a very interesting question, and since I very much like the
> concept of properties in C# (I generally think it's a very nice language),
> I came up with this in C++:
>
> ---------- 8< --------------------------
>
> class Foo {
> public:
> Foo(): X(0), Y(0), Z(0) {}
> Property<int, GET> X;
> Property<int, SET> Y;
> Property<int> Z;
> };
>
> int main()
> {
> Foo f;
> int val;
>
> f.X = 5; // error, read only
> val = f.X; // OK
>
> f.Y = 5; // OK
> val = f.Y; // error, write only
>
> f.Z = 5; // OK
> val = f.Z; // OK
> }
>
> ---------- 8< --------------------------
>
> Below is the code which realizes the Property class. It may still be dirty
> in one way or another, it's just what I came up by hacking around:
>
> ---------- 8< --------------------------
>
> enum permission { GET, SET, GETSET };
>


I am hardly thrilled about the enumeration, but I see why you used it.
It does make things alot easier.

> template <typename T, permission perm = GETSET>
> class Property {
> public:
> Property(const T& val): value(val) {}
> virtual operator T() { return value; }
> protected:
> T value;
> };
>


Ok, I see the ctor and the selfnamed operator. This is fine and it is
very elegant. One question though where is operator= ? I used your
implementation and used operator= but it is not here. How does that work
exactly?

> template <typename T>
> class Property<T, GET> {
> public:
> explicit Property(const T& val): value(val) {}
> virtual operator T() { return value; }
> protected:
> T value;
> };
>


How did you achieve readonly access? Because the ctor is declared
explicit?

> template <typename T>
> class Property<T, SET> {
> public:
> Property(const T& val): value(val) {}
> protected:
> T value;
> };
>


I think I actually understand this for the most part. Except for how did
I do:

Property<int> i(3);
i == 2;

And not have operator= defined?

Like I said, I am new to template programming. Now I see how properties
could be implemented with C++. Now I want to try to create a derivative that
can have the () and operator= methods deferred (Fuction pointers) so that
Acces can be further restricted.

Thanks for the sample code although a little confusing I think I understand
most of it.
> ---------- 8< --------------------------
>
> For example, it may be a better idea to realize permissions through
> inheritance, I don't know, maybe someone else can come up with something
> more pleasing, but at least it already works.
>
> Tell me what you think.
>
> Regards,
> Matthias



 
Reply With Quote
 
Matthias Kaeppler
Guest
Posts: n/a
 
      11-22-2005
Brent Ritchie wrote:
> Ok, I see the ctor and the selfnamed operator. This is fine and it is
> very elegant. One question though where is operator= ? I used your
> implementation and used operator= but it is not here. How does that work
> exactly?


You could also use operator=. I used the copy constructor, which also
works. If it isn't declared 'explcicit', the compiler may use it to
convert from the parameter type to the class' type.

>
> How did you achieve readonly access? Because the ctor is declared
> explicit?


That's right. An explicit ctor must not be used for implicit type
conversion, so that's fine.

> I think I actually understand this for the most part. Except for how did
> I do:
>
> Property<int> i(3);
> i == 2;
>
> And not have operator= defined?


You would have to define operator==. My code was just supposed to
outline how one could implement a property, it's nowhere complete.
 
Reply With Quote
 
Matthias Kaeppler
Guest
Posts: n/a
 
      11-22-2005
Here's another Property implementation.

This time I left the whole template thing out completely. It only uses
the preprocessor, and feels way more like C# properties than anything
using templates:

class Outer {
public:

property (MyProp, int) {
self(MyProp, int) {
// init property
}

get(int) {
// do something
return value;
}

set(int) {
// do something
this->value = value;
}
} myProperty, anotherProperty;

};

You can then use it like this:

Outer o;
int val;

o.myProperty = val;
val = o.myProperty;

o.anotherProperty = o.myProperty;
assert (o.myProperty == o.anotherProperty);

This version uses the assignment operator rather than the copy constructor.

#define property(name,type) class name
#define self(name,type) private: type value; \
public: bool operator== (const type &rhs) const \
{ return this->value == rhs; } \
public: name ()
#define get(type) public: operator type ()
#define set(type) public: void operator= (const type &value)

However, complex types shouldn't be stored in a property because copying
will be too expensive. It also can't handle "deep" lookup of pointer
types. To achieve that, you will have to rely on template meta
programming I guess.

Regards,
Matthias
 
Reply With Quote
 
GB
Guest
Posts: n/a
 
      11-23-2005
Brent Ritchie wrote:
> Hello all,
>
> I have been using C# in my programming class and I have grown quite fond
> of C# properties. Having a method act like a variable that I can control
> access to is really something.


What is the advantage of

window.color = blue;

over

window.color(blue);

or even

window.change_color(blue);

Why not always use the function notation instead of having two different
notations depending on whether you decide to treat something as a
"property". I just don't understand the motivation for making a
distinction between changing or requesting "properties" and other forms
of object interaction.

Gregg
 
Reply With Quote
 
Brent Ritchie
Guest
Posts: n/a
 
      11-23-2005

"GB" <(E-Mail Removed)> wrote in message
news:wsRgf.7083$0h5.3886@dukeread10...
> Brent Ritchie wrote:
>> Hello all,
>>
>> I have been using C# in my programming class and I have grown quite
>> fond of C# properties. Having a method act like a variable that I can
>> control access to is really something.

>
> What is the advantage of
>
> window.color = blue;
>
> over
>
> window.color(blue);
>
> or even
>
> window.change_color(blue);
>


Really, the only difference (to me) is purely cosmetic. Although using
functions is one way of doing it, I would rather use window.color = BLUE
because it is a simple assignment with (probably) very simple error checking
needed.

> Why not always use the function notation instead of having two different
> notations depending on whether you decide to treat something as a
> "property". I just don't understand the motivation for making a
> distinction between changing or requesting "properties" and other forms of
> object interaction.
>


The driving force behind this is my lazyness and hatred of Accessor/Mutator
pairs. I Like to keep functions that are useful public, and not pollute the
class namespace with nearly useless get/set functions. This way I could hide
the implementation from other programmers who need not know about why
something works just that it does. Also I think properties enforce
encapsulation better. They give a simple interface to hide as many
implementation details as possible.

> Gregg



 
Reply With Quote
 
Ben Pope
Guest
Posts: n/a
 
      11-23-2005
Brent Ritchie wrote:
> "GB" <(E-Mail Removed)> wrote in message
> news:wsRgf.7083$0h5.3886@dukeread10...
>> Brent Ritchie wrote:
>>> Hello all,
>>>
>>> I have been using C# in my programming class and I have grown quite
>>> fond of C# properties. Having a method act like a variable that I can
>>> control access to is really something.

>> What is the advantage of
>>
>> window.color = blue;
>>
>> over
>>
>> window.color(blue);
>>
>> or even
>>
>> window.change_color(blue);
>>

>
> Really, the only difference (to me) is purely cosmetic. Although using
> functions is one way of doing it, I would rather use window.color = BLUE
> because it is a simple assignment with (probably) very simple error checking
> needed.


Probably simple error checking, or perhaps not, the amount of error
checking is irrelevant if you're encapsulating, right?

>> Why not always use the function notation instead of having two different
>> notations depending on whether you decide to treat something as a
>> "property". I just don't understand the motivation for making a
>> distinction between changing or requesting "properties" and other forms of
>> object interaction.
>>

>
> The driving force behind this is my lazyness and hatred of Accessor/Mutator
> pairs. I Like to keep functions that are useful public, and not pollute the
> class namespace with nearly useless get/set functions. This way I could hide
> the implementation from other programmers who need not know about why
> something works just that it does. Also I think properties enforce
> encapsulation better. They give a simple interface to hide as many
> implementation details as possible.


I have to disagree. If it looks like a public variable, people will
expect it to behave like one... should what looks like a simple
assignment throw an exception?

And if you consistantly use the function notation, then you are
simplifying the interface.

Additionally, providing direct access to the members (or appearing to)
doesn't really hide the implementation details.

Having said that:


class Thing {
int property_;
public:
const int& property() const { return property_; }
int& property() { return property_; }
};

class OtherThing {
int property_;
public:
int property() const { return property_; }
void property(int val) { property_ = val; }
};

int main() {
Thing thing;
thing.property() = 4;
int myProperty = thing.property();

OtherThing otherThing;
otherThing.property(4);
int myOtherProperty = otherThing.property();
}


Whats wrong with those two ways of exposing the properties? It's a
pretty simple interface. You don't have to prepend the functions with
get & set, just take advantage of overloading.

Ben Pope
 
Reply With Quote
 
Brent Ritchie
Guest
Posts: n/a
 
      11-23-2005

"Ben Pope" <(E-Mail Removed)> wrote in message
news:1132746339.edd67583e0ffa026ed2e0dd8871c7e59@f e5.teranews.com...
> Brent Ritchie wrote:
>> "GB" <(E-Mail Removed)> wrote in message
>> news:wsRgf.7083$0h5.3886@dukeread10...
>>> Brent Ritchie wrote:
>>>> Hello all,
>>>>
>>>> I have been using C# in my programming class and I have grown quite
>>>> fond of C# properties. Having a method act like a variable that I can
>>>> control access to is really something.
>>> What is the advantage of
>>>
>>> window.color = blue;
>>>
>>> over
>>>
>>> window.color(blue);
>>>
>>> or even
>>>
>>> window.change_color(blue);
>>>

>>
>> Really, the only difference (to me) is purely cosmetic. Although using
>> functions is one way of doing it, I would rather use window.color = BLUE
>> because it is a simple assignment with (probably) very simple error
>> checking needed.

>
> Probably simple error checking, or perhaps not, the amount of error
> checking is irrelevant if you're encapsulating, right?
>


I have to agree. Encapsulation should automatically hide these
implementation details. What I think properties are useful for is not just
an excuse for public variables. What I think properties are useful for is to
create simple to use members that have functionality that makes sense in the
context of thier object. Say I have a Clock object with three members Hours,
Minutes Seconds. Using encapsulation rules I would write out
Accessor/Mutator pairs for each variable. If I wanted to add some value to
Minutes then I would create another function to do that, same with Hours and
Seconds. In these new functions I would again use the accessor/mutator
pairs. I always found that in this context, I always end up with functions
that do normal variable routines but use longer function names. What I
suggest is use a "property" so that they "Look" like public variables but
"Behave" in whichever context they are in. I would rather read:

Clock clock(0, 0, 0);
clock.Minutes += 80;

cout << clock.Hours << " : " << clock.Minutes << endl;

output would read : 1 : 20

This just makes sense for a Clock class to do, and I dont have to keep
typing something like clock.addMinutes(80); It just seems more intuitive to
me like this.

>>> Why not always use the function notation instead of having two different
>>> notations depending on whether you decide to treat something as a
>>> "property". I just don't understand the motivation for making a
>>> distinction between changing or requesting "properties" and other forms
>>> of object interaction.
>>>

>>
>> The driving force behind this is my lazyness and hatred of
>> Accessor/Mutator pairs. I Like to keep functions that are useful public,
>> and not pollute the class namespace with nearly useless get/set
>> functions. This way I could hide the implementation from other
>> programmers who need not know about why something works just that it
>> does. Also I think properties enforce encapsulation better. They give a
>> simple interface to hide as many implementation details as possible.

>
> I have to disagree. If it looks like a public variable, people will
> expect it to behave like one... should what looks like a simple assignment
> throw an exception?
>


Actually, after using java for a while I've grown quite fond of
everything being able to throw an exception. This allows me to create code
that can dynamically fix any mistakes that may crop up and notify me right
away that there is a problem with one of my classes or methods or whatever.
Being ready for exceptions from anywhere is always a good thing in my mind.

> And if you consistantly use the function notation, then you are
> simplifying the interface.
>


Simplifying yes, Easier to use, maybe. When creating a class, you have
to watch the length of your member names that you use. If you don't then you
run the risk of losing time writing and rewriting long member names
especially on members that add functionality for private variables as they
are usually used most. I think that if it makes sense then symbols are
better.

> Additionally, providing direct access to the members (or appearing to)
> doesn't really hide the implementation details.
>


In a way, it does. Take the Clock example again. If I go clock.Seconds++
and clock.Seconds is already equal to 59 then clock.Seconds++ would set
itself to 0 and do clock.Minutes++ at the same time to simulate a real
clock. Someone using this class knows that this happens they just don't have
to know how it actually happens. They are just glad that it does happen with
no effort on their part.

> Having said that:
>
>
> class Thing {
> int property_;
> public:
> const int& property() const { return property_; }
> int& property() { return property_; }
> };
>
> class OtherThing {
> int property_;
> public:
> int property() const { return property_; }
> void property(int val) { property_ = val; }
> };
>
> int main() {
> Thing thing;
> thing.property() = 4;
> int myProperty = thing.property();
>
> OtherThing otherThing;
> otherThing.property(4);
> int myOtherProperty = otherThing.property();
> }
>
>
> Whats wrong with those two ways of exposing the properties? It's a pretty
> simple interface. You don't have to prepend the functions with get & set,
> just take advantage of overloading.
>


Nothing is wrong with any of those, they are valid and easy to read. But
the problem is when you add funtionality what happens whan you want to add
one to your property? you would have to right a function say addProperty(int
val) { property += val; } where as Thing.Property++ or Thing.Property += 1.
is shorter and is still obvious to the user. Also the way you do it, I have
to rewrite the default functionality for each member every time I write a
class. With my template I can have the basic functionality as soon as I
declare it, and extend it as I see fit.

> Ben Pope



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Not able to copy all properties using properties.putAll() method. Sonal Java 3 12-07-2007 03:08 AM
CompositeControls: ViewState properties w/ Mapped properties probl =?Utf-8?B?Q2hyaXN0b3BoZSBQZWlsbGV0?= ASP .Net 1 01-19-2006 09:19 AM
Making Custom Control Properties Visible in Visual Studio's Properties Palette Nathan Sokalski ASP .Net 0 10-17-2005 02:05 AM
Re: C++ properties Library Created (was Binding together Properties of Objects) Victor Porton C++ 1 08-29-2004 08:02 PM
Problems parsing when Properties.dtd.properties Kent Lichty Java 0 04-16-2004 03:08 PM



Advertisments