Path: utzoo!attcan!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: Inheritance in cfront and g++ Message-ID: <56796@microsoft.UUCP> Date: 21 Aug 90 17:24:49 GMT References: <1990Aug17.141710.5004@aucs.uucp> <38219@ucbvax.BERKELEY.EDU> <1990Aug20.115115.3646@tukki.jyu.fi> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Distribution: comp Organization: Microsoft Corp., Redmond WA Lines: 33 In article <1990Aug20.115115.3646@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: > >I.e. a function declaration in an inner scope hides all functions >with the same name declared in outer scopes, independently of >argument types. According to the Release 2.0 Ref.Man., Sc. 13.1, >this applies even to other cases than base class - derived class. > >This is an unorthogonal kludge, which makes the rules >of a complicated language even more complicated. >As far as I can see, it is also a deviation from older language >specifications. Already the subtle difference between virtual >and non-virtual overloading can be surprising enough; we don't >need this hiding rule to bite us. > I disagree. I support the interpretation that same-named functions with differing parameters should represent a function-set -- multiple implementations of the same behavior, only optimized for different pass parameters. If you want to implement differing functionality, use different function names, not parameters, to differentiate your routines. Thus, if one needs to override any one of the function-set in a derived class, it is pretty safe to assume all the other functions in the set, optimized on particular pass-parameter, need to be overridded too. In the odd case where a programmer decides one of the function-set does not need to be re-implemented, that function can be carried forward from the base class via a trivial in-line function. In any case, if you've got a lot of functions in your function-set, you're probably doing something wrong.