From -7381940306728023004 X-Google-Thread: f78e5,e4aa14519cca09ff X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Sat, 30 Apr 2005 11:40:04 -0500 Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Delivered-To: std-c++@ucar.edu From: "msalters" Newsgroups: comp.std.c++ Subject: Re: My nitpicks on n1774 Organization: http://groups.google.com Message-ID: <1114785595.237226.56270@g14g2000cwa.googlegroups.com> References: <1gvl3nc.1btw8bq15u28exN%thedl0-usenet1@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=212.123.206.71; posting-account=G8Vn6AwAAAAe3s4qFj7nFOuhEuzTNEir X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU Date: Sat, 30 Apr 2005 11:39:34 CST Lines: 130 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-fcqykXeLtKZu0yVJZMeSGeIBWKr98maLuDItxWSxtg+v2cnx2PeGsScBsnq/L+mu2McPymm+jEUIPTB!Wqjn1LsJw3njeNFQwrg/QrW+xOuizsnzKI9ouChe7wfNJe4BOUkCl38/yK5PUoxWsB2CiyWVag6t!Hro5v35F4RaTBsG+7zAhZVcYgnFxXpRyb4V0Xe4pGg== X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.31 Xref: g2news1.google.com comp.std.c++:4653 Daryle Walker wrote: > [Apologies if this proposal has been superseded] Not yet, but if there is sufficient support for the idea I'll be happy to make a new version. > I'm looking at > . > > 1. 26.5, point 2 > Why shouldn't some memory errors be reported with bad_alloc? A > memory error could occur even if the result was small. What's small? I'd say that if the memory allocation fails, the result is /by definition/ not small - even if it's just 4 bytes. > 2. 26.5.1 > What about a "div" function to get the quotient and remainder > simultaneously? Good point, my first reaction was to find out where I'd lost it. I really have no reason not to include it. > Since unlimited integers can't have operator ~, you may want to add > and_not, or_not, and xor_not functions. (They act like operators &, |, > and ^, but virtually complement their second operand first.) This sounds a bit strange to me, but I'm not sure yet why. > Why aren't the I/O functions generalized for character and traits > types? > Isn't "sgn" the usual computer-math shorthand for the sign function? > Should "even" and "odd" be "is_even" and "is_odd"? Names are of course up to LWG popularity polls, ostream& is shorthand that should have been fixed. > Is there a reason to include the "factorial" function? Can it be > implemented better with inside knowledge of the class? If not, exclude > it unless it gets added to C++ in general (for the built-in numeric > types). AFAIK, yes, this can be done better with inside knowledge. > Shouldn't the "string" and "char const *" constructors be explicit? Probably. > Shouldn't there be a version for "wchar_t const *" and all versions of > "basic_string"? Same oversight, see the relation between the IOstreams operator and the string conversions. > Shouldn't there be an operator ! and a conversion to an unspecified > Boolean type? Probably, this is one class that should live up to the "do as int does" mantra. > 3. 26.5.4 > Don't the operators %= need exception warnings for zero-valued > divisors too? > The operators % need exception warnings. Yes on both. > 5. 26.5.9 > Unlike their declarations, these functions are templated for various > character and traits types. > Neither function respects the various applicable formatting state > controls. > Point 4: "x" is not a complex number. (Too much copy & paste?) > Point 4: "char(x%10)" isn't valid. It probably should be "char( '0' > + x % 10 )". "Various applicable formatting state" is something I'm not entirely certain about. > 6. 26.5.10 > I don't think the definition of "pow" makes any sense. How does the > "factorial" function get involved? Unchecked application of copy/paste keys ;) > 7. Rationale > I have no problems with rearranging the sections so comes > just after . > Why is unsigned_integer too complex? It's far simpler to implement > (except for subtraction, negation, and decrement) and bitwise operations > are more sensical. You could use it to implement integer. Anyway, the > built-in types have both versions. This is a case where I'd want more than one opinion > Having prefix versions of ++ and -- without postfix versions is an > extreme surprise. Expressions that use an inline postfix need to be > broken up. Just let the user eat the cost of the extra copy. Another point for the LWG to decide IMHO. > integer operator <<(long long, size_t) is illegal anyway since both > operands are built-ins and the return type isn't considered. Eh, that is exactly what makes it CWG ;). No reason why they can't make it a built-in returning a library type. Quite a few why they /shouldn't/, but no reason why they /can't/. > Should there be a "fma" function? (It stands for fused > multiply-add.) Perhaps, although I've also had a request for more explicit references to/support for ET implementations. They can get FMA for free. Regards, Michiel Salters --- [ 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 ]