From: Maciej Sobczak on
On 28 Lip, 11:28, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:

> >> That is, the nature of C++ essentially requires a
> >> replication strategy.
>
> > Why? What part of that "nature" requires it?
>
> Macro's nature

Wrong. Macros have nothing to do with templates.

> > But, for the sake of exercise, think about a C++ *interpreter*.
>
> Interpreter is an obvious non-starter in this context. Generics are
> considered compilable.

Paragraph, please.

> (There is no crisp line between compiled and
> interpreted)

That's the point.
A C++ or Ada interpreter can be fully standard-compliant, which makes
it a very valid "starter" in this context.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Maciej Sobczak on
On 28 Lip, 13:27, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote:

> For example
>
> template< typename T >
> void f(const T &object)
> {
>   typename T::helper internal;
>   ...
>
> }
>
> Here T::helper might be a class or a typedef.

Which makes no difference from the point of view of how to implement
that.
Think about:

char buf[sizeof(T)];

This is essentially the only problem that you have to solve, and that
does not seem to be very difficult.

> Depending on what it is a
> wide variety of uses are possible.

No, all uses have to be compatible with the code of the template. Even
though each T can have different ways of being used, the template has
to target the common subset of all such possibilities - otherwise the
program will not compile.
In other words, it does not matter how wide is the variety introduced
by different Ts - if the program compiles at all, it means that the
template is compatible with the common subset of all Ts uses. This
removes the variety out of the picture.

> There could well be other corner cases
> I'm not seeing right now... that is the 'nature' of C++ of which I spoke.

Sorry, but you did not identify any corner case for the moment.

> I realize that implementing the shared model in Ada would be hard as
> well, but Ada constrains much more the way names in generic bodies can
> be used.

Not really. AARM explicitly refers to the code copying when defining
the meaning of generics, see 12.3, especially this:

"The instance is a copy of the text of the template." (12.3/13)

and then a whole lot of consequent descriptions that are implied by
this.

I would even say that by being so explicit with this, AARM gives more
reasons to do macro-expansion than C++.

> > But, for the sake of exercise, think about a C++ *interpreter*.
>
> That seems like a different situation to me. A pure interpreter executes
> code only as needed and only when needed. Without a compilation step
> isn't the question of shared or replicated bodies meaningless?

Bingo and that's my point. This is why it does not make any sense to
say that C++ prevents some implementation scenario.
I can even imagine a combined approach, where each instantiation has a
facade that is distinct (this can target stuff like static objects)
and an actual implementation that is shared.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on
On Wed, 28 Jul 2010 05:55:36 -0700 (PDT), Maciej Sobczak wrote:

> On 28 Lip, 11:28, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>>>> That is, the nature of C++ essentially requires a
>>>> replication strategy.
>>
>>> Why? What part of that "nature" requires it?
>>
>> Macro's nature
>
> Wrong. Macros have nothing to do with templates.

They have the nature of source level uncontrolled and untyped substitution
and reinterpretation.

>>> But, for the sake of exercise, think about a C++ *interpreter*.
>>
>> Interpreter is an obvious non-starter in this context. Generics are
>> considered compilable.
>
> Paragraph, please.
>
>> (There is no crisp line between compiled and
>> interpreted)
>
> That's the point.

Nope. The difference still exists, even if not qualitative. It can be
measured in terms of performance, usability, complexity, security etc.

> A C++ or Ada interpreter can be fully standard-compliant, which makes
> it a very valid "starter" in this context.

Interpreter does not qualify as a compiler, per definition of both. You
might say that apple is as edible as orange, but that would not make it
orange in the context of the greengrocery.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Peter C. Chapin on
On 2010-07-28 09:10, Maciej Sobczak wrote:

>> Here T::helper might be a class or a typedef.
>
> Which makes no difference from the point of view of how to implement
> that. Think about:
>
> char buf[sizeof(T)];
>
> This is essentially the only problem that you have to solve, and that
> does not seem to be very difficult.

Well there could be more to it than that. If T is a class with methods
(that are used in the template body) then the shared implementation
approach would have to contend with that. If the template body tries to
derive a class from T, perhaps overriding some of T's virtual functions
there is that to think about as well. Perhaps the template body will
throw a T object as an exception... although that might not be any more
complicated than tracking T's copy constructor and destructor.

In any case it seems like the compiler, in the shared implementation
approach, would have to pass in a hidden object into the template code
that details the capabilities of T that could be used by the shared
generic code (pointers to appropriate functions, etc). I can see that
only the capabilities actually used by the template would need to be
described but there would certainly be more than just the size of a T
involved.

I assume this is how it would work in Ada as well. The difference is
(might be) that in Ada there are more limitations on what a generic can
do so the list of things to worry about would be shorter.

As I said I haven't implemented either an Ada compiler nor a C++
compiler so I'm not sure exactly what the problems might be. That is
what I was asking. :)

> Not really. AARM explicitly refers to the code copying when defining
> the meaning of generics, see 12.3, especially this:
>
> "The instance is a copy of the text of the template." (12.3/13)

That's interesting. Thanks for pointing that out. I wonder if that's
intended to be taken literally or if that really means the instance must
behave "as if" it is a copy of the text of the template.

> Bingo and that's my point. This is why it does not make any sense to
> say that C++ prevents some implementation scenario.

Well, okay. I see what you mean. To say the standard forbids a certain
implementation strategy is perhaps going too far. But there is a sense
of what can reasonably be done. The C++ community doesn't talk much
about a shared implementation of templates. Is that because it's just
unreasonably difficult in C++? I think many people in that community
would regard a pure interpreter as having too big a performance hit to
be acceptable. Of course I can't speak for everyone.

Peter
From: Robert A Duff on
"Peter C. Chapin" <pcc482719(a)gmail.com> writes:

> That's interesting. Thanks for pointing that out. I wonder if that's
> intended to be taken literally or if that really means the instance must
> behave "as if" it is a copy of the text of the template.

All formal language rules of all high-level languages mean "as if".
That goes without saying.

- Bob