Overuse of function overloading (Was: Derived class hiding a name)
On May 23, 6:59 pm, "jord...@gmail.com" <jord...@gmail.com> wrote:
I eventually realised that my class interface was a little weird
anyways,
<snip>
But just for academic interest, is there a reason why the standard
doesn't allow me to be more specific about the using declaration? Why
can't I say "using::A(foo)" so that the compiler doesn't try to also
bring the inaccessible overloaded private function into scope and only
brings the one that I need?
I have a different question: why did you need to have two
distinct functions, with different signatures, presumably
doing different things, with the same name?
Above and beyond the rather obscure issue that the OP
has brought up, there are plenty of known issues with
function overloading, particularly situations where
a different signature of a function is called than the
user expected. IM-not-so-HO, given the unavoidable
issues with overloading, function overloading should
be avoided unless the alternative is worse (or
non-existent -- cf. constructors.)
There is a tendency when people discover a new
neaty-keeno-cool feature to use it everywhere they
can -- "when you've got a hammer, everything's a
nail" -- but overuse of these features make for
code that is hard to use and hard to maintain.
Derived classes, function overloading, user-defined
type conversions, operator overloading, access controls,
etc. (let's not even mention RTTI) all tend to
get used when a more traditional approach would
work as well or better, and when that happens,
the resulting code/class hierarch is less
usable and less maintainable.
I would argue that, when designing classes or
writing code, the burden of proof should be on
the version that uses a "cewl" new
feature -- unless the new approach is clearly
better, stick with the tried-and-true.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]