From: Maciej Sobczak on 28 Jul 2010 08:55 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 28 Jul 2010 09:10 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 28 Jul 2010 09:16 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 28 Jul 2010 12:32 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 28 Jul 2010 15:30
"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 |