From 8228689175085019943 X-Google-Thread: f78e5,c9a289c55d59e43d X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!msrtrans!msrn-in!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "Richard Smith" Newsgroups: comp.std.c++ Subject: Re: non-type template parameter in the new std. Date: Tue, 18 Jul 2006 10:25:11 CST Organization: http://groups.google.com Lines: 58 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1153231116.148076.219940@h48g2000cwc.googlegroups.com> References: <1152726032.559269.324790@75g2000cwc.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1153231121 23358 127.0.0.1 (18 Jul 2006 13:58:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 18 Jul 2006 13:58:41 +0000 (UTC) Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20060109 Firefox/1.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: h48g2000cwc.googlegroups.com; posting-host=217.206.92.194; posting-account=359WWg0AAAA2-4e3vEK4vPAh3j9nKTHe X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:2846 Dave Harris wrote: > richard@ex-parrot.com (Richard Smith) wrote (abridged): > > werasm wrote: > > > 1) Are floating point numbers non-type template parameters in the > > > latest standard. > > > > Not at present. The rationale being that when cross compiling, the > > compiler would need to exactly emulate the floating point behaviour of > > the target processor, right down to the details of rounding, handling > > of NaNs and infinites, etc. > > Actually, as I understand it the problem is one of type checking. Definitely. The compiler has to understand the issues of rounding, etc., at compile time *because* this detail can be folded into the type system and therefore needs to be manipulated at compile time. If it didn't, it could simply use the lexical representation of the expressions used (e.g. "1.0/3.0") in the type system, and defer evaluation until run-time. >Given: > > template struct X {}; > > void func( X<0.3333> ) {} > void func( X<1.0/3.0> ) {} > > is this two definitions of the same function that violates the > one-definition rule, or are there two functions that take arguments of > different types? The answer depends on the precision of the floating > point, so we can't say whether the program is type-correct without knowing > more about the implementation than we should. > > This is not really about cross-compiling. It is about *all* compilers > being consistent, rather than one compiler emulating one other processor. Well, it's harder for a cross-compilers. If a non-cross-compiler needs to know whether 1.0/3.0 == 0.3333 at compile time, it can simply evaluate the expression and find out. (I appreciate that this is an oversimplification on processors that allow their floating point characteristics to be modified at run-time, as I believe certain IBM mainframes do. And even on the ix86 architecture, such things can depend on whether the whether intermediate expressions stay on the 80-bit FPU register stack or are moved into memory. But presumably relying on such details would be undefined, or maybe implementation defined, behaviour.) -- Richard Smith --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]