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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham 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 07:34:03 PST
Path: 
 supernews.google.com!sn-xit-03!supernews.com!freenix!oleane.net!oleane!proxad.net!feeder2.proxad.net!nnrp6.proxad.net.POSTED!not-for-mail
Message-ID: <3AC88CE5.A38C39D@free.fr>
From: Jean-Marc Bourguet <jbourguet@free.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en, French, fr
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Compile time executed functions
References: <3AC03CCE.70E3C2D5@mida.se>
 <OB0w6.272$rl5.40145021@newssvr16.news.prodigy.com>
 <3AC18DD1.EF25CE42@mida.se>
 <5mzw6.415$1H6.72722473@newssvr16.news.prodigy.com>
 <3AC2EB17.33AAEC0A@mida.se>
 <lEHw6.434$2g1.81555482@newssvr16.news.prodigy.com>
 <3AC46252.B7E54EA6@free.fr>
 <xg2x6.2153$db7.413856821@newssvr10-int.news.prodigy.com>
 <3AC4B7F9.7C73455A@free.fr>
 <tfqx6.563$wL.137886776@newssvr16.news.prodigy.com>
 <3AC6ED5F.9F2F51A5@free.fr>
 <clKx6.632$ru5.162431072@newssvr16.news.prodigy.com>
 <3AC84628.D8B70C7C@free.fr>
 <DS_x6.695$UY5.185094242@newssvr16.news.prodigy.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 02 Apr 2001 14:32:22 GMT
NNTP-Posting-Host: 158.140.208.29
X-Complaints-To: abuse@proxad.net
X-Trace: nnrp6.proxad.net 986221942 158.140.208.29 (Mon,
 02 Apr 2001 16:32:22 CEST)
NNTP-Posting-Date: Mon, 02 Apr 2001 16:32:22 CEST
Organization: Guest of ProXad - France
Xref: supernews.google.com comp.lang.ada:6346
Date: 2001-04-02T14:32:22+00:00
List-Id: <comp.lang.ada>

Ken Garlington wrote:
> 
> "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> news:3AC84628.D8B70C7C@free.fr...
[...]
> : 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?

You keep calling evaluating these expressions an optimization.  I think
nobody familiar with C++ will.  There is no formal guarantee but the
trouble would be to make a compiler not compute these at compile time
and still respect the other aspect of the standard.
 
> : and you may also do
> : some other things like computing type.  So running this
> :
> : #include <iostream>
> :
> : template <int F>
> : struct factorial {
> :    enum { RET = factorial<F-1>::RET*F };
> : };
> :
> : template <>
> : struct factorial<1> {
> :    enum { RET = 1 };
> : };
> :
> : template <int F>
> : struct ken {
> :   typedef int T;
> : };
> :
> : template <>
> : struct ken<3628800> {
> :   typedef double T;
> : };
> :
> : int main() {
> :   ken<factorial<10>::RET >::T x10 = 0.5;
> :   ken<factorial<11>::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." 

The type of x10 is double because factorial<10>::RET evaluates to
3628800 and the type of x11 is int because factorial<11>::RET evaluates
to something different than 3628800.  The above program is exactly the
same as

#include <iostream>

int main() {
  double x10 = 0.5;
  int    x11 = 0.5;
  std::cout << "x10=" << x10
            << "\nx11=" << x11 << std::endl; 
}

-- Jean-Marc