From 2164089670521211541 X-Google-Thread: f78e5,d8e6a7de55590f84 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: gennaro.prota@yahoo.com (Gennaro Prota) Newsgroups: comp.std.c++ Subject: Re: About "integral types" Date: Mon, 19 Feb 2007 16:12:30 GMT Organization: Aioe.org NNTP Server Lines: 106 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <4o6jt21op51eeps7a0t7g6lf4dglnr87dc@4ax.com> References: <1171823016.006307.259000@v45g2000cwv.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1171901556 24315 158.152.254.254 (19 Feb 2007 16:12:36 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 19 Feb 2007 16:12:36 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.csse.unimelb.edu.au id l1JGCXMr007167 X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Replace-Address: yes X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.csse.unimelb.edu.au (8.13.8+Sun/8.13.8/Submit) id l1JGCUww007130; Tue, 20 Feb 2007 03:12:30 +1100 (EST) X-Delivered-To: std-c++@mailman.ucar.edu X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Forte Agent 4.2/32.1118 trialware X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:5630 On Sun, 18 Feb 2007 12:44:50 CST, Daniel Kr=FCgler wrote: >On 18 Feb., 16:59, Gennaro Prota wrote: >> In the current working draft (n2134), paragraph 3.9.1/7 states: >> >> Types bool, char, wchar_t, and the signed and unsigned integer >> types are collectively called integral types >> >> This sentence looks unchanged compared to C++98, but it relies on >> other sentences (defining "signed/unsigned integer type") which >> *did* change. In particular, the meaning of "signed/unsigned >> integer type" now includes implementation-defined extended types. >> So, is the sentence quoted above meant to include those ones too? >> Or was it just not synchronized with the changes made earlier in >> the same section? > >Just my personal 2 Cent: The current meaning (i.e. merging extendend >and standard integer types into integer types) *seems* to be >intended. Otherwise the standard would need to explicitly speak out >the rules concerning valid radices, behavour of unsigned arithmetic >(para 4), the three supported representation types (para 7), etc. for >the extended types also. Yes, makes sense. >Consider also that the integral promotion rules (4.5) have been >generalized by delegation to the integer conversion rank (4.13), >which *explicitely* rules standard and extended integer types, e.g. > >"The rank of any standard integer type shall be greater than the rank >of any extended integer type with the same size." Ah, thanks :-) I didn't notice that. >"The rank of any extended signed integer type relative to another >extended signed integer type with the same size is >implementation-defined, but still subject to the other rules for >determining the integer conversion rank." which implies the wish for >uniform handling. Yep. Off-hand the new section about conversion ranks looked simply copied from C99 (except that the C++ draft doesn't use the concepts of "width" and "precision": so it seems very intentional that C++ is ruling out padding bits in integer types, whereas C99 allows them... another sibling-rivals incompatibility) and I didn't pay attention to it. >This combined handling also leeds to some problems (see some of my >currently active postings concerning "basic integral types", the >missing IO inclusion of the extended integer types, or the incomplete >header synopsis for numeric_limits), most probably just due to >oversights in the wording at those places. > >> One issue here is that we have no longer a standard nomenclature to >> denote the set { bool, char, wchar_t } U StandardIntegerTypes, >> which is what I was looking for. > >Yes, this might be a current gap - also for the type traits. May I >ask, in which use case you needed this distinction? Oh, it was just for documenting one of my library facilities (I didn't want to guarantee by contract that it would work with extended types... the library is meant to work with any standard implementation and supporting implementation-defined features isn't really worth the bother) >> (Incidentally, it would have been nice to solve once for all the >> error-prone distinction "integer" vs. "integral") > >In which sense do you mean that? Just in the terminological sense: the words are IMHO too similar not to cause confusion or oversights (in common parlance and in the standard). >Just the fact of the double existence of this identifiers or some >orthographic reasoning? On the other hand there exist the terms >"integral constant expression" or "integral promotions/conversions" >which *include* enumeration types (although they are excluded from >integer/integral types). Yeah, that's another good point. And then, as noted in Vandevoorde/Josuttis there could be support for floating-point non-type template parameters in future versions of the language; so, for instance, std::integral_constant should actually be called just std::constant, as I did with my version: >An interesting option would be to separate the meaning of integral >and integer, thereby equating > >{integral types} =3D {integer types} U {enumeration types} Yes, not sure how strongly-typed enums would fit in the scheme though. Genny. --- [ 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 ]