From 8693555353111915409 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,8d9af67f0c48e4ef X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,8d9af67f0c48e4ef X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-05-03 07:42:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!paloalto-snh1.gtei.net!denver-snf1.gtei.net!news.gtei.net!namche.sun.com!news2me.EBay.Sun.COM!sunnews1.Eng.Sun.COM!engnews1.eng.sun.com!taumet!clamage From: "Ken Hagan" Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: Re: Unsignedness of size_t Date: 3 May 2002 14:37:50 GMT Organization: unknown Lines: 49 Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: <1020331497.1602.0.nnrp-14.3e31ffea@news.demon.co.uk> References: <3CC7DB8F.52E75D62@bawi.org> NNTP-Posting-Host: taumet.eng.sun.com X-NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Thu, 2 May 2002 10:26:18 +0100 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPNG2nUHMCo9UcraBAQEprAIAtGKsposrW4uLJ/7u+8wD3zYjOQnzohc6 IpTXHRGOn+jxnEea3IokIDEQXQXzk5HKpwSlw07w0L1H7s364xCv8A== =l3xa X-Approved-For-Group: jep@[151.161.11.6] comp.lang.c++.moderated X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Content-Length: 1967 X-Status: $$$T X-UID: 0000000001 Originator: clamage@taumet Xref: archiver1.google.com comp.std.c++:11004 comp.lang.c++.moderated:42586 "Jack Klein" wrote... > > The real problem is not so much that size_t is an unsigned integer > type, but the rules of promotion for unsigned types. I am not the > only one who thinks that the "value preserving" choice for value > promotions in C89/C90 was unfortunate. I'm not sure I agree with the phrase "value preserving". Consider the following code (all integers) a = (b*c)/d; What I would call a "value preserving" language would ignore the size and (un)signed-ness of the variables on the right hand side. It would take their values and generate whatever code was needed to get the mathematically correct answer assuming they were integers of unlimited range. It would then perform whatever truncation was needed to squeeze the answer into a. Clearly this forces compilers to deal with arbitrarily wide computations and the assignment to "a" is possibly value-destroying. However, I think the above proposal has fewer gotchas than the present arrangement. Also, a compiler can see that many expressions need only be evaluated at reduced precision since they are assigned to narrow result variables anyway. For example, int a,b,c; /*...*/ a = b+c; A compiler need not widen b+c, since we truncate it immediately. Programmers who actually want wrap-around in sub-expressions (rather than only at assignments) can just introduce a temporary. Of course, another use for extended precision would be to calculate the number of lines of existing code that my proposal would break. :) [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ] [ 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.jamesd.demon.co.uk/csc/faq.html ]