Re: std::pair istream >> operator
On Nov 28, 6:55 pm, Martin <wpcm...@hotmail.com> 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<class T, class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x)
{
basic_ostringstream<charT, traits> 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<int, std::pair<std::string, int> > 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 orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 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 ]