Operator overloading is bad because it hides the complexity with easier typing.
Instead of overloading, a Macro like Axy(x,y) should expand to function_call_add(x,y). It obvious, easy to type, and does not have any overhead.
I know some are used to typing operators: but operators are meant for builtin types, extending them to cover every function call "just because its easier to type" is silly. You get confused without mentally expanding operators in the middle.
imagine res=(x+(y*g)-j<<i)/n and deduce at first glance which:
1.function calls, and their order
2.basic operators and their order
I prefer uglier, but obvious nesting of macros/function names like
add(x, sub( Mult(y*g), (j<<i) ) )
Name:
FrozenVoid2011-10-06 0:56
If you're using C++ for any OOP features, stop and consider:
Every OOP feature can be duplicated with structs and macros.
OOP has obvious overhead, and some non-obvious performance drops in function calls and object memory allocation. In general people don't notice the loss of 5-10% performance when its reduced typing time by 5-10.
You think "But what about that qsort in C vs C++ example?"
C library functions are unoptimized ancient shit(compared to fairly optimized, recent C++ library code): if you're serious for performance you roll your own. You don't use qsort, malloc for time critical code just like you don't use every Boost.Extension and STL container in C++.