Re: Why no Ada.Wide_Directories?

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]

"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. 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.

You might think that such a compiler's output could be optimized to a more 
efficient version. Indeed, that was the original premise behind Janus/Ada 
(optimization could eliminate the cost of generic sharing, pervasive heap 
allocation of objects, etc.) But it didn't work, the optimizations were too 
complex to be very practical other than in the simplest of circumstances. 
Ultimately, we bit the bullet and supported multiple representations for 
arrays, records, and the like, because that got rid of a lot of the expense 
at the source. But it also added a whole lot of complexity to the compiler.

It's possible that a from-scratch compiler design could do better, but I 
doubt it. And it seems unlikely that anyone will be doing one of those for 
Ada anytime soon.

                           Randy.