[C++] OOP

Hello faggits,

I started to declare my getter and setter like this:

math_vector.h

class V2{
private:
    double coords[2];

public:

    V2();
    V2(double x, double y);
   
    double& x();
    double const& x() const ;
   
    double& y();
    double const& y() const ;
}

inline
double& V2::x() {return coords[0];}

inline
double const& V2::x() const {return coords[0];}

inline   
double& V2::y() {return coords[1];}

inline
double const& V2::y() const {return coords[1];}

so I can use:

V2 c(1.0, 2.0);
V2 d(3.0, 4.0);

c.x() = 15.;
c.y() = d.y();

my question:

1. does the inline method needs to be declared in the .h file or in the .cpp? If I declare it in the .cpp will be then compiled and will not be used by other file as an inline method?

2. I'm getting used to write the setter with the reference is it good?
or is it better to write like this?

//1.
double& x() {return _x;}
//2.
void x(double const& value) {_x = value;}

3. I provide many times both the getter and setter to have full access to the memebers, is it better to have them public?

4. If I want to print out something to the console I often overload the ostream operator <<. There is a little glitch that buggers me: if I declare it as a friend of my class I need to #include <iostream.h> instead of #include<iostream> which some time give problems with the namespaces. So right now I'm declaring it as an outside function and passing in the object as a const& but I cannot access the private members then... How do you deal with that?

Getters/Setters Considered Harmful

what in the actual FUCK?

using C.x() = 15; is more powerful than C.x = 15, but it is not quite as powerful as C.setX(15); C.x() could do something very fancy, like allocate and reserve a memory address for the x value. But it cannot affect in any way the value of 15 that will be assigned. C.setX(15) can do whatever it wants to the value 15, and store it where ever it wants. In this example 15 is just a number, but if it was a handle for large file or something, then C could make a hash of the file and store the hash or something, or maybe compress the file and return a decompressed version when C.x() is called. It all depends on what will work best in the end, but it is nice to have to option to explore these implementations without having to keep the client code up to date with your changes.

>>4
Maybe you should be using a real language instead.
http://docs.python.org/reference/datamodel.html#customizing-attribute-access

this is why everyone hates C++

this is why >>6 hates C++

>>7
True. People hate Sepples for very disparate reasons, most of them valid.

>>5
>using three methods to handle the setting, getting, and deleting of all attribute.

Terrible!

That's nice and flexible and all for a language like python, but you wouldn't want that type of generality for seeples. Letting the name be a variable and resolving it to a getter or setter via dictionary look up would be needless overhead. Ideally, C.x = 6 would be immediately translated to C.setXHandler(6) at compile time.

>>9
Is that even relevant to the topic, or is it just your way of saying ``I don't know Python or Sepples''?

>>10
the answer you seek can by found by following the link in >>5

>>11
nice ass dubs bro!
i know you're speechless, i would be too!

but to be more clear, the pythonic way of implementing C.x = 6 would be c.__setattr__('x', 6). And then __setattr__ would need to examine the 'x' value for the name argument and use it to determine where to store the value of 6. When using a getter or a setter, the data type already knows which field your are getting or setting based upon which getter or setter you have called. It doesn't need to look up the value of a name argument at run time, which is what has to happen in python unless there is some difficult to guarantee optimization of inlining the __setattr__ method and then applying constant folding to the name argument.

>>14
So the answer is that you don't know Python. Glad we got that sorted.
Examine the link in >>5 harder.

Called when an attribute lookup has not found the attribute in the usual places (i.e. it is not an instance attribute nor is it found in the class tree for self). name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

Called when an attribute assignment is attempted. This is called instead of the normal mechanism (i.e. store the value in the instance dictionary). name is the attribute name, value is the value to be assigned to it.

normal mechanism
store the value in the instance dictionary

an attribute lookup has not found the attribute in the usual places
an attribute lookup

>>16
You're embarrassing yourself.

>>17
I'm quoting the link. If python contradicts its documentation by providing another way to do this, then maybe you should explain it.

If anyone reading the thread is interested, >>17 was hinting at this:

http://www.python.org/doc//current/library/functions.html#property

bampu pantsu