«

On 10/14/2010 3:48 PM, Niklas Holsti wrote:
> Pete Becker wrote:
>> On 2010-10-13 18:37:35 -0400, Steve Pope said:
>>
>>> Öö Tiib <> wrote:
>>>
>>>> In context of some smaller scope a function name may mean different
>>>> operation than in enclosing scope. On case of Windows API there are
>>>> perhaps precious few who even know most of the names that it declares.
>>>> Language hides the names of enclosing scopes if you define them in
>>>> scope. How should a good language (that is not "steering developers to
>>>> a bad design choice") remove confusing function names of outer scope
>>>> from overload resolution?
>>>
>>> Offhand, I would say if a compiler for this hypothetical language can
>>> find
>>> a unique function meeting the prototype over all visible scopes, then
>>> it should use that function.
>>>
>>> But if there are two functions with the same prototype (e.g. two
>>> foo(int, int)'s) in two different scopes, and neither hides the other,
>>> then it should bail.
>>>
>>> Whether this can be done with a C++ style linker, as opposed to
>>> Ada style with more passes throught the nametables, I'm not certain.
>>>
>>>
>>
>> Don't get hung up on the linker. It has nothing to do with name lookup.
>>
>> Here's a simple example of the danger in the approach you're
>> suggesting. Suppose you're using a library and it defines a base class
>> named Base. You create a derived class:
>>
>> struct Derived: Base
>> {
>> void f(long);
>> };
>>
>> and somewhere you call this function:
>>
>> Derived d;
>> d.f(3); // calls Derived::f
>>
>> Now you get a maintenance update for this third-part library and your
>> program stops working. Guess what: the developer added a function to
>> Base, void Base::f(int), and your code now calls that function instead
>> of Derived::f.
>
> Since this thread has already mentioned Ada as an example of a language
> where this kind of non-hiding can happen, perhaps it is apropos to
> explain what would happen in Ada for this example:
>
> Adding the function Base::f would make the call d.f(3) ambiguous, since
> the compiler could not decide if the literal "3" should be taken as
> integer or long-integer. Thus the compilation would fail, and the
> programmer would have to say explicitly which type should be used for
> "3", and this would determine if the call is to Base::f or to Derived::f.
>
> So this example would "work" (be safe) in Ada because Ada does not have
> the wide range of automatic type conversions and the "best match"
> ambiguity resolver that C++ uses.
>
> (I'm a habitual Ada programmer who is now trying to learn more about
> C++. From my perspective, the automatic type conversions in C++ are
> rather hair-raising

This is all a matter of personal preference, I would guess. Thirty
percent of countries in the world have cars normally moving on the left
side of the road. I find that rather hair-raising, and they do it every
day without even blinking.

Let's not submerge ourselves in feature bashing or language comparison,
shall we? Never does anything good come out of any of those
"discussions" here or in any other place.

V
--
I do not respond to top-posted replies, please don't ask

Victor Bazarov <> wrote:
> Overloading is based on the *type* of the function, not the name,
> although it does require the name to be the same. Another major
> requirement for overloading is that both *names* have to be declared in
> the same *scope*. In the original post the functions are declared in
> different scopes, and overloading does NOT apply, and hiding does. Such
> is the design of the language. What is it exactly that you don't
> understand? The rationale for what?

I understand how it works. What I don't understand is *why* it has been
standardized to work like that.

On 10/15/2010 11:31 AM, Pete Becker wrote:
> On 2010-10-14 16:02:04 -0400, Victor Bazarov said:
>
>> On 10/14/2010 3:48 PM, Niklas Holsti wrote:
>>>
>>> Since this thread has already mentioned Ada as an example of a language
>>> where this kind of non-hiding can happen, perhaps it is apropos to
>>> explain what would happen in Ada for this example:
>>>
>>> Adding the function Base::f would make the call d.f(3) ambiguous, since
>>> the compiler could not decide if the literal "3" should be taken as
>>> integer or long-integer. Thus the compilation would fail, and the
>>> programmer would have to say explicitly which type should be used for
>>> "3", and this would determine if the call is to Base::f or to
>>> Derived::f.
>>>
>>> So this example would "work" (be safe) in Ada because Ada does not have
>>> the wide range of automatic type conversions and the "best match"
>>> ambiguity resolver that C++ uses.
>>>
>>> (I'm a habitual Ada programmer who is now trying to learn more about
>>> C++. From my perspective, the automatic type conversions in C++ are
>>> rather hair-raising
>>
>> This is all a matter of personal preference, I would guess. Thirty
>> percent of countries in the world have cars normally moving on the
>> left side of the road. I find that rather hair-raising, and they do it
>> every day without even blinking.
>>
>> Let's not submerge ourselves in feature bashing or language
>> comparison, shall we? Never does anything good come out of any of
>> those "discussions" here or in any other place.
>>
>
> Victor, chill out! That sure looked to me like a neutral comparison of
> how two languages address this issue, and it was quite helpful to me.
>

I'll chill out when I think it's time to chill out, thank you. My
suggestion was directed at the "automatic type conversions in C++" note
and *not* at the comparison of function overloading/hiding in C++ and
Ada (which was what you found helpful, I suppose). We've seen some
lunatics jumping on any chance to start complaining about different
aspects of C++, warranted or not, and all those characters need is a
whiff of a "don't get me started on <blah>" to actually start the
bashing. Just trying to avoid wasting the bandwidth.

V
--
I do not respond to top-posted replies, please don't ask

On 10/15/2010 10:14 AM, Juha Nieminen wrote:
> Victor Bazarov<> wrote:
>> Overloading is based on the *type* of the function, not the name,
>> although it does require the name to be the same. Another major
>> requirement for overloading is that both *names* have to be declared in
>> the same *scope*. In the original post the functions are declared in
>> different scopes, and overloading does NOT apply, and hiding does. Such
>> is the design of the language. What is it exactly that you don't
>> understand? The rationale for what?
>
> I understand how it works. What I don't understand is *why* it has been
> standardized to work like that.

Just to remind: here we discuss "what", "where" and "how", and "why" is
usually discussed down the corridor, on the right, in 'comp.std.c++'.
Speaking of "why", quite a few features comprising the foundation of C++
are described and explained in "Design and Evolution of C++", do you
have a copy? I don't have mine handy, or I'd leaf through it to see if
function overloading is covered in it. I'd expect it to be.

V
--
I do not respond to top-posted replies, please don't ask