Sharing generic bodies across instantiations.
in [ADA]
|
From: Maciej Sobczak on 29 Jul 2010 10:02 On 29 Lip, 10:03, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > 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 Paragraph, please. Otherwise this discussion is just hand-waving. > You are free to disagree I do. Templates are not macros, do not have the nature of macros, are not their siblings and have no other association with them. > > 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. First: C++ standard places no constraints on how the implementation is organized at the system level. Second: so, I understand, "the back-end tools down to the linker and loader" were more suitable to do it in Ada, right? > > Interestingly, macros cannot use this strategy by their definition. > > They perfectly can. No. 2.1 (C++ standard) defines the phases of translation - macro expansion is performed before syntactic and semantic analysis of tokens. In other words, macros are expanded even before the compiler gets a chance to realize that it compiles a C++ code. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 29 Jul 2010 10:40 On Thu, 29 Jul 2010 07:02:25 -0700 (PDT), Maciej Sobczak wrote: > On 29 Lip, 10:03, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> You are free to disagree > I do. I know. >>> 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. > > First: C++ standard places no constraints on how the implementation is > organized at the system level. What are you trying to say by this? > Second: so, I understand, "the back-end tools down to the linker and > loader" were more suitable to do it in Ada, right? You mean shared Ada generic bodies? Yes they require much less late binding than C++ templates would, if anybody came to a silly idea to compile and then share them. >>> Interestingly, macros cannot use this strategy by their definition. >> >> They perfectly can. > > No. 2.1 (C++ standard) defines the phases of translation - macro > expansion is performed before syntactic and semantic analysis of > tokens. 1. My example of shared macros was MACRO-11. 2. The standard does not put any requirements on how the compiler actually works. Precompiled headers and IDEs with "go to the declaration point" for a #define, or just showing the source, not yet expanded, code, even daring to colorize it, do not take this advise literally. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 29 Jul 2010 16:27 On 29 Lip, 16:40, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > >> It would be technically meaningless, because the back-end tools down to the > >> linker and loader were unsuitable for this. > > > First: C++ standard places no constraints on how the implementation is > > organized at the system level. > > What are you trying to say by this? That it does not matter what was the suitability of the back-end tools, as there is no obligation (as far as the standard is concerned) to use the existing tools. If you are not obliged to use existing tools, you are not constrained by their (lack of) suitability. > > Second: so, I understand, "the back-end tools down to the linker and > > loader" were more suitable to do it in Ada, right? > > You mean shared Ada generic bodies? Yes they require much less late binding > than C++ templates would, Can you elaborate on this, please? > >>> Interestingly, macros cannot use this strategy by their definition. > > >> They perfectly can. > > > No. 2.1 (C++ standard) defines the phases of translation - macro > > expansion is performed before syntactic and semantic analysis of > > tokens. > > 1. My example of shared macros was MACRO-11. I thought we were talking about C++. Or Ada. > 2. The standard does not put any requirements on how the compiler actually > works. Bingo. So why do you put claims that are based on the suitability of some tools? The above point basically contradicts most of what you have said. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 30 Jul 2010 05:09 On Thu, 29 Jul 2010 13:27:05 -0700 (PDT), Maciej Sobczak wrote: > On 29 Lip, 16:40, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>>> It would be technically meaningless, because the back-end tools down to the >>>> linker and loader were unsuitable for this. >> >>> First: C++ standard places no constraints on how the implementation is >>> organized at the system level. >> >> What are you trying to say by this? > > That it does not matter what was the suitability of the back-end > tools, as there is no obligation (as far as the standard is concerned) > to use the existing tools. If you are not obliged to use existing > tools, you are not constrained by their (lack of) suitability. This is obviously wrong. It is like to say that you are not constrained to fly to the Moon even if there is no rocket available. >>> Second: so, I understand, "the back-end tools down to the linker and >>> loader" were more suitable to do it in Ada, right? >> >> You mean shared Ada generic bodies? Yes they require much less late binding >> than C++ templates would, > > Can you elaborate on this, please? Compiled generic bodies, at least in Ada 83, can be parametrized using linker expressions. I didn't looked into Ada 95 tagged types derived within the body from a formal generic parameter, you better as Randy for details. >>>>> Interestingly, macros cannot use this strategy by their definition. >> >>>> They perfectly can. >> >>> No. 2.1 (C++ standard) defines the phases of translation - macro >>> expansion is performed before syntactic and semantic analysis of >>> tokens. >> >> 1. My example of shared macros was MACRO-11. > > I thought we were talking about C++. Or Ada. We were about macros. You claimed that implementation of a macro cannot use something that templates can. This is a sweeping claim, which is obviously wrong. (Especially because C++ templates are macros (:-)) >> 2. The standard does not put any requirements on how the compiler actually >> works. > > Bingo. So why do you put claims that are based on the suitability of > some tools? Because any implementation must use these tools. BTW, the CPU is also such a tool. (To preempt silly claims: the strength of the word "must" may vary from tool to tool.) > The above point basically contradicts most of what you have said. How so? What I said was: 1) C++ tells something about templates 2) C++ is silent about some other things about templates 3) 1 makes something allowed by 2 difficult Where is a contradiction? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 30 Jul 2010 08:31
On 30 Lip, 11:09, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > >> What are you trying to say by this? > > > That it does not matter what was the suitability of the back-end > > tools, as there is no obligation (as far as the standard is concerned) > > to use the existing tools. If you are not obliged to use existing > > tools, you are not constrained by their (lack of) suitability. > > This is obviously wrong. It is like to say that you are not constrained to > fly to the Moon even if there is no rocket available. This is obviously wrong. The language standard is not concerned with what is available, but with what will be developed. Existing practice can of course provide the valuable guideline as well as feasibility data, but is but no means formally constraining. You can standardize flights to the Moon even if there is no rocket. Rockets will be built according to what the standard says. > >> You mean shared Ada generic bodies? Yes they require much less late binding > >> than C++ templates would, > > > Can you elaborate on this, please? > > Compiled generic bodies, at least in Ada 83, can be parametrized using > linker expressions. 1. What are linker expressions? Why they cannot be used with C++? 2. How does this affect the amount of late binding and why is there less of it than with C++ templates? > >> 1. My example of shared macros was MACRO-11. > > > I thought we were talking about C++. Or Ada. > > We were about macros. No, we were talking about going to the Moon. Your tendency to pull the subject in every possible direction just to keep the discussion going is nothing new here. *I* was talking about C++ templates and in that context your claims were wrong. During the discussion I have referred to the C++ standard, whereas you have failed to substantiate your claims in any way other than with unrelated stories. > (Especially because C++ templates are macros (:-)) Handwaving. We are close to EOF. > >> 2. The standard does not put any requirements on how the compiler actually > >> works. > > > Bingo. So why do you put claims that are based on the suitability of > > some tools? > > Because any implementation must use these tools. Implementation must use *some* tools. It might bring its own. > 1) C++ tells something about templates > 2) C++ is silent about some other things about templates > 3) 1 makes something allowed by 2 difficult And we're still nowhere close to the conclusion on sharing generic bodies across instantiations. (we got, however, closer to the Moon in the meantime) > Where is a contradiction? 1. "the back-end tools down to the linker and loader were unsuitable" 2. "The standard does not put any requirements on how the compiler actually works." The two above are exact citations. Frankly, I'm both tired and bored of this discussion. Can we stop? -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 |