Re: Anybody in US using ADA ? One silly idea..

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

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Shared bodies are working against the C++'s myth about unbeatable
>> efficience of templates.
> 
> Do you have any evidence that this is a myth, rather than a fact?

No study I know of. However, it is easy to imagine a case when a non-inlined 
subroutine could be more efficient [in terms of speed] than an inlined one. 
I do not care about the realism of the following example, but let we have a 
sort of applet which runs some simple algorithm for many different types. 
Each time you load it, only one branch for one selected type is executed. 
If the algorithm is an inlined instance, the time for loading, 
initialization of the paged memory, symbol relocation etc, could be longer 
than the time of all dereferences and dispatch.

> That is, in the C++ model of generics, the compiler has all the type
> information available at the point where it is compiling the code,
> so it's hard to see how any other model can be *more* efficient. So
> the best you can hope for is to be as efficient.

Yes. Only "hope" is IMO a wrong word. I think it is indeed possible to make 
tagged types as efficient as fully inlined macro expansions, provided that 
the corresonding class-wide routines are also inlined.

> I think of the
> canonical case as being std::sort, which can inline comparison between
> objects, so sorting an array of integers involves just doing an inline
> machine integer compare.

> Not only that, but the C++ model allows for specialization, so that the
> body of code in question does not all have to come from the same block of
> generic code - there can be completely different bodies for different
> types. This makes generic sharing even less likely there.

My point was:

- either we implement generics as macro expansions and then have 
disadvantages XYZ;

- or we share bodies, loosing some power of generics, so that a question 
arise, why generics and not tagged types?

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de