Re: std::pair istream >> operator
On Nov 18, 1:30 am, Andrey <andrey_rya...@bk.ru> wrote:
And how would you define it? To do what?
As std::pair provided to treat two values as a single unit
there can be only one posible implementation of this
operator described below.
How's that? You mean that you'd always want "(first,second)"?
Or was that "(first;second)" (since the comma is the decimal
point in a lot of local). Or maybe rather "[first;second]"?
Even when the semantics is clear (e.g. std::complex), it's not
always clear what the representation should be.
std::pair class is widely used in BGL (boost/graph libray).
The question arouse due to using this library. I wanted to use an
algorithm implemented with BGL by a friend of mine using. His library
had this operator defined, as well as my program had.
That's exactly the risk. You end up with two different
definitions. In no case do you want this operator defined.
That made me think that it was quite strange that there had
not beed such operator defined in std namespace.
-------------------------------------------------------
#include <iostream>
namespace my_ns {
template <class First, class Second>
std::istream & operator >> (std::istream & in, std::pair<First,
Second> & p) {
/* debug */ std::cout<<"my_ns::operator >> ";
return in>>p.first>>p.second;
}
}
namespace his_ns {
template <class First, class Second>
std::istream & operator >> (std::istream & in, std::pair<First,
Second> & p) {
/* debug */ std::cout<<"his_ns::operator >> ";
return in>>p.first>>p.second;
}
}
Note that neither of these operators will be found if you're
using something like std::ostream_iterator with an std::pair of
basic types.
I'd also be interested in seeing the operator<<.
"out << p.first << p.second" obviously isn't acceptable.
-----------------------------------------------------------------
I always define it by hand.
I never use std::pair to begin with, so the problem doesn't come
up. If I did, I would also define it by hand. But I see no
reason to suppose that the definition would always be the same.
It's worth discussing.
I was wondering how would you changed the following implementation?
template <class First, class Second>
istream & operator >> (istream & in, pair<First, Second> & p) {
return in>>p.first>>p.second;
}
As I said, I haven't yet found a reasonable use for std::pair.
(I know it's used in std::map, but that use is a good example of
a case where it's use is poor design: the semantics of the two
fields is NOT first and second, but key and value, and they
should be thus named.) I do overload >> and << for the structs
or classes I use instead of std::pair. But I rarely overload it
the same way: if the "pair" represents a range (often the case,
e.g. as in the return value of binary_search), then something
like:
out << '[' << p.first << ';' << p.second << '[' ;
is what I would use here, or
out << '[' << p.first << ',' << p.second << ')' ;
if the output were in English. (How to represent a half-open
interval is locale dependent. And intervals are one case where
std::pair might be acceptable... but you'd still have to tell
the << operator somehow whether the bound was open or closed,
for each bound.)
In my opinion this is the only possible implementation as it
is for operators '<' and '=='.
Try it for output? Does this implementation really do anything
reasonable, e.g. for std::pair<double,double>?
The real problem, of course, is that std::pair doesn't implement
anything, nor even imply any semantics. So first, it's not
generally a good solution for much (because you want the
semantics apparent in the source code), and secondly, what it
should do for << and >> depend very much on the semantics.
--
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 ]