reason for existance of function hiding

bo*@blah.com wrote:

Hi,

I know there exists a good reason why the designers of c++ decided that
function hiding should exist. But I don't know why. Can anybody provide
a good reason/example of a case where function hiding saves the day. I
know there exists one, I'd just like to hear about it.
thanks and have a nice day.

G

It's called OOA/OOD where users of an object only have access to its
interfaces. How the internal functioning of that object works should be
of no interest/business of theirs. Hence the collection of functions
that are used to facilitate the objects behaviour are hidden. Think
about driving a car, you only need to know how to use the controls and
not every detail of how it works. It's the same for Computers, Radios,
Televisions, Microwave ovens, and countless other every day things you
might use. Now, do you know anyone, or do you think you might be able to
understand yourself, how all of them work? I'm guessing not.

JB

* bo*@blah.com:

I know there exists a good reason why the designers of c++ decided that
function hiding should exist. But I don't know why. Can anybody provide
a good reason/example of a case where function hiding saves the day. I
know there exists one, I'd just like to hear about it.

IMO there is no convincing reason. However, there is a reason. Namely
the "fragile base class" problem, in this case that the mere addition of
a new member function in a base class should not by default affect
client code using a member function of that name from a derived class,
as it could do without the hiding (think overload resolution).

I find this reason less than convincing because (1) the hiding does not
help when the derived class offers no member function of that name, (2)
the hiding does not help with the "fragile base class" problem in
general, merely a subtle aspect that is not much of a practical problem,
and (3) the hiding is very counter-intuitive to most programmers (an
extreme case is where an automatically generated assignment operator in
a derived class hides a custom assignment operator in a base class), and
forces us to write extra, silly 'using'-declarations, instead of perhaps
with the opposite default behavior having to write 'hide'-declarations,
or simply acknowledging that the full effective interface of a derived
class really does include stuff from base classes.

Not much we can do about now, though.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"bo*@blah.com" writes:

I know there exists a good reason why the designers of c++ decided that
function hiding should exist. But I don't know why. Can anybody provide
a good reason/example of a case where function hiding saves the day. I
know there exists one, I'd just like to hear about it.

There are at least two kinds of function hiding in C++ and I don't know
which one you are referring to. One kind is the static function definition
inherited from C. The other is making a member function private. In the
first case it would take a good reason to change the rules, it's just
confusing to people without any real gain. Recall that C did not have
namespaces and this was *a* cut at that problem. I could have a sine
function that worked in radians and another one that worked in degrees in
the same composite program, each being called with: sine(double).

In the case of member functions, it may be that the class designer does not
want everyone that wanders by to have access to all the functions. They may
do harm. And even if they do no harm, why clutter their (the user of the
class) mind with things they do not need to understand or even know about?
If a Fourier analysis program has a complicated function with ten
parameters, do I really need to know about this? I either trust the person
who provided the class or I do not. It is quite unlikely that I can fix his
goofs, if there are such.

Alf P. Steinbach ha scritto:

I find this reason less than convincing because (1) the hiding does not
help when the derived class offers no member function of that name, (2)
the hiding does not help with the "fragile base class" problem in
general, merely a subtle aspect that is not much of a practical problem,
and (3) the hiding is very counter-intuitive to most programmers (an
extreme case is where an automatically generated assignment operator in
a derived class hides a custom assignment operator in a base class), and
forces us to write extra, silly 'using'-declarations, instead of perhaps
with the opposite default behavior having to write 'hide'-declarations,
or simply acknowledging that the full effective interface of a derived
class really does include stuff from base classes.

What are 'using'-declarations?

Thanks,
Marco

* Marco Ambu:

What are 'using'-declarations?

struct Base
{
void foo( int ) {}
};

struct Derived: Base
{
using Base::foo;
void foo( char const [] ) {}
};

int main()
{
Derived d;
d.foo( 1234 ); // Should work, cause of 'using'.
}

On the other hand, 'hide'-declarations where just something I made up
for the discussion.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

hi,

I know this is going slightly off-topic from the OP question, but there
seems to be some thing that i dont understand so I thought this would
be the right place to ask about it,

I would really appreciate if you can explain a bit more on

struct Derived: Base
{
using Base::foo; // <--- What does this mean?
void foo( char const [] ) {}
};

I have used 'using' keyword many times, but i have never came across a
similar usage, or maybe you can refer me to to some good source where i
can refer to it :)

/hack_tick

Opps sorry there goes something from java, seems like i need to get
hold of my C++ again, i recalled what this is all about,

it is so that the base class functions are acessable in the deived
class.

hack_tick wrote:

hi,

I know this is going slightly off-topic from the OP question, but there
seems to be some thing that i dont understand so I thought this would
be the right place to ask about it,

I would really appreciate if you can explain a bit more on

struct Derived: Base
{
using Base::foo; // <--- What does this mean?
void foo( char const [] ) {}
};

I have used 'using' keyword many times, but i have never came across a
similar usage, or maybe you can refer me to to some good source where i
can refer to it :)

/hack_tick

Hi

In the example given above you would notice that the foo() method has
different signatures in the base and derived class. Thus its neither a
case of function over-riding (which needs same function signature in
base and derived class) nor of function over-loading (which needs same
function name with different signature in the SAME class). I

f we were not using the 'using' keyword, the base class foo() would
never be accessible using the derived's object. So the base class'
foo() would have got hidden since we are using a different signature of
the same function name in derived class.

I really feel this should be called function overloading since, base
class function is visible is derived class (after using it) and derived
class is having its own member function with same name but with
different signature, lemme know if I am wrong :)

/hack_tick