Sharing generic bodies across instantiations.
in [ADA]
|
From: Maciej Sobczak on 28 Jul 2010 15:48 On 28 Lip, 15:16, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > Wrong. Macros have nothing to do with templates. > > They have the nature We were talking about the nature of templates, not the nature of macros. Macros have nothing to do with templates except for the fact that both are supported by a single language, but there are also languages that support only one or none of them. Reasoning about templates based on macros' nature is pointless. > Interpreter does not qualify as a compiler, So the discussion was limited to compilers only? I did not found this constraint in the original post. Even if we assume such a limitation of discussion, there is still nothing particular in the C++ standard that would prevent code sharing as an implementation strategy for templates. Interestingly, macros cannot use this strategy by their definition. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Maciej Sobczak on 28 Jul 2010 16:03 On 28 Lip, 18:32, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote: > The C++ community doesn't talk much > about a shared implementation of templates. Is that because it's just > unreasonably difficult in C++? Or maybe just pointless, regardless of the difficulty. I don't see any reason for doing it, really. The only possible reason would be to minimize the size of executable, possibly targeting some very constrained environment, but there are ways to do it more efficiently than with code sharing in templates - the technique, based on making a facade template implemented in terms of non-template actual code, was described by Scott Meyers, although at the moment I don't remember exactly which of his book covered it. The major advantage of this technique was *no performance penalty*. That is - small *and* fast code. In other words, the real reason for not having such compiler implementations might be that simply nobody needs them. Imagine yourself as a compiler vendor and try to answer a question if it makes sense to invest effort in this implementation strategy. If nobody asks for it, then probably not - and the market position of those Ada compilers that do it (code sharing) when compared to those that don't might indicate that this technique is not terribly shaking the Ada community either. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Keith Thompson on 28 Jul 2010 16:01 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > 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. Macros do. Templates don't. [...] >> 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. Apples and oranges are both fruits. Compilers and interpreters are both implementations. Either a compiler or an interpreter can be a compliant implementation of a language. If you think a compiler is required, consider a hypothetical system in which the "compiler" simply creates a copy the source code, and the run-time environment interprets and executes the source code. Such an implementation wouldn't be easy to create, but I can't think of any way in which it violates the standard for either C++ or Ada. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Dmitry A. Kazakov on 29 Jul 2010 03:46 On Wed, 28 Jul 2010 13:01:43 -0700, Keith Thompson wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >> 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. > > Macros do. Templates don't. They do. The only limit put on the substitution is that the reinterpretation does not fail. There are no traces of any semantics in the declaration of the template parameters. Generics suffer this too, but to a lesser extent. >>> 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. > > Apples and oranges are both fruits. So what? You don't pay for apples when buy oranges. > Compilers and interpreters are both implementations. It is about the implementation to take. The question was about shared implementation of generics. Certainly, expanded implementations do implement generics, or at least we hope so... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 29 Jul 2010 04:03
On Wed, 28 Jul 2010 12:48:57 -0700 (PDT), Maciej Sobczak wrote: > On 28 Lip, 15:16, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> Wrong. Macros have nothing to do with templates. >> >> They have the nature > > We were talking about the nature of templates, not the nature of > macros. Yep, and the point was that templates being by the nature marcos like to be expanded on the source level. You are free to disagree and put any other reason why templates are 99.(9)% expanded. But this one is good to me. >> Interpreter does not qualify as a compiler, > > So the discussion was limited to compilers only? I did not found this > constraint in the original post. It came as Peter tried to define the meaning of a template body being shared. A sound definition would be compiled body. > Even if we assume such a limitation of discussion, there is still > nothing particular in the C++ standard that would prevent code sharing > as an implementation strategy for templates. It would be technically meaningless, because the back-end tools down to the linker and loader were unsuitable for this. > Interestingly, macros cannot use this strategy by their definition. They perfectly can. For example DEC indeed had macro libraries. They were nothing but collections of shared macros. If the strategy were to call MACRO-11 at run time of the library member each time you liked to execute/interpret/expand it, then this could be done. No problem, except that nobody would do that. Why? Because of the nature of macros and templates. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |