From 3338880140490421401 X-Google-Thread: f78e5,e4aa14519cca09ff X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!newscon06.news.prodigy.com!prodigy.net!news-FFM2.ecrc.net!newsfeed00.sul.t-online.de!t-online.de!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: dsp@bdal.de (=?ISO-8859-15?Q?=22Daniel_Kr=FCgler_=28ne_Spangenberg=29=22?=) Newsgroups: comp.std.c++ Subject: Re: My nitpicks on n1774 Date: Thu, 5 May 2005 21:20:14 GMT Lines: 168 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <42788af6$0$297$4d4ebb8e@businessnews.de.uu.net> References: <1gvl3nc.1btw8bq15u28exN%thedl0-usenet1@yahoo.com> <1114785595.237226.56270@g14g2000cwa.googlegroups.com> <87vf63z31d.fsf@Astalo.kon.iki.fi> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1115328026 24770 158.152.254.254 (5 May 2005 21:20:26 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 5 May 2005 21:20:26 +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 j45LKNHb009065 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 j45LKE9w009014; Fri, 6 May 2005 07:20:14 +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++:4664 Hello Kalle Olavi Niemitalo, Kalle Olavi Niemitalo schrieb: >"msalters" writes: > =20 > >Also, I think it will be easier to recover from the exception >(e.g. retry with a different algorithm that allocates less >memory) if it is a bad_alloc rather than overflow_error. Or >define a new exception class derived from both? > I think bad_alloc is fine. The problem with a derived exception class in=20 namespace std describing something like overflow_error but not being overflow_error=20 would cause more trouble. One alternative could be an in-class-exception class like std::integer::failure; (Similar to std::ios_base::failure) >[lib.integer.members] #10: Does the constructor also throw if the >string contains no digits, or if the string contains '+' or '-' >anywhere except at the beginning? > Good point. I think one should use a somewhat more constrained rule as=20 in 22.2.3.1/p. 2. (which rules out empty digit sequences, multiple sign chars and sign=20 chars at other positions than at the front) Something along: simple_integer ::=3D [plusminus]digits where plusminus and digits are defined in the quoted paragraph. >[lib.integer.members] #8-#12: There could also be a constructor >that takes a range of chars delimited by two bidirectional >iterators. Perhaps even remove the conversion from std::string >altogether. integer(char const*) should still be kept because it >is so convenient with string literals. > I would not remove the c'tor accepting a std::string. Instead I would=20 propose the following ones (which are analogous to those provided by std::bitset and=20 boost::dynamic_bitset): template explicit integer( const basic_string& str, typename basic_string::size_type pos =3D 0, typename basic_string::size_type n =3D basic_string::npos, const Allocator& alloc =3D Allocator()); template integer(CharInputIterator first, CharInputIterator last,=20 const Allocator& alloc =3D Allocator()); (The Allocator might be viewed as an extension of the integer proposal=20 making it to a class template of typename Allocator) Why should your proposed char iterators be bidirectional? >[lib.integer.members] #8-#12: The constructor could take the >numeric base as another parameter (int base =3D 10). When the base >is a power of 2, the complexity can be O(N) in typical >implementations. I think it'd be better not to add a constructor >integer(char const*, int base), because it'd be too easy to >assume the second parameter is the length of the string. >Possibly allow base=3D=3D0 with the same meaning as in strtol. > Do you imply, that the integer should store the provided base? If so, I=20 would not like this idea, which would have further implications concerning expectd behaviour in io=20 situations (and maybe others). Instead of integer(const char* s, int base); one could provide: template integer(CharInputIterator first, CharInputIterator last, int base); (modulo Allocator) or something like integer(const char* s, base_tag, int base); where base_tag is some convenient helper type (empty struct or helper enu= m) >[lib.integer.members] #25: Preventing out_of_range also requires >a comparison to integer(LONGLONG_MIN). > Yes, correct. >[lib.integer.member.arithops] #22, #25, #29: How do *=3D and /=3D >round or truncate the result? > Absolutely, this is what I also mentioned concerning the questionable=20 double overloads. But why #25? Or do you simply mean the general behaviour of these=20 operators? In this case a reference to 5.6/p. 4 (Or a description equivalent to that)=20 should be fine at least in case of the operators accepting integral types. >[lib.integer.member.bitops]: I'd like to note that Common Lisp >has arbitrary-size integers and specifies that bitwise and shift >operations must treat them as binary two's complement. (The >representation in memory is unspecified.) This means it can have >the equivalent of operator ~ without inconsistencies. > >- dec, hex, oct, showbase: would go along nicely with the base > parameter to the constructor. > I always missed ios_base:bin (or something like this) for integral=20 arguments in binary form. But this is not the right place to complain... (Yes: We no binary literals) >[lib.integer.member.comp] #1: Because the bitwise member >operators do not change the sign, it seems possible to generate a >negative zero. The current wording for operator =3D=3D makes the >negative zero compare not equal to a positive zero ("sign" is not >written in the font used for identifiers), with a nasty effect on >operator /=3D. > Good point! I think that +0 and -0 should behave as equal (As you=20 mentioned, it should correctly delegate equality on the out-of-class sign/sgn function). Btw.: I found one further error in the effect description of sign, which=20 currently says: "Returns: - 1 if v<0 , 0 if v=3D=3D0 , and +1 if v>1" which should be corrected to say: "Returns: - 1 if v<0 , 0 if v=3D=3D0 , and +1 if v>0" Furtheron a question to the experts: Isn't the effect description of=20 sign circular concerning to that of the relational operators? The proposal obviously does not want to=20 define sign in terms of the **operators** <, >, and =3D=3D. What is the correct standardese to define= =20 it? (I could also not find the effect description of the relation operators of built-in types, 5.9=20 seems not to describe it) 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 ]