From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e93f73587e2bc1c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Sharing generic bodies across instantiations. Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4c4e2d69$0$2378$4d3efbfe@news.sover.net> <4c4f5c28$0$2375$4d3efbfe@news.sover.net> <7da1e21f-bec7-4607-923c-0fd6cbcfc753@t10g2000yqg.googlegroups.com> <1vjqnwxhvr91j.3e8ryvkk8ezv$.dlg@40tude.net> <1e77bsd66fduw.dbrgbk4g2ce7$.dlg@40tude.net> <22db743d-ef73-40fe-886d-9730a2763eaa@c10g2000yqi.googlegroups.com> <5cljc8pc0gv0$.115t79rxo29vs$.dlg@40tude.net> <9ad8b242-fe4c-4871-8c0e-1f1ddec936c7@w31g2000yqb.googlegroups.com> Date: Fri, 30 Jul 2010 11:09:09 +0200 Message-ID: <94v29hel87y$.8jvqfyw964yt.dlg@40tude.net> NNTP-Posting-Date: 30 Jul 2010 11:09:09 CEST NNTP-Posting-Host: bd279ad7.newsspool2.arcor-online.net X-Trace: DXC=ML94Vc_WgXG[kmHKHnaEnMA9EHlD;3YcB4Fo<]lROoRA8kF On Thu, 29 Jul 2010 13:27:05 -0700 (PDT), Maciej Sobczak wrote: > On 29 Lip, 16:40, "Dmitry A. Kazakov" > 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