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.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,571930b4ff0bc1ee X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-02 06:12:00 PST Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!howland.erols.net!cyclone2.usenetserver.com!news-out.usenetserver.com!newscon06.news.prodigy.com!prodigy.com!newsmst01!postmaster.news.prodigy.com!newssvr16.news.prodigy.com.POSTED!not-for-mail From: "Ken Garlington" Newsgroups: comp.lang.ada References: <3AC03CCE.70E3C2D5@mida.se> <3AC18DD1.EF25CE42@mida.se> <5mzw6.415$1H6.72722473@newssvr16.news.prodigy.com> <3AC2EB17.33AAEC0A@mida.se> <3AC46252.B7E54EA6@free.fr> <3AC4B7F9.7C73455A@free.fr> <3AC6ED5F.9F2F51A5@free.fr> <3AC84628.D8B70C7C@free.fr> Subject: Re: Compile time executed functions Organization: ex-FlashNet, now Prodigy X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: NNTP-Posting-Host: 65.65.210.133 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr16.news.prodigy.com 986216995 6207069 65.65.210.133 (Mon, 02 Apr 2001 09:09:55 EDT) NNTP-Posting-Date: Mon, 02 Apr 2001 09:09:55 EDT Date: Mon, 02 Apr 2001 13:09:55 GMT Xref: supernews.google.com comp.lang.ada:6332 Date: 2001-04-02T13:09:55+00:00 List-Id: "Jean-Marc Bourguet" wrote in message news:3AC84628.D8B70C7C@free.fr... : Ken Garlington wrote: : > : > "Jean-Marc Bourguet" wrote in message : > news:3AC6ED5F.9F2F51A5@free.fr... : > : > : I think there are NO requirement about generated code excepted the : > : observable behavior for conforming program. Everybody would be : > : surprised that the generated code for the factorial template I gave : > : produced something other than what is generated for : > : : > : int main() { : > : std::cout << 3628800 << std::endl; : > : } : > : > Well, I think you've answered your question, then. : > You're not talking about comparing the C++ language with Ada; : : My question? Sorry, "the" question. : Me comparing C++ and Ada? I think you are confusing me : with somebody else. I came into this thread when you asked for an : example of using template in C++ for computing things at compile time to : give you one. More specifically, I asked "Could you post an example of such a template, and what in the C++ standard you rely upon to guarantee compile-time calculations?" : Then you asked for a formal guarantee that it was : computed at compile time. Note that this was part of my *initial* question to which you first responded, and is important given the *original* question: "I'd like to have the compiler to execute a function for me (at compile time!) and use the return of that function to initialize the constant." Also relevant was the later statement "Ada generics is not as expressiv [sic] as C++ templates with regard to what you can get the compiler to execute for you at compile time." As you've indicated, there apparently is no guarantee that a C++ template will be "executed at compile time." It simply tends to be the behavior available from certain compilers. Similarly, there are some Ada compilers that can optimize functions down to a constants, depending upon the compiler and the nature of the function. If the customer base believes that a particular optimization is important, the vendor will probably support it (or go out of business). Therefore, if you want more optimizations, you probably aren't talking about something that is part of the language. : The level at which the C++ standard describe : semantic make it impossible to have such guarantee. Do you have a : formal guarantee that an Ada compiler does not generate a function to : calculate the 10! when you use the litteral 3628800? Which is exactly the point - there doesn't seem to be a true "compile time" function with respect to either language, only optimization techniques that are applied to various degree in *instances* of the language. Note that it could be possible for a language to define required optimizations -- Erlang, for example, appears to do so with tail recursion -- but asking for Ada to provide the "same guarantees" as C++ in this area is vacuously true, AFAIK. : I don't think so : and there is no such guarantee for C++. What the C++ standard does is : constraint the expression to be a constant integer expression and allows : the defined named and such expressions to be used in place like case : labels, array sizes and template parameters where no C++ programmer : would expect the expression be evaluated at run-time, where no sane C++ : compiler would evaluate the expression at run-time. This sounds suspiciously like a "guarantee". Do most "sane" C++ programmers expect things that aren't there? ;) I assume what you mean is that most C++ compilers tend to share certain standard optimizations, and that as a result it would surprise a C++ programmer if they weren't done (assuming they would notice). Of course, the problem with this is that there's no formal list of what "everyone" expects, and so I imagine "surprises" do occur from time to time. If your program was depending upon not being surprised, this would be a Bad Thing -- thus, it's always a good idea IMHO not to depend upon such "sanity". : > So, if you want a particular optimization with an Ada : > compiler, then you need to look at the object code generated by that : > compiler, and tweak it as needed (and possibly work with the vendor to get : > what you want). : : I think the success of "template meta programming" (as this abuse of the : template system is called by some) is the fact that there is no need to : count on compiler optimization to get the effect, This is a particularly puzzling statement. Why do you believe you are not counting on a compiler optimization for the case you presented? : and you may also do : some other things like computing type. So running this : : #include : : template : struct factorial { : enum { RET = factorial::RET*F }; : }; : : template <> : struct factorial<1> { : enum { RET = 1 }; : }; : : template : struct ken { : typedef int T; : }; : : template <> : struct ken<3628800> { : typedef double T; : }; : : int main() { : ken::RET >::T x10 = 0.5; : ken::RET >::T x11 = 0.5; : std::cout << "x10=" << x10 : << "\nx11=" << x11 << std::endl; : } : : produces : : x10=0.5 : x11=0 : : because x10 is a double while x11 is an int. But I agree, that is still : not a formal guarantee that the compiler does not compute the type of : x10 and x11 at run time :-) I'm not sure what it means to "compute a type." I assume you're talking about type conversions? Most Ada compilers also can optimize type conversions under the right conditions, e.g. trivially: X : constant Integer := Integer(0.5); will usually not generate any code to do the conversion. Again, however, this is a compiler-specific optimization, not a requirement of the language. : Some seems to think that the biggest difference between Ada generic and : C++ template is the fact that the templates are instanciated : automatically or that they are constrained by use. My point of view is : that these differences are syntaxic differences and do not modify : significantly the expressing power. I think that the ability to : specialize template is a point where the C++ templates are more : powerfull than the Ada generics. : : Yours, : : -- Jean-Marc