OK. Answered my own question. What you'll need is a template definitions
just like this:
template< class x, class y >
ost::Engine& operator >>( ost::Engine& ar, std::pair< x, y >& ob)
{
ar >> ob.first
>> ob.second;
return ar;
}
template< class x, class y >
ost::Engine& operator <<( ost::Engine& ar, std::pair< x, y > const& ob)
{
ar << ob.first
<< ob.second;
return ar;
}
This will provide the needed operators so that any std::pairs that contain
persistent types, the paris can be streamed to/from persistence.
This is kinda handy, paring up two values like this. You suppose that it
could be included in the library in the future?
On Tue, November 23, 2004 13:45, Erik Ohrnberger said:
I've just discovered a need of mine where I need to persist using the
std::pair template from the STL. The declaration is:
std::vector< std::pair< std::string, std::vector< std::string > > >
items;
This is essentially a list of named string lists.
When I try to use the normal ::read and ::write methods with the class
housing the items, I get a compiler error about not having a needed
operator:
/usr/include/cc++2/cc++/persist.h:504: error: no match for 'operator<<' in
'ar << (+ob)->std::vector<_Tp, Alloc>::operator[] [with _Tp =
std::pair<std::string, std::vector<std::string,
std::allocator<std::string> > >, _Alloc =
std::allocator<std::pair<std::string, std::vector<std::string,
std::allocator<std::string> > > >](i)'
OK, so I figure that it must be std::pair, 'cause I use std::vector<
std::string > all over the place. There must be a way to declare a
template operator method for any and all std::pairs to be persistable.
Something like this (although this is not correct, but should convey the
idea.
template< class x, class y >
ost::Engine& operator >>( ost::Engine& ar, std::pair< x, y >& ob)
{
ar.read( ob.first );
ar.read( ob.second );
return ar;
}
template< class x, class y >
ost::Engine& operator <<( ost::Engine& ar, std::pair< x, y > const& ob)
{
ar.write( ob.first );
ar.write( ob.second );
return ar;
}
Is this all wrong and I'm barking up the wrong tree, or is there a better
way to accomplish the same thing?
Any hints for pointers would be greatly appreciated.
Thanks,
Erik.
_______________________________________________
Bug-commoncpp mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-commoncpp
_______________________________________________
Bug-commoncpp mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-commoncpp