Hey, I was takin'' a look at a C# book, and the language has some cool features. One of them was a get/set type of member function dealio, and it was kinda cool. Instead of defining functions like this: class Point { GetX (); SetX (); ... } you did something like this: class Point { get m_X { return (m_X); } set m_X { return (m_x); } } or something like that, and then you just did this: Point.X = 4; whatever. Doesn''t matter anyway... that got me to thinking, though. I know you can return a reference to an object and use that return paramter as if it were an outside access to a member. Like this: Point.X() = 4; f = Point.X(); ok, we got that. now wouldn''t it be cool if we could write an operator called something like member()= or ==member() and it would give us access to a member? Like this: class Point { operator X()= (parameter) { myX = parameter; } operator ==X() (parameter) { // return true if x == parameter. } } then you could just do this: Point.X() = 4; f = Point.X(); then you could do bounds cheking and stuff. i am sense making? tinking me am not.

I''m pretty sure you can do that. I never delved into it myself, because I''ve never really needed it; but try looking under the command called "operator".

I''m pretty sure you can do that operator example that you had just fine in normal C++ (like WhatEver said).

What I want to know about C++, is why is a pure virtual declared like:
virtual func(...) = 0;

Heh, I''m sure lots of people would like to know why they did that also .

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said
http://www.gdarchive.net/druidgames/

Not sure if I've understood what you're getting at, but what about this?

class Point
{
public:
// constructors, functions etc

int& X() { return _x; }
int& Y() { return _y; }

private:
int _x, _y;
};

No idea if it will work, but it should. But then again, if you're going to do that you might want to rethink your encapsulation :-)

ADDENDUM:

The operator X() example won't work. That is used to allow implicit conversions when the compiler is expecting something something else and needs to convert.

For example, maybe you want to test if a file is open or not, you can define "operator bool()" inside your File class, the write:

File myFile;

if (myFile) ...

and the compiler will use your operator to coerce your object of type File into one of type bool ... otherwise you would get a compile error.

--
Get a stripper on your desktop!

Edited by - taliesin73 on February 22, 2001 9:44:23 PM

Okay, I just looked at the original article again ... you already covered the reference to object thingy that I described.

On re-reading, it would appear that what you want is to be able to write one member function that can access all member variables, yes? That being the case, that violates encapsualtion even worse ;-) I''m guessing that if you define get and set methods, C# must add some sort of syntactic sugar to map point.X to the appropriate method.

Get a stripper on your desktop!

C++ Builder has a language extention of __property. The format is...

<property declaration> ::= __property <type> <id> [ <prop dim list> ] = "{" <prop attrib list> "}" <prop dim list> ::= "[" <type> [ <id> ] "]" [ <prop dim list> ] <prop attrib list> ::= <prop attrib> [ , <prop attrib list> ] <prop attrib> ::= read = <data/function id> <prop attrib> ::= write = <data/function id> <prop attrib> ::= stored = <data/function id> <prop attrib> ::= stored = <boolean constant> <prop attrib> ::= default = <constant> <prop attrib> ::= nodefault <prop attrib> ::= index = <const int expression>Examples: __property int X = {read = iX, write = SetX} instance.X = instance.X++;// read return data member iX, write call void SetX(int Value) __property int Element[int i] = {read = GetElem, write = SetElem} instance.Element[i] = instance.Element[i+1];// read call int GetElem(int i), write call void SetElem(int Index, int Value);

I was going to say that it sounds like Delphi
I personally think that it''s a bad design - if a function is going to be called when you make an assignment you kinda want to know. Also assignment cannot fail, if a function gets called, what do you do if there''s a simple error? like the value being out-of-bounds (value not index)? throw (read abuse) an exception?
or keep it a big secret?

I see how it could be useful too, it''s not entirely unlike operator overloading...

Magmai Kai Holmlor
- The disgruntled & disillusioned

Null ''n'' Void, you wanted to know why pure virtual functions is declared like this:

virtual func(...) = 0;

My guess is that since virtual functions are stored as pointers in a vtable structure (internally) so that they can be overloaded, the = 0 thingie says that the pointer should be set to NULL, i.e. there is no implementation of the function available at this level.

Just my guess...

Best regards,
Henrik

quote:

---

On re-reading, it would appear that what you want is to be able to write one member function that can access all member variables, yes? That being the case, that violates encapsualtion even worse ;-) I''m guessing that if you define get and set methods, C# must add some sort of syntactic sugar to map point.X to the appropriate method.

---

Actually the get/set thingy in C# is syntactic sugar, since it allows you to do one thing you can perfectly do another way, but maybe not as neat. It doesn''t violate encapsulation in the sense that you can perform things you want to when that value changes (including not allow change), which is harder when the variable is just plain public. The function is not "one for all member vars", you declare one function for each member-var you want to be able to access, so you won''t expose those you don''t want to expose.

quote:

---

now wouldn''t it be cool if we could write an operator called something like member()= or ==member() and it would give us access to a member?

---

Well, this is a feature in ruby a nice OO-language (as it seems, I haven''t tried it yet). More info: http://www.ruby-lang.org/en/.

quote:

---

I personally think that it''s a bad design - if a function is going to be called when you make an assignment you kinda want to know. Also assignment cannot fail, if a function gets called, what do you do if there''s a simple error? like the value being out-of-bounds (value not index)? throw (read abuse) an exception?
or keep it a big secret?

---

Hehe, definetly keep it a secret. No actually I think you should throw, and I don''t think it''s an abuse, since if the value is out-of-bounds, it''s not a simple error (of course depending on situation). I think there seems to be a big fear for exceptions here. It''s important to have a clear view on what really is an error. Today people are used to SW not working ("it''s not a bug, it''s a feature"-mentality), which I think is clearly wrong. What needs to be separated is expected errors and unexpected errors. Faulty user-input is an expected error, so that should be validated before going further into the system, thus an out-of-bounds exception is a SW-bug, since either it was a value generated by the SW (and a faulty one) or it was a faulty value from the user, that was allowed to pass through the user-input validation. Either way it''s an error.
Still I can partially agree that, although sometimes nice, it can cause problems for Joe, the maintenance programmer, since he''ll probably tear his hair out before he realises that if you try to write a value larger than 10 to O.X, O.X won''t change. (That''s another reason throwing when out-of-bounds, since then Joe the hairless maintenance programmer will find the problem and be happy again).

quote:

---

Original post by Magmai Kai Holmlor

what do you do if there''s a simple error? like the value being out-of-bounds (value not index)? throw (read abuse) an exception?

---

Sure, why not? Isn''t that what the rangeErr exception is for?


--
Get a stripper on your desktop!