- Boost - lists.boost.org

Re:Re:[serialization] cyclic references
by Martin Ecker 07 May '04

07 May '04

Robert Ramey wrote: > Francois Fath wrote: > > > I have difficulties when serializing two objects pointing to each other. > > The generated archive is fine (I can see both references in it), but when > > deserializing, only one is restored. In the attached example, I have a > > collection of nodes, each one is pointing to the previous and to the next > > node. When deserializing, only the ->next references are restored, all the > > ->previous are NULL. > > Hmmm - I would have expect to get a "pointer_conflict" exception when the > archive is being created - see test_cyclic_ptrs. Hm, this is unfortunate. MFC's serialization mechanism (via CArchive) supports these kinds of cyclic pointer relationships. I believe, it should be possible to extend boost::serialization to support this as well, especially since the written out archives seem to contain all that is needed to reconstruct the data structure upon deserialization. See my previous mail on this subject on what I think needs to be addressed to achieve this. Am I missing something here or are there other complications that maybe MFC's CArchive cannot deal with or simply disregards with respect to cyclic pointer structures? Best Regards, Martin Ecker

1 0

tuple - pair interoperability
by Fredrik Blomqvist 07 May '04

07 May '04

Hi, I think it would be convenient if one could treat std::pair as a boost two-tuple. Both tuples::tie and tuple assignment already work with std::pair but I've noticed that the get<> accessor doesn't. So, I propose a simple extension to tuples::get<> with the obvious semantics: boost::get<0>(p) == p.first boost::get<1>(p) == p.second The only reference I found in the archives was a post by Tomas Witt early 2002. "Tuple extension proposal": http://lists.boost.org/MailArchives/boost/msg25582.php Should I submit the code I've got or does something like this already exist somewhere? (I've tested the code using VC7.1, it doesn't rely on PTS although member-templates) Regards // Fredrik Blomqvist

4 6

License Conversion Update
by Jaap Suter 07 May '04

07 May '04

Hello, This is a reminder to urge Boost developers to add their names to http://www.boost.org/more/blanket-permission.txt if applicable. In fact, I would also like to see a list of authors who explicitly don't want their libraries be subject to the new Boost license. If anybody wants me to do a license conversion for them, I'd be more than happy to. Just contact me, let me know what library you want converted, and I will send you back the patches. As long as some of the wide-spread libraries (MPL, smart_ptr, etc.) keep their old license, libraries that depend on these are effectively still limited. Thanks, Jaap Suter

13 33

Re:[boost] [serialization] exception during deserialization
by Robert Ramey 07 May '04

07 May '04

Francois wrote: > I am trying to use the serialization library to save an object and a > pointer to the object, but the pointer has the type of the object's base > class. Something like: >// declaration >MyClass myObject; // object, not pointer >MyBaseClass *myPointer = &myObject; >// serialization code >ar & BOOST_SERIALIZATION_NVP(myObject); >ar & BOOST_SERIALIZATION_NVP(myPointer); >And I get an exception (either null reference exception or access >violation) during the deserialization. I am using xml archives. The xml >generated code seems fine. I would expect and "unregistered_class" exception on both serialization and de-serialization. If objects are to be serialized through a base class pointer, they must either: a) Be previously serialized directly or through the derived class pointer. or b) be "forward registered" with the archive. Or c) be "exported" via BOOST_CLASS_EXPORT >template<class Archive> >void serialize(Archive & ar, const unsigned int version) > { > ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Base); > // What is the intended purpose for the following? > // I can't see why one would want to do this. > /* uncomment to avoid the exception > * ar & BOOST_SERIALIZATION_NVP(this); > */ > } >}; Robert Ramey

2 1

calling bind with literals
by Dill, John 07 May '04

07 May '04

I don't know if this was discussed at an earlier point, but I have a suggestion for a workaround of the forwarding problem. The main issue is whether you want to allow literals to be called from the bind_t operator(). I believe it's possible to change the semantics to the same as those within the bind call. In the current implementation of bind, bind( function, ref( object1 ), "literal" )( object2, "No literal" ) object2 is passed by reference, and "No literal" will not work due to binding a literal to a reference. However, I believe it possible to define semantics like this: bind( function, ref( object1 ), "literal" )( object2, "Literal allowed" ) object2 is passed by value, the literal is now allowed bind( function, ref( object1 ), "literal" )( ref( object2 ), "Literal allowed" ) object2 is passed by reference through the reference wrapper, and the literal is still allowed. There are several steps needed to convert the bind/mem_fn to these semantics (roughly): For mem_fn: 1. Change the semantics of mem_fn_template of the reference function to non reference (pass by value). 2. Add another operator() which uses a reference_wrapper. For bind: 3. Add a traits which processes the argument type to give the right semantics: template <class T> argument_traits { typedef T type; }; template <class T> argument_traits<reference_wrapper<T> > { typedef T& type; }; template <class T> argument_traits<reference_wrapper<T const> > { typedef T const& type; }; 4. Remove the reference from the argument type in bind_template.hpp from A1& to A1 for all N for operator(). 5. Process the list_av_N type by argument_traits instead of A1&, A2&, ... I believe that this can be done, but doesn't justify whether it should be done. There are several issues that I see at the moment. A. Changes the semantics of everyone's bind and mem_fn, no biggy there ;-). B. Pass by value is silent, not sure how many copies of the argument will be generated if pass-by-value. But at the same time there is an advantage. a. You can use literals in calling your bind functions. What do you all think? Best, John

7 12

Re:[boost] [serialization] cyclic references
by Robert Ramey 07 May '04

07 May '04

