From -769689423040308970 X-Google-Thread: f78e5,e4aa14519cca09ff X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed.stueberl.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: dsp@bdal.de (=?ISO-8859-1?Q?=22Daniel_Kr=FCgler_=28ne_Spangenberg=29=22?=) Newsgroups: comp.std.c++ Subject: Re: My nitpicks on n1774 Date: Wed, 27 Apr 2005 18:31:56 GMT Lines: 133 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <426f40a1$0$308$4d4ebb8e@businessnews.de.uu.net> References: <1gvl3nc.1btw8bq15u28exN%thedl0-usenet1@yahoo.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1114626726 20429 158.152.254.254 (27 Apr 2005 18:32:06 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 27 Apr 2005 18:32:06 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.4) Gecko/20030619 Netscape/7.1 (ax) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id j3RIW32Y016031 X-Accept-Language: de-de, de X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j3RIVuhW015969; Thu, 28 Apr 2005 04:31:56 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:4630 Hello Daryle Walker, Daryle Walker schrieb: >[Apologies if this proposal has been superseded] > >I'm looking at >. > Please have a look at my own posting "Some questions concerning 'big=20 integer' proposal", where I discuss similar (and further) points. > What about a "div" function to get the quotient and remainder >simultaneously? > That would be possible (at least for reasons of consistency), but I see=20 no real advantage. How would you define its signature and return type? Taking consistency into account=20 one would need something like integer_div_t, which is nasty at best, using void div(const integer& numer, const integer& denom, integer& quot,=20 integer& rem); would work, but is not the expected one. Pure C++ style would propably lead to: std::pair div(const integer& numer, const integer&=20 denom); > Isn't "sgn" the usual computer-math shorthand for the sign function? >Should "even" and "odd" be "is_even" and "is_odd"? > I support your view concerning is_odd/is_even, and also for sgn versus=20 sign. Actually the full name would be signum, but sgn is the most popular shorthand. The most=20 important thing is its definition (which is provided), because there exist definitions, which map its=20 argument to +1 and -1 only (0 is mostly assigned to +1 in this case) > 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). > I tend to agree. > Shouldn't the "string" and "char const *" constructors be explicit? > Yes. >Shouldn't there be a version for "wchar_t const *" and all versions of >"basic_string"? > All versions of basic_string: Yes, but why wchar_t const *? Only if this=20 c'tor is added for std::bitset also, and I do not see any reason for that. The valid characters are all=20 necessarily available as char representations. > If there's going to be the "XXX_not" family of functions, then >self-modifying versions need to be added to the actual class. > Shouldn't there be an operator ! and a conversion to an unspecified >Boolean type? > Absolutely! Otherwise the operator long long is invoked with=20 catastrophic consequences, if this conversion exceeds the representation range of long long (exception). >3. 26.5.4 > Don't the operators %=3D need exception warnings for zero-valued >divisors too? > >4. 26.5.7 > The operators % need exception warnings. > Yes. >5. 26.5.9 > Unlike their declarations, these functions are templated for various >character and traits types. > Absolutely (I overlooked that). > 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 )". As it is, you're using code-points 0 through 9, and not >the characters '0' through '9', which aren't garunteed to match. >(Actually, I think they're forbidden to match. The '\0' character must >have a bit pattern of zero and cannot match any valid character.) > To add: I don't think that the current "as if" implementation makes any=20 sense at all (See my posting). >6. 26.5.10 > I don't think the definition of "pow" makes any sense. How does the >"factorial" function get involved? > Absolutely (also overlooked by me). > 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. > I tend to agree. > 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. > Yes. Please read also my remarks concerning operators taking double values as=20 arguments and my discussion concerning conversion rules. Greetings from Bremen, Daniel Kr=FCgler --- [ 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 ]