Author Topic: Overloaded operators  (Read 3145 times)

0 Members and 1 Guest are viewing this topic.

Charles Pegge

  • Guest
Overloaded operators
« on: April 27, 2013, 09:36:36 AM »

I would like to ditch overloaded operators (+-*/ for compound types), since I feel they are conceptually flawed, and play merry hell with compiler logistics. They make some sense for complex numbers. But these can be handled quite comfortably with conventional function calls.

Any objections?

Charles

Aurel

  • Guest
Re: Overloaded operators
« Reply #1 on: April 27, 2013, 12:36:52 PM »
What kind of 'quite comfortably with conventional function calls'.
Do you can explain this little bit more? ???

Charles Pegge

  • Guest
Re: Overloaded operators
« Reply #2 on: April 27, 2013, 12:47:34 PM »
It means you won't be able to use operators directly on complex numbers, vectors and matrices etc. Where each of these types are classes with operator-method sets.

M3=M1*M2

Instead just use standard functions

MatrixMultiply(M3,M1,M2)

Or simple OOP

M3.MulProduct M1,M2

Aurel

  • Guest
Re: Overloaded operators
« Reply #3 on: April 27, 2013, 01:02:28 PM »
Charles .
wait a moment..
Do you want to tell that this:

c = a[2] + b[6]

will be replaced with something like this :

c = ArrayAdd(a[2],b[6])

and that old ordinary way would be removed  :o

Charles Pegge

  • Guest
Re: Overloaded operators
« Reply #4 on: April 27, 2013, 01:11:35 PM »
No, it only applies to compound math objects like complex numbers, vectors, matrix arithmetic. All specialised stuff, where the meaning of arithmentical and logical operators is altered in some way.

Emil_halim

  • Guest
Re: Overloaded operators
« Reply #5 on: April 28, 2013, 07:02:52 AM »
Hi Charles,

why you want do that , it is so simple if vectors  , complex numbers ,.... are classes then creating + - / +
symbol operator is the ideal methods for math calculation.

if not so what is the types of them ?     

Charles Pegge

  • Guest
Re: Overloaded operators
« Reply #6 on: April 28, 2013, 08:25:12 AM »
Hi Emil,

My main concerns are:

1 Rarely used - conventional methods would do the same job with little loss of clarity.
2 Additional compiler complexity.
3 Leaky abstraction. These constructs do not behave like simple numeric values.
4 My current implementation is not thread-safe.
5 Too slow. Current implementation of complex numbers, not fast enough for rendering Mandelbrots etc.