overloaded casting question

[laniik]

Hi. Im just wondering what the syntax to overload a casting operator
is. For example, i have

struct Point {
float x,y,z;
};

struct Vector {
float a,b,c;
};

and i want to be able to do somthing like

Point p;
Vector v;

((Point)v).x++;

thanks

 

[Victor Bazarov]

Hi. Im just wondering what the syntax to overload a casting operator
is. For example, i have

struct Point {
float x,y,z;
};

struct Vector {
float a,b,c;
};

and i want to be able to do somthing like

Point p;
Vector v;

((Point)v).x++;

I would strongly advise against it. What you really want is to create
an interface to treat the Vector's elements as if they had names x, y, or
z. You can introduce member functions for that.

struct Vector {
float a,b,c;
float& x() { return a; }
};

Now write

v.x()++;

V

 

[Victor Bazarov]

I would strongly advise against it. What you really want is to create
an interface to treat the Vector's elements as if they had names x, y, or
z. You can introduce member functions for that.

struct Vector {
float a,b,c;
float& x() { return a; }
};

Now write

v.x()++;

V

Another way is to derive Vector from Point, of course.

V

 

[Artie Gold]

Another way is to derive Vector from Point, of course.

V

<ack> <gag> <splutter>

Is a Vector a Point?

</ack> </gag> </splutter>
;-)

--ag

 

[lilburne]

Another way is to derive Vector from Point, of course.

I don't think our mathematicians would agree, in fact I can
point to 10 years of interminable arguments about a point
isn't a vector, etc, etc.

class Point {
public:

double x();
double y();
double z();
Vector release();
};

class Vector {
public:

double i();
double j();
double k();
Point anchor();
};

 

[laniik]

hm. just out of curosity, why do you advise against it. Really, the
reason is not so i can rename the variables, that was just an example
of what they do. The reason i would want to do that is because i often
find myself wanting to perform vector functions on points:

example.

Vector v;
Point p;

v.a=p.x;
v.b=p.y;
v.c=p.z;

Vector::normalize(v);

where really i would like to remove the need of those 3 lines, and have

Vector::normalize((Vector)p);

for example.

thanks
oliver

 

[laniik]

a vector is not a point, of course, but they are similar in terms of
local data, and im often wanting to perform vector operations on a
vector that woul have the same values as a specific point.

 

[laniik]

also,

(regardless of the correctness of vectors/points) im also curious how
its done!

: )

 

[Victor Bazarov]

hm. just out of curosity, why do you advise against it.

You're trying to introduce a tight coupling where none seem to exist.
If you know that it does in fact exist, there are better ways to put it
into C++ terms. See Inheritance, Containment, Implementation in terms of
and so on...

Really, the
reason is not so i can rename the variables, that was just an example
of what they do. The reason i would want to do that is because i often
find myself wanting to perform vector functions on points:

example.

Vector v;
Point p;

v.a=p.x;
v.b=p.y;
v.c=p.z;

Vector::normalize(v);

where really i would like to remove the need of those 3 lines, and have

Vector::normalize((Vector)p);

for example.

What does it mean to normalize a point if that point is not a vector?
What you need, probably is a way to convert one into the other. Define
respective parameterized constructors in each class.

class Point;

struct Vector {
float a,b,c;
Vector(Point const &p);
};

struct Point {
float x,y,z;
Point(Vector const &v);
};

Vector::Vector(Point const &p) : a(p.x), b(p.y), c(p.z) {}
Point:oint(Vector const &v) : x(v.a), y(v.b), z(v.c) {}


V

 

[lilburne]

hm. just out of curosity, why do you advise against it. Really, the
reason is not so i can rename the variables, that was just an example
of what they do. The reason i would want to do that is because i often
find myself wanting to perform vector functions on points:

example.

Vector v;
Point p;

v.a=p.x;
v.b=p.y;
v.c=p.z;

Vector::normalize(v);

where really i would like to remove the need of those 3 lines, and have

Vector::normalize((Vector)p);

for example.

Points and vectors are our stock in trade. Most of the time
we don't have any real problems with keeping them seperate
and converting a Point to a Vector and back again as needed,
besides our vector class has a cached length too. Heck we
even have a UnitVector class too. For us the important thing
is clarity in the code, and a minimal use of casting. If we
really need to get jiggywithit these things get converted to
raw arrays.

 

[Andrew McDonagh]

Points and vectors are our stock in trade. Most of the time we don't
have any real problems with keeping them seperate and converting a Point
to a Vector and back again as needed, besides our vector class has a
cached length too. Heck we even have a UnitVector class too. For us the
important thing is clarity in the code, and a minimal use of casting. If
we really need to get jiggywithit these things get converted to raw arrays.

For the initial example given by the OP, we can keep Vector and Point
classes as separate types, whilst still avoiding the need for casts, by
having them implement an interface.

That is, both class can inherit a pure abstract class.

class ICoordinate {
public:

double x() = 0;
double y() = 0;
double z() = 0;

}

class Point : public ICoordinate {
public:

double x();
double y();
double z();
Vector release();
};

class Vector : public ICoordinate {
public:

double x() { return i(); )
double y() { return j(); }
double z() { return K(); }

double i();
double j();
double k();
Point anchor();
};

The code that would have needed to cast a Vector to a Point, would
actually use a pointer/reference of type ICoordinate, and simply call
the appropriate interface method.


It doesn't address how we access Point or Vector specific methods like
Point::anchor() or Vector::release(), but these methods are not the same
so it would not be appropriate to use an Interface for them.

Andrew

 

[laniik]

hm ok thanks for the advice. i will reconsider implementing what was
originally just an attempt to save three lines of code and a little
curosity.

so now I have a new (totally unrelated) question:
say have 2 classes

struct BLAHG {
float erg,gha,moo;
}

struct OOGA {
float roo, hak, mup;
}

and i want to do a cast

OOGA o;
BLAHG b;

(BLAHG)o

where it maps the respective internal elements.

how would i do that? : P

 

[Andrew McDonagh]

hm ok thanks for the advice. i will reconsider implementing what was
originally just an attempt to save three lines of code

I think this may be the cause of your problem. You may be removing the 3
lines of code within the classes, but how many lines of cast code would
you be implementing.

Don't think about saving three lines of code, its better to think about
the design. Once you do this, any duplication (in this case the
Casting) would be removed anyway.

and a little curosity.

so now I have a new (totally unrelated) question:

From a design point of view, this appears to be the same question.

 

[lilburne]

hm ok thanks for the advice. i will reconsider implementing what was
originally just an attempt to save three lines of code and a little
curosity.

so now I have a new (totally unrelated) question:
say have 2 classes

struct BLAHG {
float erg,gha,moo;
}

struct OOGA {
float roo, hak, mup;
}

and i want to do a cast

OOGA o;
BLAHG b;

(BLAHG)o

where it maps the respective internal elements.

how would i do that? : P

You could use reintpret_cast<T*> or reinterpret_cast<T&> or
and old style C cast. But you really don't want to do that.
The problem is that over time BLAGH nearly always turns into
BLAGH1 and OOGA nearly always turns into OOGA1. As the old
80s saying went:

"The world could end due to a misplaced typecast!"

 

[lilburne]

It doesn't address how we access Point or Vector specific methods like
Point::anchor() or Vector::release(), but these methods are not the same
so it would not be appropriate to use an Interface for them.

I think that is exactly what the OP wants to do. He wants to
perform operations from disparate classes based on
commonality of implementation details.