- Boost - lists.boost.org

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

GPL compatibility etc.
by John Maddock 07 May '04

07 May '04

It seems on reading the GPL FAQ and in particular http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs, that: The GPL normally extends itself to all of the program * including all library dependencies *, I'll leave aside the issue of whether this is legal, and instead point out the section which reads: "If you want your program to link against a library not covered by that exception, you need to add your own exception, wholly outside of the GPL. This copyright notice and license notice give permission to link with the program FOO: Copyright (C) yyyy <name of copyright holder> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA In addition, as a special exception, <name of copyright holder> gives permission to link the code of this program with the FOO library (or with modified versions of FOO that use the same license as FOO), and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than FOO. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Only the copyright holders for the program can legally authorize this exception. If you wrote the whole program yourself, then assuming your employer or school does not claim the copyright, you are the copyright holder--so you can authorize the exception. But if you want to use parts of other GPL-covered programs by other authors in your code, you cannot authorize the exception for them. You have to get the approval of the copyright holders of those programs. " The last paragraph is particularly odious it seems to me, especially if you are trying to combine Boost with GPL'ed libraries into one GPL whole. One final point, I note that some libraries under non-GPL licences contain explicit exceptions along the lines of: "4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), or Lesser General Purpose Licence (LGPL), then the terms of that licence shall supersede any condition above with which it is incompatible." But having said that, the new Boost License seems to be most like the licenses that the GPL folks consider to be "compatible", so maybe we just need to hasten the provision of the new License to all of Boost. John.

2 2