Re: which of these 3 casts would you prefer?
On Aug 27, 11:38 am, Juha Nieminen <nos...@thanks.invalid> 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 o=
r
similar...).
The reason why function and operator overloading is important is not
because it's "handy" or "convenient" or anything like that. It's because
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);
}
You don't even need to be doing this to run into the lack of function
overloading as a great annoyance. I recently started working in a
project where the lead architect insists it's in C (there are a bunch
of other things that are more frustrating to me about it than that,
but whatever). I've found the necessity to think of obscure names to
make sure to avoid any naming conflicts is a serious quandry. For
example, in writing a generic stack, vector, or managed string class
(I have no problem with C OOP, it can be elegant in its own way) you
have many functions that have a related concept but of course are very
different in implementation. You could use polymorphism to get by,
but what if you don't want to use polymorphism? You're quite stuck
having to name functions like isEmpty to things like
isNamespaceStackEmpty and isNamespaceStringEmpty, and you're always
going to be worried that somewhere someone else is naming their stack
or vector functions the same thing.
Luckily the project code is quite small and this isn't anything but a
minor annoyance, but I can't imagine having to deal with it on a
larger scale. In C++ these things just work themselves out and they
work themselves out quite well in a very direct manner that is easy to
detect errors. There are rules like ADL and more complex rules when
possible overloads are templates, but they're actually not that hard
to remember especially for the gain you get from them. Honestly this
issue has bugged me more than any lack of operator overloads, etc...