Re: C++ reluctant to overload function
On 13 okt, 18:59, spop...@speedymail.org (Steve Pope) wrote:
=D6=F6 Tiib <oot...@hot.ee> wrote:
Example given by Victor is on one hand a good example of name hiding
feature what language allows. On other hand it is hard to see who
really needs to hide a name like that (and why). It is very hard to
believe that writer of the function did really run out of possible
names.
The whole idea of overloading is to provide the programmer with
a form of polymorphism. e.g. I have a math library function
double sin(double x)
And I want to overloaded it with a vector version
vector<double> sin(vector<double> x)
Because one scope encloses the other I cannot do this without some
sort of workaround.
I do not really see why you need them as overloads but hopefully you
tell the reason.
Lets first see what we have. There are several sin() in current C++.
1) In <complex> there is such std::sin():
namespace std
{
template<class T> complex<T> sin(const complex<T>& x);
}
2) In <valarray> there is such std::sin():
namespace std
{
template<class T> valarray<T> sin(const valarray<T>&);
}
3) In <cmath> there are such sin():
double sin(double);
float sin(float);
long double sin(long double);
Lets now see solutions.
1) These are all usable side-by-side. Just call ::sin() for double,
float and long double or std::sin() for valarray<T> and complex<T>.
2) If you want to define your own sin in your scope (namespace) and
have the C++ sin variants also there as overloads:
#include <complex>
#include <valarray>
#include <cmath>
namespace stevemath
{
using ::sin;
using std::sin;
vector<double> sin(vector<double> x);
}
3) If you want them to be all useful as overloads in a global
namespace then that is bad idea to burden global namespace but also
doable:
#include <complex>
#include <valarray>
#include <cmath>
using std::sin;
vector<double> sin(vector<double> x); // Steves sin
So what is so difficult about it?
If the nuisance factor of such workarounds inclines
the programmer to not use polymorphism when they should, then
in some sense the language design is steering them to a poor design choic=
e.
I do not understand ... why you need them all sins as overloads of
each other. If there is reason then i don not understand how can it be
so good i have not met it but you desire it without indicating it?
Majority would really hate if some of thousands of functions from
<windows.h> or other place like that started to compete in overload
resolution with member functions within their classes or with
functions within their namespace and cause typos to compile for
confusing results. Describe the poor design choice you are steered
towards. For me C++ is as liberal as it can only get when choices of
paradigms, idioms or design patterns are under discussion.