From 3716780754066738699 X-Google-Thread: f78e5,ac8f7c796c0ee2eb X-Google-Attributes: gidf78e5,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: James Kanze Newsgroups: comp.std.c++ Subject: Re: std::pair istream >> operator Date: Thu, 29 Nov 2007 11:07:50 CST Organization: http://groups.google.com Lines: 89 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <92a741eb-f9f2-40dc-b252-5f53a451af13@w34g2000hsg.googlegroups.com> <84eb137f-aa46-443e-8f6a-912487da73ad@p69g2000hsa.googlegroups.com> <63447783-3e0d-41f8-98a6-62f69025e631@d50g2000hsf.googlegroups.com> <01a449b0-f514-44ff-9949-5a65d6e2dc46@w34g2000hsg.googlegroups.com> <320d4cda-ad86-4c19-83ea-8c3fcc23e110@s36g2000prg.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1196347724 21835 127.0.0.1 (29 Nov 2007 14:48:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 29 Nov 2007 14:48:44 +0000 (UTC) Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu X-SMTP-Auth: no Complaints-To: groups-abuse@google.com Injection-Info: x69g2000hsx.googlegroups.com; posting-host=62.160.54.162; posting-account=1W_PtwoAAAA1QoMcl2Z5P6j-DNc8HR3W User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9,gzip(gfe),gzip(gfe) Content-Disposition: inline X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.csse.unimelb.edu.au id lATEn7uU002333 X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news1.google.com comp.std.c++:9717 On Nov 28, 6:55 pm, Martin wrote: > > The solution I'd always seen (in pre-standard complex) was to > > apply (width()-3)/2 to each of the components of the complex. > The draft standard says about stream::operator<< > Effects: inserts the complex number x onto the stream o as if it were > implemented as follows: > template > basic_ostream& > operator<<(basic_ostream& o, const complex& x) > { > basic_ostringstream s; > s.flags(o.flags()); > s.imbue(o.getloc()); > s.precision(o.precision()); > s << '(' << x.real() << "," << x.imag() << ')'; > return o << s.str(); > } That's not the draft; that's the current state. And there's a DR because of it, I think; it's obviously broken. (You can't even use it in most locales; it would result in something like (1,0,2,0) in the French locale, for example.) > > > If I could put in a recommendation it would be: > > > - Add a separator field to the ios_base structure (default = > > > traits::eof() -> ctype.isspace for input and space for output) > > > - Add manipulators: separator, setseparator, showseparator, > > > noshowseparator (default) > > > - Width, fill etc applies to each item (but not the separator) > > > - separator is also used to end stream input for string. > > None of which addresses the basic problem of outputting > > std::pair (or boost::tuple): the fact that the type may have > > different semantic signification at different places in the > > program. > Isn't that something that applies to all types? Not to the same degree. > Built in types like double got modifers on format, precision > etc. If you need some non-standard formatting you implement > your own but it still nice to have a default. The problem is that, unlike double, there is no reasonable default. > > Although there may be some special cases, my own feeling is that > > any use of std::pair (and probably most uses of boost::tuple) > > are simply poor programming. > I agree but admit I'm using them a lot. Specially in containers. > To make your own "named_tuple" you need to implement the > operators as well. I have some macros to do it but it quickly > get inconvenient. > If I temporary need a set or map with 2 values inside a > funtion I just do a single line > typedef std::map > mymap; This is fine for quick hacking, but it's not something that would make its way into production code. The fact that those two values are associated has some application specific signification, and their names in the association aren't first and second. Consider something like the return value of map<>::insert. Does the name "first" tell me in any way whether I'm dealing with the iterator or the indication as to whether the insertion changed something or not? (Admittedly, that's an extreme case: but even in the case of ranges, wouldn't names like top, or upper be more appropriate.) -- James Kanze (GABI Software) email:james.kanze@gmail.com Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 --- [ 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 ]