Re: Correct swapping
On 19 Apr., 10:50, Carl Barron <cbarron...@adelphia.net> wrote:
In article <1176934203.246655.276...@y80g2000hsf.googlegroups.com>,
Daniel Kr?gler <daniel.krueg...@googlemail.com> wrote:
Another point to consider is, that it's usually a bad idea, to
provide operator<< on some arbitrary std::pair, because neither
std::pair nor std::ostream are *your* types. To fix your problem
I recommend in this special situation to use one of the following:
(a) Replace your std::copy invocation by a std::for_each call
(which uses a special print functor and *not* operator<< on
std::pair) or an explicit loop.
(b) Use a better customizable iterator like boost::transform_iterator
which uses the in (a) mentioned print-functor. This ansatz is
nearly identical to your std::copy approach, where you simply
r
Depends if I have a complicated function using an output iterator
I would just create a small class and the needed operator << ().
struct Derived:std::pair<double,double>
{
Derived(double a,double b):std::pair<double,double>(a,b){}
Derived(std::pair<double,double> const
&a):std::pair<double,double>(a){};
Derived & operator == (const std::pair<double,double> &x)
Should probably be:
Derived & operator = (const std::pair<double,double> &x)
[..]
};
inline std::ostream & operator << (std::istream &s,const Derived &x)
Should be:
inline std::ostream & operator << (std::ostream &s,const Derived &x)
I see several problems with this approach:
1) You derive publicly from class which is not designed to be a base
class.
2) You put up with writing a complete new class (which does not bring
any
actual advantages compared to its base class) just to reuse
std::ostream_operator,
although transform_iterator (or something similar) would be the better
choice.
3) Your solution does not work with the OP's use-case, which uses
std::map<?1, ?2>::value_type, which is std::pair<const ?1, ?2>. So
would
have to provide one further class Derived2 to realize this issue - all
of the
implementation is basically the same as in Derived. That is, this
approach
scales badly for related types or problems.
4) You willingly accept the fact, that every std::pair argument from
your
original container is *copied* into a temporary Derived instance
before
output.
5) The above design does not provide more security/encapsulation
compared to defining the criticized
operator<<(std::ostream&,const std::pair<double, double&),
in the first place because the following *will* compile:
void foo(std::ostream& os) {
std::pair<double, double> p; // *not* Derived!
os << p; // Finds and uses operator<<(std::ostream&,const Derived&)
// with one implicit conversion std::pair<double,
double> -> Derived
}
Taking all these points I see no advantage compared to the natural
solution:
void save(const char * filename, const Histogram::Map & data)
{
std::ofstream file(filename);
std::copy(data.begin(),data.end(),
boost::make_transform_iterator(data.begin(), MyPrint(file,"\n"));
}
where MyPrint is the functor in fact replacing
ostream& operator<<(ostream & os, const
Histogram::Map::value_type&pair);
There exists practically no difference in effort in writing MyPrint
compared to
above operator<< in the most simple case. In contrast, it is very easy
to create
a reusable and *non-intrusive* component class (template) from that
one without
polluting the namespace scope with needless/dangerous operator
overloads.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]