Re: which of these 3 casts would you prefer?
On Aug 27, 2:37 pm, BGB <cr88...@hotmail.com> wrote:
On 8/27/2011 11:38 AM, Juha Nieminen wrote:
BGB<cr88...@hotmail.com> wrote:
one can also argue that function overloading and operator overloading
are nifty, but rarely have I found this to be a big issue (one can
typically sort-of make due with using short macro names to redirect to
longer operator function names or similar, and with the convention of
using short suffixes to function names to indicate the argument types =
or
similar...).
The reason why function and operator overloading is important is=
not
because it's "handy" or "convenient" or anything like that. It's becaus=
e
it's *necessary* for generic programming. It's what allows you to do
things like this:
template<typename T>
T foo(T value)
{
std::cout<< "The input value was "<< value<< =
std::endl;
return std::cos(value);
}
The above code would be impossible without function and operator
overloading. For example in C you have cos(), cosf() and cosl(), and
you just can't write a macro that would call the proper function based
on the type of the parameter. In C++ you have just different versions
of std::cos(), and the proper version will be automatically called
depending on the type of parameter.
(You could write *three* macros with different names, but now yo=
u have
not only triplicated your code, you have made it impossible to call
the macro from other macros without triplicating those too, so the
triplication becomes contagious. Also, it doesn't allow the user to use
a custom user-defined type.)
Likewise it's what allows the std::cout above to work properly.
This is something the most C programmers don't understand. They =
are
not to blame, though, because many C++ programmers don't know this eith=
er
(or have never thought about it).
yes, fair enough. C does not do this...
however, it could be argued that *not* having to write duplicated code
in this case is what is nifty/convinient/...
You seem to be saying that function overloading is not necessary for
generic programming because you don't have to use generic
programming. Same can be said of any paradigm.
Tell me, why are you not writing all your code in assembler?
Certainly it is possible to do so.
as well, there is another partial way around this problem:
one can implement a dynamic type-system, and then use wrapping and
run-time type-checking for a lot of this. it is a tradeoff (performance
is worse, ...), but it works.
In C++ we call this polymorphism and it is another built in feature we
don't have to develop on our own.