Re: Why no Ada.Wide_Directories?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 26 Oct 2011 17:41:30 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:ci96gr5yzmpp$.1mwky141c6e78$.dlg@40tude.net...
>> On Tue, 25 Oct 2011 14:22:27 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:5279agttaub8.1pl7pt496l1am$.dlg@40tude.net...
>>>> On Fri, 21 Oct 2011 14:53:11 +0200, Yannick Duch�ne (Hibou57) wrote:
>>>>
>>>>> Le Thu, 20 Oct 2011 19:35:21 +0200, Dmitry A. Kazakov
>>>>> <mailbox@dmitry-kazakov.de> a �crit:
>>>>
>>>>>>> What's missing from Interface type introduced with Ada 2005 ?
>>>>>>
>>>>>> 1. Most Ada types do not have interfaces
>>>>> Eiffel has this, and this is 1) not perfect (may lead to performance
>>>>> issue) 2) rarely used in practice
>>>>
>>>> There is no performance loss.
>>>
>>> Anytime you have a construct that allows multiple inheritance, there is a
>>> large performance loss (whether or not you use the multiple inheritance).
>>> You can move the performance loss from one construct to another (i.e.
>>> dispatching calls, access types, etc.) but you can't get rid of it.
>>
>> There is no time/memory loss, at all. For the types in question any legal
>> Ada 2005 program would generate exactly same code as it would be the
>> change.
> 
> First of all, I was including Ada 2005 interfaces in this complaint -- so 
> "Ada 2005" is irrelevant (you've already gone over the edge at that point). 
> You *might* be right about Ada 95 programs, but it would require a 
> substantial increase in compiler complexity in order to support that. But 
> Ada compilers are already very complex - fairly close to the point where the 
> complexity would overwhelm the ability to get them correct.

Because the language is in a mess. That surely makes compilers complex.
Without an overhaul it will collapse in some not so distant future anyway
under the weight of arbitrary language patches. You wanted it complex, here
you are!

> It's much more 
> likely that a much simpler design would be used for a pervasively multiple 
> inheriting language where everything is much more expensive.

Note that it was not about multiple inheritance. Yannick suggested that
making types like Boolean, String, Integer etc to have classes and
primitive operations would mean a performance loss. That is wrong.
Introducing classes and primitive operation will cost strictly zero in
*all* use cases, which are legal now. Other use cases (e.g. using
class-wide objects and dispatching) are presently illegal, so the whole
argument is bogus.

As for MI, I doubt it very much that MI for *tagged* types would imply any
overhead in *comparable* cases. But this is another discussion. Again, any
such comparison should be correct. I don't care which cost MI inflicts on
record members inherited through it, because it is not legal now, thus,
irrelevant. Would inheritance from interfaces become more expensive? (a
comparable case) I don't believe it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de