- Boost - lists.boost.org

BUG: graphviz_write (boost_1_31_0)
by Mark Purtill 08 May '04

08 May '04

The graphviz_write function is inconsistent in how it writes vertices. When it write the vertex itself, it uses get(vertex_index, ...), but when it writes the edges, it just writes the vertex descriptor. When using adjacency_list< listS, listS, bidirectionalS,... >, this produces bad output (the edges list their endpoints by hexadecimal address values). Here's a patch: *** graphviz.hpp.orig 2004-05-07 12:00:21.000000000 -0700 --- graphviz.hpp 2004-05-07 11:34:11.000000000 -0700 *************** *** 266,272 **** } typename graph_traits<Graph>::edge_iterator ei, edge_end; for(tie(ei, edge_end) = edges(g); ei != edge_end; ++ei) { ! out << source(*ei, g) << Traits::delimiter() << target(*ei, g) << " "; epw(out, *ei); //print edge attributes out << ";" << std::endl; } --- 266,272 ---- } typename graph_traits<Graph>::edge_iterator ei, edge_end; for(tie(ei, edge_end) = edges(g); ei != edge_end; ++ei) { ! out << get(vertex_index, source(*ei, g)) << Traits::delimiter() << get(vertex_index, target(*ei, g)) << " "; epw(out, *ei); //print edge attributes out << ";" << std::endl; } -- ^.-.^ Mark Purtill <mpurtill(a)softwarerevolution.com> (425)284-2770 ((")) Software Revolution 11332 NE 122nd Way Kirkland WA 98034-6931

2 1

RE: [boost] Re: License : Graph library incompatw/Boost (was incompatw/GPL)
by Jon Kalb 08 May '04

08 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > Sent: Friday, May 07, 2004 4:15 AM > To: boost(a)lists.boost.org > Cc: Andrew Lumsdaine; Lie-Quan Lee; Jeremy Siek > Subject: [boost] Re: License Conversion Update: Graph library > incompatw/GPL > Maybe this is all a distraction. I think it may be a much > bigger problem that the graph library's license, IIUC, seems > to be incompatible with the Boost license requirements. > Isn't anyone a little alarmed about that? > > I guess if there's a chance we can relicense it under the > Boost license, that'd solve things, but I'm not sure it's > possible. Can any of the copyright holders comment? Yes I'm alarmed about that. I looked at the graph library docs on the web site and they don't say anything at all about copyright or license (that I could find). I think we are (unintentionally) misleading people. People have a right to assume that any library that we have accepted has met the submission requirements which include the license requirements from http://boost.org/more/lib_guide.htm#License. We simply can't include a library that doesn't meet these requirements. I think we need to pull the graph library from the current release and put a note on the website explaining the situation until we get it resolved. I realize that this is a pretty drastic move, but I feel this situation calls Boost's integrity into question and that calls for swift and decisive action. How was this not caught during the review? -- Jon Kalb

4 3

Lambda Doc Bug
by Stephan T. Lavavej 08 May '04

08 May '04

http://boost.org/libs/lambda/doc/ar01s04.html#sect:storing_bound_arguments > [1] Strictly taken, the C++ standard defines for_each as a > non-modifying sequence operation, and the function object > passed to for_each should not modify its argument. The > requirements for the arguments of for_each are unnecessary > strict, since as long as the iterators are mutable, for_each > accepts a function object that can have side-effects on their > argument. Nevertheless, it is straightforward to provide > another function template with the functionality > of std::for_each but more fine-grained requirements for its > arguments. This is incorrect, as well as having a typo. for_each is described as "non-modifying" in the Standard because it does not inherently modify sequences (contrast copy() and friends). However, the functor it takes can mutate its argument. This footnote must be removed. Stephan T. Lavavej http://nuwen.net

1 0

looping construct - testers wanted ;)
by John Torjo 08 May '04

08 May '04

Dear boosters, In the "looping construct" thread, a while ago David Abrahams said that we should do a test, to compare all looping solutions. I've made such a test. It tests against: - keeping internal functions in crange<> - virtual functions - BOOST_FOREACH comparing to using raw iterators. The tests are pretty heavy. I've tested on a Win2000 box/512 Mb of RAM/1.8Ghz Intel processor (laptop), VC7.1 with all optimizations on. It seems that Dave, you were right about the virtual functions - the vtable can be cached. But it seems to happen only when the loop contents are pretty trivial (if within the loop there are some not-so-simple instructions, the vtable aren't cached - see the 'set_to_az' test). Please if any of you can spare about 15 minutes to run the tests, it would be great! Also, any improvement to the tests is welcome. I've attached my results and the code to test. Conclusions (mine :D): - BOOST_FOREACH rocks big time - vtables can be cached, in case the instructions within the loop are not too compilcated - the overhead is pretty large for both vtables and internal functions (at least for vc7.1) I'm eager to see how the tests run on different platforms. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy! ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** *****************************************************************************

7 15

[serialization] bug in basic_iarchive.cpp
by Fredrik Blomqvist 07 May '04

07 May '04

I noticed a typo in the assignment operator for the cobject_id class in libs/serialization/src/basic_iarchive.cpp class cobject_id { public: cobject_id & operator=(const cobject_id & rhs){ bis_ptr = rhs.bis_ptr; bisp_ptr = rhs.bisp_ptr; file_version = rhs.file_version; tracking_level = rhs.tracking_level; ==> initialized = initialized; // [line 101] return *this; } ......... }; This could perhaps be part of the bug/problems Martin Ecker had(?). // Fredrik Blomqvist

1 0

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