On operator overloading

Started by
14 comments, last by jfclavette 19 years, 10 months ago
quote:Original post by SiCrane
quote:Original post by xMcBaiNx
Sidenote: Vector * Vector
Make it the dotproduct, the crossproduct, or none to avoid confusion ?
IMO, none.
I agree. I''d use a.dot(b) and a.cross(b) or something similar.
quote:Original post by Thunder_Hawk
This leads me to something that''s been bugging me for a little while now. What do you do with formulas involving velocity squared? My best guess would be to convert the velocity to polar form, square the length, and convert the vector back to standard (x, y) form, but I really have no idea if that''s right.
Squaring a vector makes little sense. The formulas probably just want the square of the length of the vector.
Advertisement
quote:Original post by Beer Hunter
I agree. I''d use a.dot(b) and a.cross(b) or something similar.


I''d prefer to work with dot(a, b) and cross(a, b), but that''s just me.
My stuff.Shameless promotion: FreePop: The GPL god-sim.
quote:Original post by Doc
quote:Original post by Beer Hunter
I agree. I''d use a.dot(b) and a.cross(b) or something similar.


I''d prefer to work with dot(a, b) and cross(a, b), but that''s just me.


I second that.

Prefer non-member functions to members. (It''s one of the
items in [More] Effective C++, but I don''t have the books with
me right now.)

When I see a.dot(b), I think of "dot" as a mutator of a. But,
calculating the dot-product should not change the vector a.
This syntax is not intuitive.

OTOH, the intent of dot(a, b) (or c = MyVector::Dot(a, b), as
a class-static function) is quite clear, at least to me.



Kami no Itte ga ore ni zettai naru!
神はサイコロを振らない!
There are additional (bad) ways of handling this. One of my favorite bad methods goes like:
class Vector {  public:    Vector(float x = 0.0f, float y = 0.0f, float z = 0.0f)      : x_(x), y_(y), z_(z)    {}      public:    float x_;    float y_;    float z_;};template <typename Op>struct LtProxy {  LtProxy(const Vector & r) : ref_(r) {}  const Vector & ref_;};const struct DotT {} dot;LtProxy<DotT> operator<(const Vector & lhs, const DotT & rhs) {  return LtProxy<DotT>(lhs);}float operator>(const LtProxy<DotT> & lhs, const Vector & rhs) {  return ( (lhs.ref_.x_ * rhs.x_) +           (lhs.ref_.y_ * rhs.y_) +           (lhs.ref_.z_ * rhs.z_) );}const struct CrossT {} cross;LtProxy<CrossT> operator<(const Vector & lhs, const CrossT & rhs) {  return LtProxy<CrossT>(lhs);}Vector operator>(const LtProxy<CrossT> & lhs, const Vector & rhs) {  return Vector( (lhs.ref_.y_ * rhs.z_ - lhs.ref_.z_ * rhs.y_),                 (lhs.ref_.z_ * rhs.x_ - lhs.ref_.x_ * rhs.z_),                 (lhs.ref_.x_ * rhs.y_ - lhs.ref_.y_ * rhs.x_) );}int main(int, char **) {  Vector a(0, 1, 3);  Vector b(4, 2, 1);   float dot_product = a <dot> b;   std::cout << dot_product << std::endl;    Vector cross_product = a <cross> b;  std::cout << cross_product.x_ << std::endl;  std::cout << cross_product.y_ << std::endl;  std::cout << cross_product.z_ << std::endl;    return 0;}

This abuses the associativity of relational operators and operator overloading in general, is unmaintainable and can give operator precdence headaches, but it''s fun.

Of course, I have a slightly twisted definition of fun.
...

...

... OMFG. That is truly sick. Caek for yuo.
Wow. That's almost as good as my implementation of finally.

EDIT: I missed this...
quote:Original post by TangentZ
quote:Original post by Doc
quote:Original post by Beer Hunter
I agree. I'd use a.dot(b) and a.cross(b) or something similar.
I'd prefer to work with dot(a, b) and cross(a, b), but that's just me.
I second that.

Prefer non-member functions to members.
...
Come to think of it, I agree. It'd be more clear as a non-member function.

[edited by - Beer Hunter on June 3, 2004 3:36:01 AM]

This topic is closed to new replies.

Advertisement