Francois Fath wrote: > I have difficulties when serializing two objects pointing to each other. > The generated archive is fine (I can see both references in it), but when > deserializing, only one is restored. In the attached example, I have a > collection of nodes, each one is pointing to the previous and to the next > node. When deserializing, only the ->next references are restored, all the > ->previous are NULL. Hmmm - I would have expect to get a "pointer_conflict" exception when the archive is being created - see test_cyclic_ptrs. Robert Ramey

1 0

Re: calling bind with literals
by Dill, John 07 May '04

07 May '04

"Douglas Gregor" <gregod(a)cs.rpi.edu> wrote in message news:<200405061958.52886.gregod(a)cs.rpi.edu>... > On Thursday 06 May 2004 05:32 pm, Dill, John wrote: > > I believe that this can be done, but doesn't justify whether it should be > > done. There are several issues that I see at the moment. > > > > A. Changes the semantics of everyone's bind and mem_fn, no biggy there > > ;-). B. Pass by value is silent, not sure how many copies of the argument > > will be generated if pass-by-value. > > > > But at the same time there is an advantage. > > > > a. You can use literals in calling your bind functions. > > > > What do you all think? > > I don't like the change. > > Ideally, bind(f, _1, _2, _3)(x, y, z) would be exactly equivalent to f(x, y, > z). The current bind() implementation gives us nearly this equivalence > because it passes by reference, except that we get a failure at compile time > if one tries to pass a literal. Going to passing by value would take us > further from that ideal equivalence. I see your point. But, what if instead of argument_traits being pass by value, it by default passes by T const&? What could be done is to have the bind_t arguments be passed by const reference, and then use reference_wrapper to do type-selection to pass by reference. It still supports literals, and passes by T const& when it can, but everything that is passed by reference must have a ref( object ). The compiler would fail if you try to pass a reference without a reference_wrapper because it by default tries to pass a T const&. This wouldn't require the 2^N overloads but would require you to do a ref( object ) for everything passed by reference. This might also be a workaround for those compilers that don't support T& and T const& overloading. I think that this should be addressed, either through overloading, or maybe this idea might be feasible. I think the implementation of this aspect of bind is worth doing. Best, John

4 3

[program_options] Checkin candidate
by Vladimir Prus 07 May '04

07 May '04

The next version of the program_options library is available from http://zigzag.cs.msu.su:7813/program_options/ or http://zigzag.cs.msu.su/~ghost/program_options/ The primary change in this version is support for unicode command line and config file parsers. Please see http://zigzag.cs.msu.su:7813/program_options/html/program_options.howto.htm… and the new "unicode_test.cpp" file in the "test" directory. I believe that now all major changes are finished and the library is ready to be added to CVS. If nobody find any showstoppers within a week, I'll go ahead. I'd appreciate any comments on this version. Thanks in advance, Volodya

6 17

Re: Re: calling bind with literals
by Dill, John 07 May '04

07 May '04

"Douglas Gregor" <gregod(a)cs.rpi.edu> wrote in message news:<200405071039.24725.gregod(a)cs.rpi.edu>... > On Friday 07 May 2004 10:30 am, Dill, John wrote: > > I see your point. But, what if instead of argument_traits being pass by > > value, it by default passes by T const&? What could be done is to have the > > bind_t arguments be passed by const reference, and then use > > reference_wrapper to do type-selection to pass by reference. It still > > supports literals, and passes by T const& when it can, but everything that > > is passed by reference must have a ref( object ). The compiler would fail > > if you try to pass a reference without a reference_wrapper because it by > > default tries to pass a T const&. This wouldn't require the 2^N overloads > > but would require you to do a ref( object ) for everything passed by > > reference. This might also be a workaround for those compilers that don't > > support T& and T const& overloading. > > So we'd be trading lvalue support for literal support. In my experience, > lvalues are _much_ more important than literals[*], and we've had these > semantics for a really long time (they'll be part of the C++ Library TR), so > it will take a truly killer argument to change this. > > [*] Thinking of my own work, where I use lots of bind expressions, I remember > only once having to name a temporary to get around the T& issue with bind, > but can thinking of at least 4 places where I pass lvalues through bind. Okay, just trying an idea out. Thanks for your comments. John

1 0

[serialization] cyclic references
by FATH Francois 07 May '04

07 May '04

I have difficulties when serializing two objects pointing to each other. The generated archive is fine (I can see both references in it), but when deserializing, only one is restored. In the attached example, I have a collection of nodes, each one is pointing to the previous and to the next node. When deserializing, only the ->next references are restored, all the ->previous are NULL. The compiler is VC7.1 Thanks, Francois Fath -- Disclaimer ------------------------------------ Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system. #include "stdafx.h" #include <fstream> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> using namespace std; class Node { public: Node(Node *previous = NULL, Node *next = NULL) { id = ++count; this->previous = previous; if (previous) previous->next = this; this->next = next; if (next) next->previous = this; } ~Node() { if (previous) previous->next = next; if (next) next->previous = previous; } private: static unsigned int count; unsigned int id; Node *previous; Node *next; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(id); ar & BOOST_SERIALIZATION_NVP(previous); ar & BOOST_SERIALIZATION_NVP(next); } }; unsigned int Node::count = 0; int _tmain(int argc, _TCHAR* argv[]) { Node *head = new Node(); Node *node = new Node(head); node = new Node(node); node = new Node(node); // serialize { ofstream ofs("cyclic.xml"); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(head); } // deserialize Node *other_node = NULL; { ifstream ifs("cyclic.xml"); boost::archive::xml_iarchive ia(ifs); ia >> BOOST_SERIALIZATION_NVP(other_node); } //quit return 0; }

2 1