- Boost - lists.preview.boost.org

Regression testing -- some new testing options?
by Jeff Garland 09 May '04

09 May '04

Robert Ramey & I have been having a discussion offline about the impact of new boost libraries on the time it takes to run the regression tests. Serialization has a particularly time consuming test -- the so called 'torture test' suite. The problem is, that once serialization is in the tree it will be important to run that full test from time to time (like right before release), but it would probably be overkill to run everyday. And from past dicussion it is clear that running the regression test is already becoming very time consuming. Of course this isn't a serialization specific issue. With more and more libraries added the time to do any sort of regression test is continuing to grow. In addition, there is now the 'dll' versus 'static' library dimension for those of us with compiled libraries. It might be nice to sometimes run one or the other to speed things up. Also, Robert would like to be able to run 'debug' versus 'release' tests from time to time. So here's a suggestion. Perhaps it be possible to create a standard way we could set up the regression test targets so that library authors could: 1) define a couple standard test levels - say 'basic' and 'torture' 2) DLL versus static tests would be an option on the regression suite -- so you could run only one or both. Of course this isn't an issue for header libraries. 3) debug versus release is an option 4) define specific compiler/platform exclusions I believe such a design could increase the regression test effectiveness by allowing some contributors and users to run only one set of options (eg: 'basic-dll-release') tests. This option would be much-much faster than 'torture-all-all' -- which for a compiled library needs to compile and excute 4 versions of the tests (dll-release, dll-debug, static-release, static-debug). The compiler/platform exclusions would save time by just skipping over stuff that is going to fail and will never be fixed. There may be some way of doing this now, but ideally we would have some way of specifying this in the bjam file for the tests. Thoughts? Jeff

1 0

Re: Request for small test in VC7.1
by Arkadiy Vertleyb 09 May '04

09 May '04

Hi Joaquin, Your example compiles with no problem in VC7.1 (.NET 2003) in both debug and release mode. Regards, Arkadiy

1 0

Re: [boost] Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 09 May '04

09 May '04

----- Mensaje original ----- De: brok(a)spamcop.net Fecha: Domingo, Mayo 9, 2004 10:52 pm Asunto: Re: [boost] Request for small test in VC7.1 > Quoting JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es>: > [snippet deleted] > Compiled successfully (tried with and without /Za, ie "disable > languageextensions"). > > > B. > Hi Bronek, thanks for trying the test. Obviously, I failed to capture the problem in the snippet, the actual error that's troubling me can be consulted at: http://tinyurl.com/ysmxq The diagnostic seems to be related with the fact that composite_key_result_less privately inherits from composite_key_compare while allowing public access to the base's operator() with a using declaration. Any idea about this? I'll be more than happy to provide further info to anyone who has a clue about the problem, or whishes to try the test in VC 7.1. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: Re: [boost] Re: [serialization] pointers to built-in types
by Robert Ramey 09 May '04

09 May '04

Dave Harris wrote: > I'd rather tell the library exactly which ints can be serialised via > pointers and which not, and the current solution seems a reasonable way of > doing that. At least, I can't think of a better one. To me the cental issue is one of side-effects. I have a header file which implements serialization for pointers to longs - and it works great. Now I forget about the implementation of that header - after all, it works great - and include it in some other header files for some other project. Now I have a big mess. Whereever it's been included, pointers to ALL longs are tracked. Whereever its non included, pointer to longs are flagged at compiler time. Now the behavior of unrelated code is significantly altered just be the inclusion/exclusion of a seemingly unrelated component. The alteration effects even the compilation as well as the execution. Its worse than a global variable in a global namespace. That's why pointers to primitive types have been made non-serializable by default. And there is a very simple solution - use a wrapper to make the long its own type. Probably the only thing missing is to specify serialization for strong_typedef. Robert Ramey

2 1

Possible bug in mpl::push_front for vectorN
by Hamish Mackenzie 09 May '04

09 May '04

#define BOOST_MPL_LIMIT_VECTOR_SIZE 20 #include "boost/mpl/vector.hpp" #include "boost/mpl/push_front.hpp" class X { }; typedef boost::mpl::vector20< X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X > test; typedef boost::mpl::push_front< test, X >::type test2; int main() { return 0; } GCC Version 3.4.0 gives /usr/include/boost/mpl/push_front.hpp: In instantiation of `boost::mpl::push_front<test, X>': push_front.cpp:10: instantiated from here /usr/include/boost/mpl/push_front.hpp:36: error: invalid use of undefined type `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' /usr/include/boost/mpl/aux_/push_front_impl.hpp:31: error: declaration of `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' push_front.cpp:10: error: expected init-declarator before "test2" push_front.cpp:10: error: expected `,' or `;' before "test2"

2 1

Re: [boost] boost/bind.hpp and boost/mpl/less.hpp conflict
by Aleksey Gurtovoy 09 May '04

09 May '04

Lijun Qin writes: > It seems these two files can not be both included, > > just two line file: > > #include <boost/bind.hpp> > #include <boost/mpl/less.hpp> > > will fail to compile on vc 7.1 > > change value to value_t in bind.hpp can resolve the problem. Lijun, It's a known problem that has been fixed in the CVS. The fix will appear in the next release. Thanks for the report, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] Re: [serialization] pointers to built-in types
by brangdon＠cix.compulink.co.uk 09 May '04

09 May '04

In-Reply-To: <c7etkk$e3d$1(a)sea.gmane.org> lirong(a)hotpop.com (Li Lirong) wrote (abridged): > > This well mean that all serialized longs have to be tracked. > > I think the lib should only track it when it is serialized through > pointer. And most of the time, primitives are not serialized through > pointers. So there should be any overhead. It's easy to construct cases where that goes wrong. Like: struct S { int x; int *px; S() : x(0), px(&x) {} }; And such cases aren't that unlikely in real code, either. For example, x might be a default, with px being settable to some other location. It's true that such cases are rare... however, that just makes it all the more important that when they happen, they either work correctly or are diagnosed as errors, preferably at compile time. Disallowing serialisation of int pointers altogether may be restrictive, but it gives a safe compile-time check. I suppose it might be OK to have an option where ints are tracked only when serialised through pointers, provided there was also an option which detected any mistakes at run-time. In other words, did the tracking for all ints but without outputting it. The two options would let you trade performance for safety, eg switched with #ifdef _NDEBUG. However, this seems like a lot of development work. In practice I expect serialisation of int pointers is pretty rare. If we have them, then sooner or later we may get cases like S, and then we have to move to some other solution anyway. Handling the special case in the middle doesn't seem worth it to me. Especially if error detection only happens at run-time, and perhaps only in debug builds. I'd rather tell the library exactly which ints can be serialised via pointers and which not, and the current solution seems a reasonable way of doing that. At least, I can't think of a better one. -- Dave Harris, Nottingham, UK

1 0

boost/bind.hpp and boost/mpl/less.hpp conflict
by Lijun Qin 09 May '04

09 May '04

Hi, It seems these two files can not be both included, just two line file: #include <boost/bind.hpp> #include <boost/mpl/less.hpp> will fail to compile on vc 7.1 change value to value_t in bind.hpp can resolve the problem. Regards Lijun Qin

1 0

RE: [boost] Writing fully custom containers for the bgl
by Roman Yakovenko 09 May '04

09 May '04

> -----Original Message----- > From: Pierre DOUCY [mailto:pdoucyml@free.fr] > Sent: Friday, May 07, 2004 1:47 AM > To: Boost General General > Subject: [boost] Writing fully custom containers for the bgl > > > I have written a custom container for the bgl's adjacency_list which > was based on a subclass of a stl container (namely, std:list). > Everything seemed to work just fine (if not by itself) as I followed > the bgl book indications. > > Now, I'm working on a non stl-based container (a wrapper > around the bdb > API), and facing a lot of compile-time problems. I know my > bdb wrapper > is not fully stl-compliant. > > So my question is : if I make this wrapper fully standard-compliant > (for instance by using boost::iterator and by implementing everything > the stl tells me to implement in a AssociativeContainer or a > MultipleAssociativeContainer), will the bgl play nicely with > it (i.e. > as if it was a std::map, for instance) ? I think even if you do this you will not get standard-compliant AssociativeContainer The reason is simple: bdb cursor does not have all functionality of std iterator. > > If not, what should I do to be able to use my containers with > the bgl. > I haven't found any examples out there, and wondered if anyone tried > (and succeded) in this task. > > My second question is : how and when does the adjacency_list > instantiates its containers, and is there any way to mess with it, by > passing special arguments to the containers when instatiating > my graph > ? Reading the code and following the process in a debugger doesn't > really make my ideas clearer. > > Thanks in advance for any help and/or ideas > > Pierre > > -- > Written slowly for people who can't read fast. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 08 May '04

08 May '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >> >>>Reece Dunn wrote: >>> >>>>There is currently a static-sized array in the Boost library that allows >>>>you to operate on arrays of fixed size. I was wondering if something >>>>similar exists for strings, in particular, providing buffer-overflow >>>>safe string operations. >>>> >>>>I have an nstring< std::size_t n > string class that provides size-safe >>>>copying and comparison, allowing for you to do things like: > >OK, thanks. First bug reports: > >1. Compile problems under VC++ 6: > No include brings in "std::size_t". Fixed. >2. VC++ 6.x complains about references to a zero-sized array for > [edit]: copy( const char( & s )[ m ] ) I have disabled these for VC6 since they are causing problems with the compiler, even with Thorsten Ottersen's workaround :(. >3. "copy" function does not place a trailing null in the string. >[snip] > Note that "strlen" returns a count that does NOT contain the null. I have added this facility as a template parameter (bool null_terminate). The logic behind this is when you do not specifically need a null-terminated string, e.g.: struct JPEGHeader { // ... boost::string::char_string< 4 > magic; // ... } hdr; if( hdr.magic != "JPEG" ) error( "invalid format" ); but also to allow it if you need that security. > All the operations should guarantee that the string remains null >terminated. A constructor should be provided, but all it has to >do is put a null in the first character position. I have already provided such a constructor :). > As for the naming issue, the important thing for retrofit work >is that it should be possible to write a "using" statement that makes >"strcopy", "sprintf", for char_string etc. valid without prefixes, and >doesn't break anything else. You should be able to include something >("safe_strings.hpp"?) that does as much as possible to fix old code. I have moved the char_string class into char_string.hpp and started work on providing safe versions of ::strXXX. It is not possible to use the same names (strlen, etc.) for the char_string versions :( as can be seen in the example below. #include <iostream> #include <cstring> namespace boost { namespace string { using ::strcpy; inline char * strcpy( char * d, const char * s, size_t n ) { return( ::strncpy( d, s, n )); } }} int main() { char str[ 100 ]; using boost::string::strcpy; ::strcpy( str, "Meine Welt!" ); std::cout << str << '\n'; ::strcpy( str, "1234567890", 5 ); // error std::cout << str << '\n'; return( 0 ); } Because of this, I have decided to use the c prefix (e.g. cstrlen). This seems the best solution, but if the c prefix is problematic, let me know and I'll change it. >This is a good start, and not hard to fix. I look forward to the >next round. I have included this round as attachments, but will place the next version in the boost sandbox. It has the signature: template< size_t n, bool null_terminate = true, typename CharT = char, class StringPolicy = std::char_traits< CharT > > class boost::string::char_string; and is the initial move towards a basic_string-like interface. How about the name fixed_string? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

[Formal review] Collection Traits library
by hartmutkaiser＠t-online.de 08 May '04

08 May '04

Hi all, The review of the Collection Traits library, written by Thorsten Ottosen starts today (April 28th, 2004) and runs for 10 days (until May 7th, 2004). The Latest version of the library is available at (yahoo files sections): http://tinyurl.com/ysbaj (72 kB) or in the Boost sandbox. What is it? The Collection Traits library is mainly a tool for writing generic algorithms that work on External Collections. A Collection is a subset of the container requirements; it is so small and essential that it can be made to work with standard containers, iterator-views, built-in arrays and strings by defining a new requirement, the External Collection Concept, where typedefs and functions have been made free-standing instead of members. The library consists of two components: (1) type generators and (2) free-standing functions. The type-generators provide types such as iterators and size_type of external collections whereas the Free-standing functions are for extracting iterators and size of the external collections. Here is a small example: // Example: extracting bounds in generic algorithms template< typename ExternalCollection, typename T > inline typename boost::iterator_of<ExternalCollection>::type find( ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } template< typename ExternalCollection, typename T > inline typename boost::const_iterator_of<ExternalCollection>::type find( const ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } // replace first value and return its index template< typename EC, typename T > inline typename boost::size_type_of< EC >::type my_generic_replace( EC& c, const T& value, const T& replacement ) { boost::iterator_of<EC>::type found = find( c, v ); *found = replacement; return std::distance( boost::begin( c ), found ); } // usage std::vector<int> my_vector; typedef vector<int>::iterator iterator; std::pair<iterator,iterator> my_view( my_vector.begin(), my_vector.begin() + N ); char str[] = "a string"; // ... std::cout << my_generic_replace( my_vector, 4, 2 ) << my_generic_replace( my_view, 4, 2 ) << my_generic_replace( str, 'a', 'b' ); As the External Concepts idea is a rather new one, I would like to ask you to comment on this. Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

20 102

Re:[boost] [serialization] archive_exception bug
by Robert Ramey 08 May '04

08 May '04

Fredrik Blomqvist wrote: > The switch-case in class archive_exception lacks a 'break' after the > 'stream> error' case which leads to incorrect what() message. OK > I also note that the error code "invalid_class_name" doesn't have a > message > equivalent. OK > Furthermore I'm confused about this (which was the reason I found the > other > bug) : > (VC7.1 + Dinkumware) > > int main() > { > try > { > // save > { > std::ofstream ofs("serializer_test.txt"); > boost::archive::text_oarchive oa(ofs); > > oa << 'x'; > // ofs.close(); // uncommenting this throws "stream_error" > (altough > currently with wrong what() message) > oa << 'y'; > } > > // load > { > std::ifstream ifs("serializer_test.txt", std::ios::binary); > boost::archive::text_iarchive ia(ifs); > > char x, y; > ia >> x; > // ifs.close(); // uncommenting this _doesn't_ throw? > ia >> y; > > assert(x == 'x' && y == 'y'); > } > } > catch(std::exception const& e) > { > std::cout << e.what(); > } > > return 0; > } > > > Shouldn't reading throw also? The archives check is/os.good() to throw. > Or is this a bug in my std.lib (or my understanding of it? ;) > #1 looks correct to me. An attempt to read a closed stream should be an error. #2 looks to me like it should throw as well. One think, I'm checking os.good BEFORE trying to write. I don't check it afterwards. Maybe that's the issue. The reason I did this is that after reading eof - os.good() returns false - not really what we want. But at the point where we can check, we don't know that there isn't anything more to be read. Robert Ramey

1 0

[serialization] archive_exception bug
by Fredrik Blomqvist 08 May '04

08 May '04

Hi, The switch-case in class archive_exception lacks a 'break' after the 'stream error' case which leads to incorrect what() message. I also note that the error code "invalid_class_name" doesn't have a message equivalent. Furthermore I'm confused about this (which was the reason I found the other bug) : (VC7.1 + Dinkumware) int main() { try { // save { std::ofstream ofs("serializer_test.txt"); boost::archive::text_oarchive oa(ofs); oa << 'x'; // ofs.close(); // uncommenting this throws "stream_error" (altough currently with wrong what() message) oa << 'y'; } // load { std::ifstream ifs("serializer_test.txt", std::ios::binary); boost::archive::text_iarchive ia(ifs); char x, y; ia >> x; // ifs.close(); // uncommenting this _doesn't_ throw? ia >> y; assert(x == 'x' && y == 'y'); } } catch(std::exception const& e) { std::cout << e.what(); } return 0; } Shouldn't reading throw also? The archives check is/os.good() to throw. Or is this a bug in my std.lib (or my understanding of it? ;) // Fredrik Blomqvist

1 0

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

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

[Formal Review] Collection Traits ends May 7th
by hartmutkaiser＠t-online.de 07 May '04

07 May '04

Hi all, Just wanted to remind you, that the formal review of the Collection Traits library (do we have agreed on a new name already?) ends today, May 7th, 2004. Regards Hartmut Review Manager

1 0

[serialization] exception during deserialization
by FATH Francois 07 May '04

07 May '04

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 have also noticed that saving a pointer of the object's type pointing to the object solves the problem: // updated code MyClass myObject; // object, not pointer MyClass *myOtherPointer = & myObject MyBaseClass *myPointer = &myObject; // serialization code ar & BOOST_SERIALIZATION_NVP(myObject); ar & BOOST_SERIALIZATION_NVP(myOtherPointer); ar & BOOST_SERIALIZATION_NVP(myPointer); So is it a bug, or have I done something wrong ? The compiler is VC7.1, full example code is in attachement. 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> #include <boost/serialization/export.hpp> using namespace std; /* * Base class */ class Base { public: Base() {} virtual ~Base() {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { } }; /* * Derived class */ class Derived : public Base { public: Derived() {} virtual ~Derived() {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Base); /* uncomment to avoid the exception * ar & BOOST_SERIALIZATION_NVP(this); */ } }; /* * exports */ BOOST_CLASS_EXPORT(Base) BOOST_CLASS_EXPORT(Derived) int _tmain(int argc, _TCHAR* argv[]) { // create Derived derived; Base *base = &derived; // serialize { ofstream ofs("toto.xml"); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(derived); oa << BOOST_SERIALIZATION_NVP(base); } // deserialize { ifstream ifs("toto.xml"); boost::archive::xml_iarchive ia(ifs); ia >> BOOST_SERIALIZATION_NVP(derived); ia >> BOOST_SERIALIZATION_NVP(base); } //quit return 0; }

2 1

Re: [boost] Re: Re: Re: Using Serialization for binary marshalling
by brangdon＠cix.compulink.co.uk 07 May '04

07 May '04

In-Reply-To: <c7bsah$27c$1(a)sea.gmane.org> ianmcc(a)lorentz.leidenuniv.nl (Ian McCulloch) wrote (abridged): > Nice idea. I was thinking along the lines of how to achieve > high-performance, with shared memory & fast network message passing in > mind. I have some experience of that kind of code being quicker than code which naively treats an int as 4 bytes. There was enough compression that the bandwidth saving (eg on disk i/o) compensated for the complexity of the code. That was some years ago, and there may have been ways to optimise the naive code that I didn't try. Still, I wouldn't write this off on speed grounds without measuring it. -- Dave Harris, Nottingham, UK

3 2

Re:[boost] [serialization] pointers to built-in types
by Robert Ramey 07 May '04

07 May '04

Lirong wrote: > I remember that pointers to built-in types can not be serialized > directly in earlier versions of the library. The user would have to > write a wrapper around the built-in type. How is the situation now? The default serialization traits are such that pointers to primitive types are set to not-serializable. Suppose you set the implementation_level<long> to object serializable and serialize a pointer to a long. This well mean that all serialized longs have to be tracked. Do you want something like this to happen? Its possible to serialize a pointer to primitive - I just can't imagine a case where one would want to do because of the side effects it would cause. That's why I recommend wrapping the primitive in its own type so that you don't create a lot of unexpected/undesired side-effects. Look at strong typedef for a simple cheap automatic wrapper. Robert Ramey

2 1

RE: [boost] Re: static sized strings
by Reece Dunn 07 May '04

07 May '04

John Nagle wrote: >Reece Dunn wrote: >>There is currently a static-sized array in the Boost library that allows >>you to operate on arrays of fixed size. I was wondering if something >>similar exists for strings, in particular, providing buffer-overflow safe >>string operations. >> >>I have an nstring< std::size_t n > string class that provides size-safe >>copying and comparison, allowing for you to do things like: > > That's an excellent direction in which to be moving. > > How far can we go in replacing unsafe C strings? With >the endless reports of buffer overflow exploits, anything >that can be done in that direction would help. This was the motivation for designing the class: to allow safe string operations with a clean, easy-to-use interface. I have attached the source below. Note that this is still a work-in-progress and as such is not yet complete. > I'd suggest a class with the following properties: > > Fixed-allocated strings, with length information. > No calls to "new". Typical usage would be something like: boost::char_string< 15 > str; str.copy( "Hello World!" ); NOTE: there is not yet an operator=. The formatterex class is to support sprintf-like operations and can be used like this: error_message( boost::formatterex< 1024 >( "[%s]: %s", severity, msg )); > Supports most of the operations allowed for STL strings. Good idea - this will help shifting between both classes. > Also supports the "classic" C string operations, like > "sprintf", "strlen", etc., using the classic C syntax for them. Also a good idea. But where should these reside? In the global namespace, std namespace or boost namespace? > Implicit conversion to "const char*", but not "char *", for > compatibility with existing library calls. Done. > Fully protected against overflow. I hope that this is the case, although if any bugs are spotted, I'd appreciate feedback so I can fix them. Note that the const char ( & )[ m ] versions are to support string literals. > It might also be worthwhile to provide "sprintf", "strlen", etc. >for STL strings. This is where things get tricky. Where do we place these overloads? Like with the others (char_string) there is the question of how to be compatible with the existing std+global namespace versions. Note that this is complicated by the fact that the functions exist in the global namespace and are using-imported into the std namespace in (all?) existing implementations. I would suggest having something like a boost::string namespace, where these overloads (plus wchar_t overloads) of strlen, etc are placed. It may be that the implementations need to be placed directly in the global namespace, but I don't know what impact that would have. > The basic idea is that this should be retrofittable to old code >without major efforts. Ideally, you go through the code with >a program, replacing "char foo[nnn]" with "char_array<nnn> foo", >and "char *" with "char_array&", and it mostly works. Everything >that doesn't work gets a compile-time error. You fix all the compile >time errors, and your program is overflow-proof, at least in >this area. On my to-do list for this class is to add wchar_t support and support for a traits class (char_traits?) as well as completing the implementation. Let me know what you thing. Regards, Reece ===== // (C) Copyright 2003-2004: Reece H. Dunn #ifndef BOOST_CHAR_STRING_HPP #define BOOST_CHAR_STRING_HPP # include <cstring> namespace boost { template< std::size_t n > class char_string { private: char str[ n ]; public: // access inline operator const char *() const { return( str ); } public: inline const char * c_str() const { return( str ); } inline std::size_t size() const { return( n ); } public: // copy inline void copy( const char * s, std::size_t l ) { ::strncpy( str, s, ( l > n ) ? n : l ); } inline void copy( const char * s ) { copy( s, ::strlen( s )); } inline void copy( const char_string< n > & s ) { ::strncpy( str, s, n ); } template< std::size_t m > inline void copy( const char( & s )[ m ] ) { copy( s, m ); } public: // comparison inline int comp( const char * s, std::size_t l ) const { return( ::strncmp( str, s, ( l > n ) ? n : l )); } inline int comp( const char * s ) const { return( comp( s, ::strlen( s ))); } inline int comp( const char_string< n > & s ) const { return( ::strncmp( str, s, n )); } template< std::size_t m > inline int comp( const char( & s )[ m ] ) const { return( comp( s, m )); } public: inline char_string() { str[ 0 ] = '\0'; } }; template< std::size_t n > bool operator==( const char_string< n > & a, const char_string< n > & b ) { return( a.comp( b ) == 0 ); } template< std::size_t n, std::size_t m > bool operator==( const char_string< n > & a, const char( & b )[ m ] ) { return( a.comp( b ) == 0 ); } template< std::size_t n, std::size_t m > bool operator==( const char( & b )[ m ], const char_string< n > & a ) { return( a.comp( b ) == 0 ); } // formatter -- sprintf-like operations template< std::size_t n > class formatterex: public char_string< n > { public: inline const char * operator()( const char * fs ... ) throw() { va_list args; va_start( args, fs ); _vsnprintf( *this, n, fs, args ); va_end( args ); return( *this ); } public: inline formatterex( const char * fs ... ) throw() { va_list args; va_start( args, fs ); _vsnprintf( *this, n, fs, args ); va_end( args ); } inline formatterex() throw() { } }; typedef formatterex< 512 > formatter; } #endif _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Writing fully custom containers for the bgl
by Pierre DOUCY 07 May '04

07 May '04

I have written a custom container for the bgl's adjacency_list which was based on a subclass of a stl container (namely, std:list). Everything seemed to work just fine (if not by itself) as I followed the bgl book indications. Now, I'm working on a non stl-based container (a wrapper around the bdb API), and facing a lot of compile-time problems. I know my bdb wrapper is not fully stl-compliant. So my question is : if I make this wrapper fully standard-compliant (for instance by using boost::iterator and by implementing everything the stl tells me to implement in a AssociativeContainer or a MultipleAssociativeContainer), will the bgl play nicely with it (i.e. as if it was a std::map, for instance) ? If not, what should I do to be able to use my containers with the bgl. I haven't found any examples out there, and wondered if anyone tried (and succeded) in this task. My second question is : how and when does the adjacency_list instantiates its containers, and is there any way to mess with it, by passing special arguments to the containers when instatiating my graph ? Reading the code and following the process in a debugger doesn't really make my ideas clearer. Thanks in advance for any help and/or ideas Pierre -- Written slowly for people who can't read fast.

3 2

small enable_if documentation or header bug
by Richard Peters 06 May '04

06 May '04

The documentation of enable_if reads: 3 Using enable_if The enable_if templates are defined in boost/utility/enable_if.hpp, which is included by boost/utility.hpp. but the header boost/utility/enable_if.hpp is not included by boost/utility.hpp. best regards, Richard Peters

3 3

Re:[boost] Re: Re: Re: Using Serialization for binary
by brangdon＠cix.compulink.co.uk 06 May '04

06 May '04

In-Reply-To: <20040506033527.A2765313DF(a)acme.west.net> ramey(a)rrsd.com (Robert Ramey) wrote (abridged): > > > Specifically, I'd use a byte oriented scheme where the low 7 bits of > > > each byte contribute to the current number, and the high bit says > > > whether there are more bytes to come. > > That's the way it's done in demo_portable_binary_archive included in the > current serialization package. Yes. Demo_portable_binary_archive stores a length byte followed by the bytes needed. I specifically wanted to suggest an alternative to that. Using a bit from each byte means that small integers take half as much space as with your format. Some numbers of bytes: Integer Length Byte High Bit 0 2 1 10 2 1 100 2 1 1000 3 2 10000 3 2 100000 4 3 In practice most integers are small. Eg most archive version numbers will be below 100. -- Dave Harris, Nottingham, UK

1 0

RE: [boost] pool_alloc with Pair Associative Container?
by SCleary＠jerviswebb.com 06 May '04

06 May '04

Your declaration looks correct to me. hash_map is part of SGI's STL/STLPort. It will support Standard C++ Allocators IF the underlying compiler is capable of it (requires member template support). Otherwise, it has a nice fallback mechanism that uses its own form of STLPort Allocator. pool_alloc provides a Standard C++ Allocator; it does not support the STLPort Allocator interface. So, it sounds like you're using a compiler that is not capable of supporting Standard C++ Allocators properly. -Steve -----Original Message----- From: Thomas [mailto:hazard@imsa.edu] Sent: Wednesday, May 05, 2004 4:45 PM To: boost(a)lists.boost.org Subject: [boost] pool_alloc with Pair Associative Container? Can someone give me an example of how to use the boost pool_alloc allocator interface with a Pair Associative Container, like hash_map? I tried doing something like typedef hash_map<long long,double,longLongHasher,boost::pool_allocator< pair<const long long,double> > > tLongLongToDoubleHashMap; ,,,but I get errors when I try to compile code that actually uses tLongLongToDoubleHashMap. Thanks! Thomas -- Thomas <hazard(a)imsa.edu> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[bind] bug for vc7.1
by John Torjo 06 May '04

06 May '04

#include <boost/bind.hpp> using namespace boost; #include <vector> struct base { int i; }; struct test : public base { // if you uncomment here and comment above, it'll work // int i; }; int main() { typedef std::vector<test> vector; vector v; // generates compile-time error on vc7.1 bind<int&>( mem_fn(&test::i), _1) (v.front()); return 0; } Peter, any workarounds, until its' fixed? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 3

Re: Re: Re:boost::serialization Remarks
by martin.ecker＠tab.at 06 May '04

06 May '04

Jeff, > Although, I am having problems with my > VC71 MFC application reporting memory > leaks of a 24byte block corresponding > to each shared_ptr loaded from an > oarchive. You probably mean "loaded from an iarchive". Anyway, due to the modifications I've made in our local code base of boost::serialization I had a bit of a look through the code. I'm not sure, but the memory leaks you experience could possibly be related to the fact that basic_iarchive::delete_created_pointers is never called. Maybe you can add a call to this function yourself somewhere in your application (delete_created_pointers is a public member function of basic_iarchive) and see if the memory leaks disappear. Note that this is just a guess on my part, as I haven't had time to look at all the code in detail. In reference to the example you posted, you could change it to not use an empty shared_ptr but actually allocate an object for it and then change the deserialization code to: if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); ia.delete_created_pointers(); } Regards, Martin TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

2 1

signal lib broken in current cvs version
by Vasco Lohrenscheit 06 May '04

06 May '04

Hello, I'm not sure where to best report it, but the current cvs version of the signal lib is broken: errors occur in named_slot_map.cpp/named_slot_map.cpp resp. iterator_facade.hpp (using vc7.1). One problem is a syntax error in named_slot_map.cpp line 91 and then methods decrement and advance are missing (resulting in an error in iterator_facade.hpp). best regards, Vasco Lohrenscheit

2 1

Re: Re: Re:boost::serialization Remarks
by Robert Ramey 06 May '04

06 May '04

Martin Ecker wrote: > > Although, I am having problems with my > > VC71 MFC application reporting memory > > leaks of a 24byte block corresponding to each shared_ptr loaded from > > an oarchive. > I'm not sure, but the memory leaks you experience could possibly be > related to the fact that basic_iarchive::delete_created_pointers is never > called. Maybe you can add a call to this function yourself somewhere in > your application (delete_created_pointers is a public member function of > basic_iarchive) and see if the memory leaks disappear. The intended purpose of delete_created_pointers is to delete object created in the course of de-serializing a stream which has thrown an exception. Nothing more. One place you might want to look shared_ptr serialization. Serialization of shared_ptr starts out by initializing the shared pointer to NULL and adds references as things proceed. This might be a problem in the case where the shared_ptr is already pointing to something. Robert Ramey

1 0

Bug in signals library
by Алексей Суббота 06 May '04

06 May '04

There is bug at boost/signals/detail/config.hpp: Before #ifdef BOOST_HAS_DECLSPEC must be #include <boost/config.hpp> Without it line dll's version does't export nothing.

2 1

[Boost-bugs] [ boost-Bugs-949189 ] typos in wrapping_int.hpp
by SourceForge.net 06 May '04

06 May '04

Bugs item #949189, was opened at 2004-05-06 15:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pieter (morban) Assigned to: Jeff Garland (az_sw_dude) Summary: typos in wrapping_int.hpp Initial Comment: In the following code: template<typename int_type_, int_type_ wrap_min, int_type_ wrap_max> class wrapping_int2 { public: typedef int_type_ int_type; static unsigned long wrap_value() {return wrap_max;} static unsigned long min_value() {return wrap_min;} ... the last two lines should probably read (changing return types and the first function's name): static int_type max_value() {return wrap_max;} static int_type min_value() {return wrap_min;} May I suggest renaming this class to "top_wrapping_int" in reaction to the comment above it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Formal review] Collection Traits library review ends tomorrow
by hartmutkaiser＠t-online.de 06 May '04

06 May '04

Hi all, Just wanted to remind you, that the formal review of the Collection Traits library written by Thorsten Ottosen ends tomorrow, May 7th, 2004. Please submit your reviews until then, if you haven't already. Regards Hartmut Review Manager

1 0

Re: [boost] Re: Re: Using Serialization for binary marshalling
by brangdon＠cix.compulink.co.uk 06 May '04

06 May '04

In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > As I see it the current serialization library allows both options, > depending on your preferences. Any archive may choose which types it > view as fundamental, but both have their disadvantages: I would use variable length integers. Use as many bytes as you need for the integer's actual value. That way the archive format is independent of whether short, int, long or some other type was used by the outputting program. It can also give you byte order independence for free. Specifically, I'd use a byte oriented scheme where the low 7 bits of each byte contribute to the current number, and the high bit says whether there are more bytes to come. void load( uintmax_t &result ) { result = 0; while (true) { unsigned char byte; *this >> byte; result = (result << 7) | (byte & 0x7f); if ((byte & 0x80) == 0) return; } } Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes etc. This gives a compact representation while still supporting 64-bit ints and beyond. You can use boost::numeric_cast<> or similar to bring the uintmax_t down to a smaller size. -- Dave Harris, Nottingham, UK

4 4

Re: static sized strings
by John Nagle 06 May '04

06 May '04

Reece Dunn wrote: > There is currently a static-sized array in the Boost library that allows > you to operate on arrays of fixed size. I was wondering if something > similar exists for strings, in particular, providing buffer-overflow > safe string operations. > > I have an nstring< std::size_t n > string class that provides size-safe > copying and comparison, allowing for you to do things like: That's an excellent direction in which to be moving. How far can we go in replacing unsafe C strings? With the endless reports of buffer overflow exploits, anything that can be done in that direction would help. I'd suggest a class with the following properties: Fixed-allocated strings, with length information. No calls to "new". Supports most of the operations allowed for STL strings. Also supports the "classic" C string operations, like "sprintf", "strlen", etc., using the classic C syntax for them. Implicit conversion to "const char*", but not "char *", for compatibility with existing library calls. Fully protected against overflow. It might also be worthwhile to provide "sprintf", "strlen", etc. for STL strings. The basic idea is that this should be retrofittable to old code without major efforts. Ideally, you go through the code with a program, replacing "char foo[nnn]" with "char_array<nnn> foo", and "char *" with "char_array&", and it mostly works. Everything that doesn't work gets a compile-time error. You fix all the compile time errors, and your program is overflow-proof, at least in this area. John Nagle Team Overbot

1 0

Re:[boost] Re: Re: Re: Using Serialization for binary
by Robert Ramey 06 May '04

06 May '04

Ian McCulloch wrote: > > Dave Harris wrote: > > > In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> > > troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > >> As I see it the current serialization library allows both options, > >> depending on your preferences. Any archive may choose which types it > >> view as fundamental, but both have their disadvantages: > > > > I would use variable length integers. Use as many bytes as you need for > > the integer's actual value. That way the archive format is independent > of > > whether short, int, long or some other type was used by the outputting > > program. It can also give you byte order independence for free. > > > > Specifically, I'd use a byte oriented scheme where the low 7 bits of > each > > byte contribute to the current number, and the high bit says whether > there > > are more bytes to come. > [...] > > Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes > > etc. This gives a compact representation while still supporting 64-bit > > ints and beyond. You can use boost::numeric_cast<> or similar to bring > the > > uintmax_t down to a smaller size. > > Nice idea. I was thinking along the lines of how to achieve > high-performance, with shared memory & fast network message passing in > mind. I think now though, this is probably too specialized an application > for boost::serialization. > That's the way it's done in demo_portable_binary_archive included in the current serialization package. Robert Ramey

1 0

signals and threads
by David Abrahams 06 May '04

06 May '04

So, we're thinking of using the signals library in one of our projects, but the lack of thread-safety is a concern for us. What issues are preventing Boost.Signals from being made threadsafe? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

pool_alloc with Pair Associative Container?
by Thomas 05 May '04

05 May '04

Can someone give me an example of how to use the boost pool_alloc allocator interface with a Pair Associative Container, like hash_map? I tried doing something like typedef hash_map<long long,double,longLongHasher,boost::pool_allocator< pair<const long long,double> > > tLongLongToDoubleHashMap; ,,,but I get errors when I try to compile code that actually uses tLongLongToDoubleHashMap. Thanks! Thomas -- Thomas <hazard(a)imsa.edu>

1 0

[Boost-bugs] [ boost-Bugs-948785 ] lambda doesn't overload deref op correctly
by SourceForge.net 05 May '04

05 May '04

Bugs item #948785, was opened at 2004-05-05 13:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948785&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lambda doesn't overload deref op correctly Initial Comment: The dereference operator overload for lambda fn params seems to assume that the argument is an iterator. This precludes easy dereference of UDTs and smart ptrs. Thanks Bill Somerville bill(a)classdesign.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948785&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: Re: Spirit and typeof [was typeof]
by Reece Dunn 05 May '04

05 May '04

Arkadiy Vertleyb wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > > > One question though: I have a parser where I have created several >external > > grammars to help modularize the grammar and employ the trick suggested >in > > the techniques section (c.f. sub-grammar): > > > > [snip] > > Once you have a (sub-)rule like this, you can use it like: > > > > rule_t<ScannerT> tagName = !( identifier >> ':' ) >> identifier; > > > > I was wondering if this would cause any major problems when implemented >with > > the typeof/auto hack (since it could then be implemented as a grammar). > >I think you would just have to register your identifier_parser class. The >typeof system then would treat it as an atom and not care what is behind >it. This was what I was thinking. But is there a way of handling the grammar template as a special case, e.g.: template< typename T > class deduce_type { typedef ... type; }; template< typename DerivedT > class deduce_type< boost::spirit::grammar< DerivedT > > { typedef DerivedT::type type; }; I am not saying that this is what it will look like as I am not up to speed with your typeof mechanism, but if something similar could be implemented, it would make custom grammars more powerful (may even reduce the number of types that need explicit registration). Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

Re: RE: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 05 May '04

05 May '04

Brian Braatz wrote: > Question- I was just looking for clarification. Does the boost > serialization library allow me to have objects on different platforms > stream to each other? Yes. However, the archive must be designed to be platform independent. This is a little bit more subtle than it would first appear. For example, consider the text archive. It stores all numbers as text delimited by spaces. That's portable. But suppose a machine which uses an 80 bit IEEE double stores a high precision value to an archive. Another machine that reads the archive might only have a 64 bit double. So, some of the original precision would be lost. Of course the original value would have been preserved to the extent possible on the new machine. Even here, moving to an ebcdic machine would require a custom codecvt facet which is not in library. Is this "portable"? You be the judge. Within the limitations of the above, text and xml archives can be considered portable. The binary archive is really "native binary" in that it doesn't make conversions for integer size or endianness. (It does check that the endianness and integer size are the same on the saving and loading machines so it might be portable between some pairs of machines). In general the binary archive should be considered non-portable and not suitable for archives meant to be transferred from non identical architectures. There has been lots of interest in making an XDR and CDR archives. I really haven't considered issues in using XDR or CDR. I don't know whether these are just standards for encoding low level types or describe a whole protocol. If it's the former, it would be pretty simple implement. Otherwise, we have the problem of matching the serial representation of some arbitrary C++ structure with some externally defined protocol. Though it might be possible in certain cases, this is not something that the serialization system has been designed to do. http://lists.boost.org/MailArchives/boost/msg63695.php The package includes a "portable" archive as a demo. It doesn't include code for floats and longs. The portable archive includes a lead byte for each integer indicating the number of bytes required to hold the value. If the integer doesn't "fit" in the loaded type, an exception is thrown. The usage of boost::uint_16 etc. doesn't have to be explicitly considered. I didn't have good method for handling floats and doubles across machine architectures. Now that I have suitable code for handling portable floats/doubles, (http://lists.boost.org/MailArchives/boost/msg63672.php) I might think of promoting portable_binary_?archive to a first class supported archive. It would be complete and general, but depend on the serialization library being implemented on the "other" machine. Not an unreasonable restriction in my view. For those who must have CDR/XDR I have no final answer. Robert Ramey

3 4

Passing parameters to container constructor
by pdoucyml＠free.fr 05 May '04

05 May '04

I'm in the process of writing my bdb container, and have used the container_gen template to tell boost which container to use. Now what I would like is to be able to pass some parameters to this container's constructor (e.g., the database's file name). After some time googling and reading the bgl book, I haven't been able to figure out how to achieve this. Any ideas ? Thanks in advance. Pierre.

1 0

[multi_index] ANN: Post-review version available
by Joaquín Mª López Muñoz 05 May '04

05 May '04

I'm glad to announce that the post-review version of The Boost Multi-index Containers Library or Boos.MultiIndex (formerly known as Boost.IndexedSet) is available at: http://groups.yahoo.com/group/boost/files/multi_index.zip The most noticeable change is the new name for the library, which I hope will please most and bug none. Also, a new powerful feature called composite_key has been added. The complete list of changes after requests from the reviewers can be consulted at: http://groups.yahoo.com/group/boost/files/multi_index_postreview_notes.html I'd be grateful if the people interested could do the following: 1. make sure that all requests have been met. Those that haven't are justified at the post-review notes. 2. try to compile the library with different compilers. I don't think I've broken anything, but one never knows. This version has been tested with MSVC 6.5, GCC 3.3.1 and ICC 7.1 for Windows. Of special interest are MSVC 7.1, ICC 8.0, GCC 4.0 and CW 9.2. If no one raises any objection, in a week's time I'll commit the library to the main CVS, hopefully in time for Boost 1.32. Thanks everybody, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

Re:[boost] Re: Re: Using Serialization for binary marshalling
by Robert Ramey 05 May '04

05 May '04

Ian McCulloch wrote: > Does something like this structure make sense for the boost serialization > library? FWIW, my views on this subject are pretty much on display in the demo_portable_binary example shipped with draft #18 of the boost serialization library. If I have time, I may add support for floating point and move some code to templates to speed it up. But basically its very simple and addresses all known portability issues as far as I know. Robert Ramey

1 0

Re: [boost] Re: Spirit and typeof [was typeof]
by Reece Dunn 05 May '04

05 May '04

Joel de Guzman wrote: >Arkadiy Vertleyb wrote: >>"Joel de Guzman" wrote >>>I'd like >>>to start a new CVS branch for typeof/auto experimentations. This would >>>involve not only Spirit but Phoenix as well. I have a feeling that this >>>will take more than a week or two. Yet, I'm sure that the results would >>>be gratifying, at the very least. >> >> >>Actually, I do think that this should be done fast, since it is intended >>to >>close the gap (maybe a year or two) until the real typeof becomes >>available. > >Agreed. Let's do it! I would also like to help, as I think that Spirit is an awesome library/tool and would benefit greatly with auto/typeof support. One question though: I have a parser where I have created several external grammars to help modularize the grammar and employ the trick suggested in the techniques section (c.f. sub-grammar): using namespace boost::spirit; struct identifier_parser: public sub_grammar< identifier_parser > { public: typedef sequence_t < alternative< alpha_parser, chlit<> >, kleene_alternative_t< alnum_parser, chlit<> >::type >::type start_t; public: start_t start; public: inline identifier_parser(): start ( ( alpha_p | '_' ) >> *( alnum_p | '_' ) ) { } } identifier; NOTE: This is using various type construction helpers. Once you have a (sub-)rule like this, you can use it like: rule_t<ScannerT> tagName = !( identifier >> ':' ) >> identifier; I was wondering if this would cause any major problems when implemented with the typeof/auto hack (since it could then be implemented as a grammar). Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

RE: [boost] [Formal review] Collection Traits library
by Randy Bowen 05 May '04

05 May '04

> why would you want to view it in 80 columns? > IMO 80 cols per line is quite a thing of the past. > Nowadays, 100 or even more is more appropriate. On my 21" > monitor :) I have my IDE set to 110 cols/line. > I believe that 80 columns is part of the current Boost requirements/guidelines. (Debating the value of this is obviously another matter.) Randy Bowen Stamps.com

1 0

Re:Re:[boost] boost::serialization Remarks
by Robert Ramey 05 May '04

05 May '04

Martin Ecker wrote: > > > Is there work under way to fix this and have working DLL builds of > > > boost::serialization (just as there are DLL builds for, say, > > > boost::regex)? > > > > I have interest in addressing this. I do believe it is addressable > without > > too much difficulty but will require some extra care. There also might > be > > some restrictions on usage - I don't know yet. > > I looked into this some more and I believe to have found somewhat of > a solution (albeit a "hacky" one) for the template classes derived from > extended_type_info. If you don't mind I will send you my current > boost::serialization code base via private e-mail and you could maybe > have a look at it. As I wrote above, I do not yet know enough about > the internal structure of the library, so I can't say for sure if > my changes broke anything major. In the limited tests I did with the > demo samples that come with the library everything seemed to work fine > though. > OK > One thing that I have not yet addressed though is the need for > extended type info objects to unregister themselves from the > global registry. This is important when DLLs are loaded, unloaded, > and then loaded again. I believe this should be quite easy to > implement. Simply make a call to some unregister function in > the extended_type_info destructor, similar to the self_register > call in the constructor. I have yet to consider the issues related to dynamic loading/unloading of DLLS. The current system registers things at pre-execution time. I'm not sure what that means when the object to be registered via construction of a static object located in a DLL loaded at a subsequent time. > This actually brings me to another > question: Why is the self_register call not directly in the > base class constructor, i.e. in extended_type_info::extended_type_info, > but rather in the deriving classes? No particular reason as far as I can see. > > > My intention was the BOOST_CLASS_EXPORT be included in the header file. > > I don't quite understand how this can work reliably. Say, I have two DLLs. > In one DLL I have class A. A's header file also contains the > BOOST_CLASS_EXPORT(A) macro. Now a second DLL also needs to use this > class. Therefore it will include A's header file. This will result > in a static guid_initializer instance to be created in both DLLs, which > is unnecessary. Note that a new static variable instance should created for each archive included. If no archives are included, then the header with BOOST_CLASS_EXPORT can be included anywhere any number of times. The actual restriction should be that it be included only once for a given archive class. Looking at the code now, I see that its also creating an extended_type_info instance as well and this will lead to problems with multiply defined static instances. I believe this can be enhanced to skip this step of no archives are being included. That doesn't quite do it but it points the way to improving this. > Also with the current code it will cause the class' > extended type info to be registered twice, once in each DLL with a > different extended type info object each time. I believe my code > modifications will remedy this though, so it wouldn't matter if > the registration happened multiple times, but it is still unnecessary. > The only "proper" way I know of to avoid this is to always use the > export macros in .cpp files. I'm coming to this conclusion as well. > > This would mean code modules would be organized > > similar to the demo_pimpl example where the implementation of class > > serialization (invocations of ar << my_class_instance) are in separate > > modules from the headers rather than inline functions. > > I've looked at that sample, but since we are trying to integrate > boost::serialization into an existing project, reorganizing all of > our code is pretty much out of the question. > We tend to have the serialization code inlined in the header files > of the class it belongs to. This has so far proven to be good > for maintenance of the code as well (e.g. when a new member variable > is added to a class it is harder to forget to also change > the serialization code, if necessary). I think it's a mistake to dismiss this idea. I appreciate the ease of maintenance but in the type of project your working with I think it would be best to: a) refrain from defining serialize inline in the header file. b) implement serialize() in the my_class.cpp file for each class. c) include BOOST_CLASS_EXPORT in each my_class.cpp file d) instanciate the templates in the class *.cpp file for archive classes you expect to support. Only the my_class.cpp will included archive class headers. I believe it is common practice is to have an *.hpp file and a *.cpp file for each non-trivial class. So I would be surprised to find that much code reorganization would be required to implement this. I also believe that to reliably support libraries and DLLs of exported classes, such an organization will be required. It will also result in much smaller code with almost no loss of speed. If the code is compiled to a static library, the executable won't contain any "dead" code. If compiled to a DLL, the code won't have to be loaded unless it is actually used. Note that this organization will be required only for those class types which are serialized through pointers to derived classes. So it may not be as much as a burden as it might seem. Robert Ramey

1 0

Re:[boost] boost::serialization Remarks
by Robert Ramey 05 May '04

05 May '04

Martin Ecker wrote: > Is there work under way to improve the serialization of > shared_ptr/weak_ptr? Some kind of generic mechanism to serialize other > smart pointer types, such as boost::shared_array or boost::intrusive_ptr, > would be very nice. Indeed it would. I want to review the implementation of boost::shared_ptr in light of recent observations. The other ones will have to be done by someone else. Since you have a need/interest in this, perhaps you would like to do this and send it too me? > Our system consists of a number of DLLs and we need boost::serialization > to be built as DLL as well. > ... > I might have missed some > others. > Is there work under way to fix this and have working DLL builds of > boost::serialization (just as there are DLL builds for, say, > boost::regex)? I have interest in addressing this. I do believe it is addressable without too much difficulty but will require some extra care. There also might be some restrictions on usage - I don't know yet. > In the documentation I would like to see a remark in the section on Export > Keys, i.e. the BOOST_CLASS_EXPORT macro, that the export macros must not > be used in header files, at least not in header files included by multiple > clients, because they implement global variables that must exist only > once. My intention was the BOOST_CLASS_EXPORT be included in the header file. I believe that new static variables are created only when the header file is used together with an archive header file. So this multiple instances problem would be avoided by organizing modules so that the combination of headers only occurs once. This would mean code modules would be organized similar to the demo_pimpl example where the implementation of class serialization (invocations of ar << my_class_instance) are in separate modules from the headers rather than inline functions. Note that this will result in smaller and easier to maintain code. > One thing I also find unfortunate is that the BOOST_CLASS_EXPORT macro has > to be used at global scope and cannot be used inside namespaces. Is there > a way to fix this? The same goes for BOOST_SERIALIZATION_SPLIT_FREE. A number of people have noted this - I haven't yet found a satisfactory fix for this. > On MSVC 7.1 serialization of a std::vector<bool> doesn't work with the > default implementation of the boost::serialization library. Thanks, I'll look into this. Robert Ramey

3 2

[Boost-bugs] [ boost-Bugs-948514 ] lambda doesn't overload deref op correctly
by SourceForge.net 05 May '04

05 May '04

Bugs item #948514, was opened at 2004-05-05 07:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948514&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lambda doesn't overload deref op correctly Initial Comment: The dereference operator overload for lambda fn params seems to assume that the argument is an iterator. This precludes easy dereference of UDTs and smart ptrs. Thanks Bill Somerville bill(a)classdesign.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948514&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: Re: [Thread] Perennial rw_mutex question
by Hurd, Matthew 05 May '04

05 May '04

> On Behalf Of Michael Glassford > * Rename to improve consistency and eliminate abbreviations: > Use "read" and "write" instead of "shared" and "exclusive". Just a quick note from the bike shop. I've always had an issue with rw/read/write as this is a common use case rather than shared/exclusive which is the real deal. Going along these lines I think rw_mutex is a bad name, though I grant it is commonly understood. The oxymoron shareable_mutex or something other shorter name would make me happier. 0.000000000000002 lira, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Re: [Boost] Big integer library
by Richard Peters 05 May '04

05 May '04

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org... > I have some questions. Will it be possible to say > > 1. typedef boost::rational< big_integer > big_rational. Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used. > 2. Why is faculty() a part of the interface. I have a generic version of > faculty in some prob&stat code I'm doing that I hope would work > with big_integer. Your generic version will most probably work. There is one difference, my version returns an expression instead of a value, which saves the creation of one temporary value. In this case, the gained performance is probably minimal. I'm happy to refactor this function out of the library, throw it away, or come up with a hybrid solution where the expression-returning version is included when both big_integer and your library is included. > 3. Are you planning big_float? I would be happy with focus on interface > specs and then better implementation later. Unfortunately not. I can see that big_float would have its uses, but I rarely even use float. My interests ly in algebraic computations such as cryptology. > The C++ standard could really use a "big" library and it's always nice > with a version in boost first. > > br > > Thorsten Thanks for the response, Richard Peters

10 18

compiler confirmance table
by Max Khesin 05 May '04

05 May '04

Hi, do you know if anyone has a compiler->boost library table of some sort? As I am going through some of the boost libs to get an idea what I can benefit from working in vc6 environment you have to do quite a bit of poking in the docs to figure out if and how much of a given library will compile/work on this platform. It would be nice to have a table like this (just for example) MSVC6 ======= bind - ok function - ok using portable syntax BLL - forget it xyz - runtime problems ... GCC ===== ... of course if there were standardized unit tests for each lib this could be somewhat automated. max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 4

Re: Generative programming support in boost
by Dave Gomboc 05 May '04

05 May '04

> I'm not sure what your question is. Generative programming > itself is a design process/idiom. I can't really imagine how > you'd directly support it with a library, though of course we > have lots of tools in Boost that can be used to practice > generative programming. Indeed, my original message missed the mark -- perhaps I'm not sure what my question is either. :-/ Let me try again. I'm wondering about support for the automatic assembly of components as described in [CE2000], based upon defining mandatory and variable (optional and alternative) features of components, plus the creation of domain-specific languages (a la Spirit), but particularly for component configuration. Of course, boost::mpl aides the specific task of static template metaprogramming. Chapters 13 and 14 of the book contain examples of generative programming applied to bank accounts and to matrix computation. It'd be of value if there was an reimplementation of these that used parts of boost as applicable. I think I've more-more-than-less grokked chapter 12 (the list generator). Dave

1 0

RE: [boost] bdb and mpi selectors for the graph library
by Roman Yakovenko 05 May '04

05 May '04

Pierre wrote: > What I propose, in the case of bdb, is just an edge and a vertex > container, which allows you to do something like : > typedef adjacency_list<bdbS, bdbS, ...> Graph; > and store you whole graph in a berkeley DB database, so that you can > play with fairly big graphs... > > Hope it answers your question... > > > Pierre Definitely. Thanks. Yes, I am interested. I have to deal with DAG, implemented on bdb. I am in design phase of the project. So if you want to share your thought, it will be grate. Roman

1 0

RE: [boost] bdb and mpi selectors for the graph library
by Roman Yakovenko 05 May '04

05 May '04

Hi. I don't understand what do you propose. > The second is aimed at situations when you can't distribute > your graph (e.g. > you're partitionning it before distributing it), or speed > isn't an issue. It > uses a berkeley DB database to store the graph. Do you propose interface that suitable for boost::graph library while implementation of graph is BDB ? If so I'd like to see some code or\and documentation. Roman

3 2

Re: Big integer library
by Richard Peters 05 May '04

05 May '04

I have uploaded a new version of the big_integer library which also compiles with GCC 3.4.0 (cvs version). This version now compiles on compilers which implement two-stage name lookup. The library is available at http://groups.yahoo.com/group/boost/files/big_integer/, the version is 0.1. best regards, Richard Peters "Giovanni Bajo" <giovannibajo(a)libero.it> wrote in message news:c5mf2u$bt0$1@sea.gmane.org... > Richard Peters wrote: > > > A few months ago there was some discussion about an arbitrary > > magnitude integer library. I have now implemented such a library, > > which is located at > > http://groups.yahoo.com/group/boost/files/big_integer/. > > Compiling the code generate hundreds of failures because of two-stage name > lookup. You tested it under MSVC 71 and GCC 3.2 which both fail to implement > lookup rules correctly. I suggest you try again with GCC 3.4.0 (a pre-release > binary package should be available now) or EDG-based compilers. > -- > Giovanni Bajo

11 24

[Thread] Perennial rw_mutex question
by Douglas Paul Gregor 05 May '04

05 May '04

What is the status of rw_mutex and its brethren? It's been languishing on the thread_dev branch for far too long, but lots of people (myself now included) need it. Are there design issues holding it up? Some coding that still needs finishing? Testing? Doug

2 3

[serialization] pointers to built-in types
by Li Lirong 05 May '04

05 May '04

I remember that pointers to built-in types can not be serialized directly in earlier versions of the library. The user would have to write a wrapper around the built-in type. How is the situation now? Best regards, Lirong

1 0

patch: iterator/zip_iterator.hpp
by Antony Searle 05 May '04

05 May '04

While using zip_iterator I encountered some minor bugs. Bugs: The include guard is broken (the #define has been omitted). The function "tuple_equal" causes multiple-definition linker errors. Patch: Added missing #define to header guard. Added missing "inline" keyword to "tuple_equal" definition. Please find attached the patch file. Best, Antony Searle zip_iterator.hpp.patch: *** zip_iterator.hpp.orig 2004-05-05 10:35:41.000000000 +1000 --- zip_iterator.hpp 2004-05-05 11:08:45.000000000 +1000 *************** *** 19,24 **** --- 19,25 ---- // Borland 5.5.1 (broken due to lack of support from Boost.Tuples) #ifndef BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ + #define BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ #include <stddef.h> #include <boost/iterator.hpp> *************** *** 315,321 **** // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2> --- 316,322 ---- // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! inline bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2>

1 0

Request for mpl::empty_sequence
by Alexander Nasonov 05 May '04

05 May '04

For the purpose of forward declaration of class templates this read-only lightweight sequence might be useful. For example, one might declare class template Selector in fwd file: // empty_sequence.hpp is designed for inclusion into fwd files #include <boost/mpl/empty_sequence.hpp> template<class Variants = empty_sequence> class Selector; Another way to archieve this could be inclusion of <boost/mpl/vector_fwd.hpp> (why there is no such file in mpl?) and using mpl::vector<> instead. Although, it could extend a set of class templates with those modifying template parameter but a user would find it strange to include <boost/mpl/vector.hpp> if he only uses Selector<>. The empty_sequence definition is as simple as: namespace boost { namespace mpl { namespace aux { struct empty_sequence_iter { typedef forward_iterator_tag category; }; } struct empty_sequence { typedef aux::empty_sequence_iter begin; typedef aux::empty_sequence_iter end; }; }} This is not yet complete. I hope that support for some transformations will be added later (transformation doesn't change empty_sequence unless the size is changed) -- Alexander Nasonov Independent Developer and Consultant

2 6

[Review] Collection traits library
by Douglas Paul Gregor 04 May '04

04 May '04

We should accept the collection traits library into Boost. Collection traits address an annoying inconsistency in the use of collections. The documentation is sound, I did not find any issues when skimming the source code, and the testing looks adequate. Only two little nitpicks: - A misspelling: "funtions" in ExternalCollectionConcept synopsis. - Need to get copyright/license into files in the "test" subdirectory. Doug

1 0

connected components in adjacency_list graph
by Kommers, Jefferson 04 May '04

04 May '04

I am trying to understand why the order in which I add edges to an adjacency_list graph has some effect on the connected components I get using incremental_components. Using the listing below, with Boost release 1.30.0 (also 1.31.0) with g++ 2.95 (cygwin) I get the following: > g++ -I./boost_1_31_0 -o ok -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./ok rank[0] = 0 rank[1] = 0 rank[2] = 0 rank[3] = 1 rank[4] = 0 parent[0] = 3 parent[1] = 3 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 1 0 This is what I expect. If I change the order in which I add edges to the graph, I get a different answer: > g++ -I./boost_1_31_0 -DSHOWBUG -o bug -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./bug rank[0] = 0 rank[1] = 0 rank[2] = 1 rank[3] = 2 rank[4] = 0 parent[0] = 3 parent[1] = 2 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 0 This is not what I expect. The single connected component has lost a vertex. But it should be the same graph, the only difference being the order in which I called add_edge(). Is this a bug or a misunderstanding on my part? Any advice would be appreciated... Jeff #include <iostream> #include <vector> #include <algorithm> #include <utility> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> int main(int, char *[]) { using namespace boost; // Create a graph typedef adjacency_list < vecS, vecS, undirectedS > Graph; typedef graph_traits < Graph >::vertex_descriptor Vertex; const int N = 5; Graph G(N); add_edge(0, 3, G); add_edge(0, 4, G); #ifndef SHOWBUG add_edge(1, 4, G); add_edge(1, 2, G); #else add_edge(1, 2, G); add_edge(1, 4, G); #endif // create the disjoint-sets object, which requires rank and parent vertex properties std::vector < Vertex > rank(num_vertices(G)); std::vector < Vertex > parent(num_vertices(G)); typedef graph_traits<Graph>::vertices_size_type* Rank; typedef Vertex* Parent; disjoint_sets < Rank, Parent > ds(&rank[0], &parent[0]); // determine the connected components, storing the results in the disjoint-sets object initialize_incremental_components(G, ds); incremental_components(G, ds); for (unsigned int i = 0; i < rank.size(); ++i) { std::cout << "rank[" <Components; Components components(parent.begin(), parent.end()); for (Components::size_type i = 0; i < components.size(); ++i) { std::cout << "component " << i << " contains: "; for (Components::value_type::iterator j = components[i].begin(); j != components[i].end(); ++j) std::cout << *j << " "; std::cout << std::endl; } return EXIT_SUCCESS; }

1 0

[signals] Deterministic slot ordering
by Douglas Paul Gregor 04 May '04

04 May '04

7 or 8 months ago, Edward Diener proposed deterministic slot ordering for Signals, allowing one to better arrange slot call order: http://article.gmane.org/gmane.comp.lib.boost.devel/25152/ I've now, finally, implemented his suggestions. The results are in CVS. The user-visible changes are: - By default, slots are called in the order they are connected. Groups still go in order, with unnamed slots at the end, but now connection order in a group determines invocation order. This probably won't change anything in user code, because multimaps tend to act this way anyway. - The "connect" methods now have an "at" parameter which may be set to "at_front" or "at_back". at_front means to connect the slot at the front of the slot list (before any grouped slots, or before any other slots in that group) whereas at_back means to connect the slot at the back of the slot list (after any grouped slots, or after any other slots in that group). The simple version of user-visible changes: sig.connect(Hello()); sig.connect(World()); sig(); Now this is guaranteed to print "Hello, world!", eliminating a massive source of confusion. With any luck, I haven't introduced too many new bugs. All regression tests pass for me, but of course I'd appreciate feedback. Doug

1 0

[multi_index][repost] ANN: Post-review version available
by Joaquín Mª López Muñoz 04 May '04

04 May '04

Some days ago I posted the following prompting for feedback on the post-review version of Boost.MultiIndex (fka Boost.IndexedSet). Just in case the post did go unnoticed, here it goes again. If nobody says anything this will go to the CVS next Friday, but I'd rather get some opinions first (and please please some tests on different compilers). Thank you! ************************************* I'm glad to announce that the post-review version of The Boost Multi-index Containers Library or Boos.MultiIndex (formerly known as Boost.IndexedSet) is available at: http://groups.yahoo.com/group/boost/files/multi_index.zip The most noticeable change is the new name for the library, which I hope will please most and bug none. Also, a new powerful feature called composite_key has been added. The complete list of changes after requests from the reviewers can be consulted at: http://groups.yahoo.com/group/boost/files/multi_index_postreview_notes.html I'd be grateful if the people interested could do the following: 1. make sure that all requests have been met. Those that haven't are justified at the post-review notes. 2. try to compile the library with different compilers. I don't think I've broken anything, but one never knows. This version has been tested with MSVC 6.5, GCC 3.3.1 and ICC 7.1 for Windows. Of special interest are MSVC 7.1, ICC 8.0, GCC 4.0 and CW 9.2. If no one raises any objection, in a week's time I'll commit the library to the main CVS, hopefully in time for Boost 1.32. Thanks everybody, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost::serialization Remarks
by martin.ecker＠tab.at 04 May '04

04 May '04

Hello, Even though the formal review is already over, I would like to make a couple of remarks regarding boost::serialization. First of all I like the design of the library and I'm glad it got accepted into Boost. We've started using the library about two weeks ago, at first only for serializing simple configuration data. But now we're looking into the possibility of using it fully as our serialization mechanism. Our project is rather large and it uses shared_ptrs extensively. Therefore, proper support for shared_ptr is very important to us. Unfortunately, the way shared_ptr is serialized currently is not really optimal, as has been discussed on this list before. Also weak_ptr is not yet supported, which is also a requirement for us. Apart from that, the fact that the macro BOOST_SHARED_POINTER_EXPORT has to be used to register the boost::detail::sp-counted_base_impl type is not very nice. Is there work under way to improve the serialization of shared_ptr/weak_ptr? Some kind of generic mechanism to serialize other smart pointer types, such as boost::shared_array or boost::intrusive_ptr, would be very nice. Our system consists of a number of DLLs and we need boost::serialization to be built as DLL as well. I quickly hacked a number of __declspec(dllexport) declarations into the source and created a DLL project with MSVC 7.1 and everything seemed to work fine at first. However, there are problems because of the fact that some of the template classes use static variables that are defined in header files. When included from multiple DLLs, this will cause multiple instances of that static variable to exist, one each for each DLL, although there should only be one instance for the entire program. Thus, if an attempt is made to serialize an object that belongs to one DLL from another DLL all sorts of things go wrong. For example, two template classes in boost::serialization that cause these problems are extended_type_info_no_rtti and extended_type_info_rtti, which declare static local variables in a function called get_instance in their respective header files. Also the static_initializer template class in void_cast.hpp defines a static member variable. I might have missed some others. Is there work under way to fix this and have working DLL builds of boost::serialization (just as there are DLL builds for, say, boost::regex)? In the documentation I would like to see a remark in the section on Export Keys, i.e. the BOOST_CLASS_EXPORT macro, that the export macros must not be used in header files, at least not in header files included by multiple clients, because they implement global variables that must exist only once. One thing I also find unfortunate is that the BOOST_CLASS_EXPORT macro has to be used at global scope and cannot be used inside namespaces. Is there a way to fix this? The same goes for BOOST_SERIALIZATION_SPLIT_FREE. On MSVC 7.1 serialization of a std::vector<bool> doesn't work with the default implementation of the boost::serialization library. The compiler complains in save_collection in the line save_construct_data(ar, &(*it), 0U); with the error C2101: '&' requires l-value I presume this is because dereferencing an iterator to a std::vector<bool> returns a proxy object. A simple solution to this is to specialize the serialize free function for std::vector<bool>. Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

1 0

[patch] GCC 3.4 removed __GLIBCPP__ macro
by Jonathan Wakely 04 May '04

04 May '04

Hi, The version of libstdc++ that ships with GCC 3.4 has changed a number of macro names, so the boost/config/stdlib/libstdcpp3.hpp file no longer works. __GLIBCPP__ -> __GLIBCXX__ _GLIBCPP_USE_WCHAR_T -> _GLIBCXX_USE_WCHAR_T _GLIBCPP_USE_LONG_LONG -> _GLIBCXX_USE_LONG_LONG The attached patch adds a check for __GLIBCXX__ to select_stdlib_config.hpp and includes a new libstdcxx3.hpp file if it's defined. That new file is also attached. If noone's already working on this, is my approach the best one? jon -- "Surrealism aims at the total transformation of the mind and all that resembles it" - Breton

2 3

Re: [boost] [ublas] Patch for GCC 3.4
by Giovanni Bajo 04 May '04

04 May '04

[copied to the Boost mailing list] Michael Stevens wrote: > I noticed you posting a month ago and I was hoping Joerg Walter would > answer your query. I have been helping Joerg maintain uBLAS since the > end of last year. Sadly Joerg has been of the ublas-dev list for > quite some time now and I have been unable to contact him. In the > meantime I am keeping up the maintenance of the separate ublas-dev > CVS. > However I do not have Boost CVS commit access so I am unable to > propagate these changes. The ublas-dev CVS has a couple of rather > recent changes which need further testing before reaching Boost. > However the GCC 3.4 problem I think is important enough that it > should be fixed now. > I therefore want to ask you the favour of committing the attached > patch. This fixes all the missing typename's which occur in several > files. It also adds test7 to the regression tests. This shows up a > bug in VC7.1 which I am hoping Microsoft will address. OK, I'm committing this patch to the CVS trunk on your behalf. > If this goes well I would also like to ask you to add a set for > Jamfiles for BBv2 that are now a part of ublas-dev. Would that be OK? I do not have problems in doing this, but if you are maintaining uBLAS, I think it is worth you to do this *officially*, and get CVS write access. Asking on the Boost list would be a way to accomplish this. Giovanni Bajo

1 0

RE: [boost] Re: Using Serialization for binary marshalling
by Brian Braatz 03 May '04

03 May '04

"""""""""" > Now, as you rightly point out, CDR does provide for efficient binary > representation of C++ primitive types. I can see that some people > might prefer to use CDR as an on-wire format for communication between > equivalent systems, so this certainly is a candidate for complete C++ coverage. > > This is complicated, however. If you were to allow full C++ > serialization into a CDR archive, the result would be portable but not > conformant to any standard or protocol, since it relied on the > serialization library's object serialization method. Only another > user of the serialization library could recover the serialized data. Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win. I can write to binary files or across a socket to any platform and as long as I deserialize using the same code it should work. I don't believe the other binary (maybe the text) archives can claim that. I think there is one more restriction on the C++ code, however. Types would have to be coded with 'portable' types (eg: boost::uint_16, boost::uint_32, etc). But anyone doing cross-platform development already does that, right ;-) """"""""""'' Question- I was just looking for clarification. Does the boost serialization library allow me to have objects on different platforms stream to each other? To put it another way is the guess here correct? " Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win." Thanks

1 0

regex patches available
by John Maddock 03 May '04

03 May '04

All users of Boost.Regex-1.31.1 should be aware that there are now a set of patches available for this release - see https://sourceforge.net/project/showfiles.php?group_id=7586 for downloads. Issues fixed include: POSIX style regular expressions not behaving correctly with regex_grep. Non-greedy repeats not backtracking correctly in some cases. Backreferences cause some repeat operators to behave incorrectly. Some wide character expressions weren't getting correctly optimised, leading to thrown exceptions in trivial cases. Misc. compiler compatibility fixes. Regards, John Maddock.

2 1

bdb and mpi selectors for the graph library
by pdoucyml＠free.fr 03 May '04

03 May '04

Hi all, as part of a project dealing with (very) big graphs, I am currently writing two containers. The first one is aimed at situations when you have huge graphs and want to distribute them among different computers. It uses MPI to communicate between computers. The second is aimed at situations when you can't distribute your graph (e.g. you're partitionning it before distributing it), or speed isn't an issue. It uses a berkeley DB database to store the graph. Is this code of interest for boost, would you consider reviewing it once it's tested and stable ? Pierre DOUCY -- Written slowly for people who can't read fast.

2 1

Linux regression tests screwed up?
by Gennaro Prota 03 May '04

03 May '04

Hi, I was looking at the Linux regression logs at http://boost.sourceforge.net/regression-logs/cs-Linux.html and I see that each test file is listed twice, with different results (Warn/Pass, or Warn/Fail etc.). It seems that at least in some cases old files are being picked up from the repository; for instance the tests for "dynamic_bitset - dyn_bitset_unit_tests1 - intel-8.0-linux" give a warning on the return type of const char * const test_file_name() which I have already changed to "const char *" nine days ago. A similar thing can be said for some gcc errors: http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#dynamic_bi… Maybe I got something wrong in the Jamfiles? -- Genny. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

[Boost-bugs] [ boost-Bugs-946917 ] Minor coding issue
by SourceForge.net 03 May '04

03 May '04

Bugs item #946917, was opened at 2004-05-03 14:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=946917&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pieter (morban) Assigned to: Jeff Garland (az_sw_dude) Summary: Minor coding issue Initial Comment: The functions: gregorian_calendar_base<ymd_type_,date_int_type_>::fr om_day_number(date_int_type dayNumber) and: gregorian_calendar_base<ymd_type_,date_int_type_>::fr om_julian_day_number(date_int_type dayNumber) in "gregorian_calander.ipp" share the same code, except for the static_cast to year_type (which is static_cast<unsigned short> in the first and static_cast<year_type> in the second of these functions. It seems that the one of these functions is redundant (and that the first one has a wrong type cast)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=946917&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

ssh and repository
by Victor A. Wagner Jr. 03 May '04

03 May '04

Ok, it's broken yet again <sigh> and as Jonathan Wakely <cow(a)compsoc.man.ac.uk> says (I don't know where he's finding that info, I've been ALL OVER sourceforge.net) the root name is in EVERY directory...it's not a "just change my command line" Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

6 7

Hotfix or full 1.31.1 release? [mainly regex]
by John Maddock 03 May '04

03 May '04

Folks, I'm starting to accumulate a number of regex fixes/patches now, that could usefully be released as either a hotfix for 1.31.0, or combined with other 1.31.0 fixes to make a full 1.31.1 release. So which should it be - this is mainly going to be determined by whether the regression testers are prepared to switch their testing back to the release branch I guess. John.

3 3

Re: Re: [BGL] forced client complexity
by Provisional Dissonance 02 May '04

02 May '04

>Yea, but first the original poster should indicate if this is what he's >looking for -- I never needed this myself. What I was looking for, really, was dialog on existing design strategies. It sounds like your issues with property maps mirror my confusion with the library design, though. While I can fully appreciate the desire to write generic code, it feels like BGL has pushed the complexity of creating and enforcing coupling between the generic graph/node/visitor/algorithm/etc onto the client. At a basic conceptual level, I think of a graph as a data structure composed of nodes and edges. If I'm modeling a family tree, I expect the nodes to be objects of some family-member class. C++ exposes many robust and elegant methods for modeling the family-member - why should I, as a client, have to use property-maps at all? If the node's "index" is related to the object, why would it not be a natural member of the node-type's class? If, instead, it is a synthesized construct for communication between a graph and the algorithm operating over it, why should the client be responsible for its maintenance instead of the framework? What are the advantages of this approach? What are the disadvantages of simplifying things for the client? This is the type of design issue that I intended to question with my initial post. -prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 16

bind question/request
by Max Khesin 02 May '04

02 May '04

I am refactoring code that looks something like this: if (op == LN::FILTER_IN || op == LN::FILTER_NOT_IN) { where += handle_set_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_RANGE) { where += handle_range_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_NULL || op == LN::FILTER_NOT_NULL) { where += handle_null_operation(column, op); } ... This would obviously be handled better with a map of some sort (has to map int to function). The problem here is that some functions have more arguments than others, precluding the possibility of uniform type for the function value of the map. I cannot just go and change the function sig to include dummy values ('cause it's a dumb idea). This situation made me think of boost.function/boost.bind, which allows to effectively shorten the function parameter list by binding some of the args. so given int f(int a, int b) { return a + b; } bind(f, _1, 5)(x); is equivalent to f(x, 5); and by extension bind(f, _1, _2, _0)(x, y, z) would be equivalent to f(x, y) thoughts? thanks. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

5 4

ssh to CVS updates
by Victor A. Wagner Jr. 02 May '04

02 May '04

I finally got the boost stuff updating.... I downloaded UltraEdit to fix all the root files ... it might be worth paying for the program JUST to have that feature.... it did it in one step in about 4 seconds (609 files updated). so now that I've got that working again I get this when attempting to run bjam in the status sub-directory: C:\Projects\boost>cd status C:\Projects\boost\status>bjam -sTOOLS=vc7.1 1>status.log C:\Projects\boost\status>mgrep (('serror's)`('starget)`(skipped's)) status.log Grep - Version 1.11 Copyright (C) 1986-94, Metadigm, Inc. All Rights Reserved Copyright (C) 2000-2; Victor A. Wagner Jr. All Rights Reserved File: status.log ...found 25149 targets... ...updating 101 targets... C:\Projects\boost\boost\graph\graph_test.hpp(375) : error C2065: 'x' : undeclared identifier C:\Projects\boost\boost\graph\graph_test.hpp(380) : error C3861: 'x': identifier not found, even with argument-dependent lookup C:\Projects\boost\boost\graph\graph_test.hpp(384) : error C3861: 'x': identifier not found, even with argument-dependent lookup ...skipped <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.CMD for lack of <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.obj... ...skipped <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.exe for lack of <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.CMD... ...skipped <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.run for lack of <@boost!libs!graph!test\subgraph.test\vc7.1\debug>subgraph.exe... ...failed updating 1 target... ...skipped 4 targets... ...updated 96 targets... =============================================================================================== this is the additional information about the 1st error: ..\libs\graph\test\subgraph.cpp(114) : see reference to function template instantiation 'void boost::graph_test<Graph>::test_vertex_property_graph<int,boost::vertex_color_t>(const std::vector<_Ty> &,PropertyTag,Graph &)' being compiled with [ Graph=subgraph_t, _Ty=int, PropertyTag=boost::vertex_color_t ] ================================================================================================= I'm still unable to access what used to be :ssh:vawjr@cvs.boost-sandbox.sourceforge.net:22:/cvsroot/boost-sandbox here is the relevant info C:\Projects\boost-sandbox>cvs login Logging in to :ssh:vawjr@cvs.sourceforge.net:22:/cvsroot/boost-sandbox CVS password: ******* C:\Projects\boost-sandbox>cvs co -c C:\Projects\boost-sandbox>cvs update -dPA cvs update: Updating . cvs update: failed to create lock directory for `/cvsroot/boost-sandbox/boost-sandbox' (/cvsroot/boost-sandbox/boost-sandbox/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository `/cvsroot/boost-sandbox/boost-sandbox' cvs [update aborted]: read lock failed - giving up ======================================================================================================= that cvs co -c doesn't complain leads me to believe that it's working to SOME extent not sure what the permission problem is. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Generative programming support in boost
by Dave Gomboc 01 May '04

01 May '04

I'm revisiting Czarnecki and Eisenecker's work (Generative Programming: Methods, Tools, and Applications) from 2000. I'm wondering what is available in boost that exploits (or even advances) on the techniques and code examples given there. It occurs to me that both the concept_check and the mpl library have something to offer in this respect. At the very least, there are few obvious things (e.g. if, apply_if, etc. in mpl). Is anyone actively applying boost code in this area? (I did find a series of posts from February 2002 on this topic, but not much since then.) Dave

4 3

Re: [boost] Generative programming support in boost
by JOAQUIN LOPEZ MU?Z 01 May '04

01 May '04

----- Mensaje original ----- De: Dave Gomboc <dave(a)cs.ualberta.ca> Fecha: Sábado, Mayo 1, 2004 4:04 am Asunto: [boost] Generative programming support in boost > I'm revisiting Czarnecki and Eisenecker's work (Generative > Programming:Methods, Tools, and Applications) from 2000. I'm > wondering what is > available in boost that exploits (or even advances) on the techniques > and code examples given there. > > It occurs to me that both the concept_check and the mpl library have > something to offer in this respect. At the very least, there are few > obvious things (e.g. if, apply_if, etc. in mpl). Is anyone actively > applying boost code in this area? > FWIW, multi_index_container crucially depends on MPL to construct the container out of a typelist of index specifiers (mpl::fold stuff). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Generative programming support in boost
by Reece Dunn 01 May '04

01 May '04

Dave Gomboc wrote: >I'm revisiting Czarnecki and Eisenecker's work (Generative Programming: >Methods, Tools, and Applications) from 2000. I'm wondering what is >available in boost that exploits (or even advances) on the techniques >and code examples given there. >It occurs to me that both the concept_check and the mpl library have >something to offer in this respect. At the very least, there are few >obvious things (e.g. if, apply_if, etc. in mpl). Is anyone actively >applying boost code in this area? Have you had a look at Boost.Spirit and the related Phoenix/Fusion libraries? Spirit is a lexer/parser generator that allows you to write BNF grammars in C++ that are close to the actual BNF grammar declerations, as well as providing a set of grammar recognisers like real numbers. See the documentation for more information. Spirit allows you to bind actions to the grammar (e.g. summing the numbers read from a file/user input). There is closure support, alliowing a grammar rule to have data bound to it, and the Phoenix/Fusion library provides a mechanism for writing lazily evaluated C++-like code (e.g. if, while as well as STL actions such as push_back and assign). e.g. std::vector< float > v; ... rule<> = real_p[ push_back_p( v ) ] >> ',' >> real_p[ push_back_p( v ) ] NOTE: The Spirit documentation contains this example with a more detailed explanation. There is also the Lambda library - which is currently being rewritten to sit on top of the Fusion framework - that allows you to use Lambda expressions in C++ code, e.g.: std::for_each( c.begin(), c.end(), n += _1 ); // see Lambda docs for correct usage There has also been a review of the FC++ library (see the mail archives for details) that attempts to provide a functional language framework, and although it has not yet been accepted into Boost, there are some powerful concepts like Lazy Lists. It provides its own Lambda implementation and equivalent of Boost.Function/Boost,Bind. Even though this is functional programming (like Haskell) there is a heavy reliance on template metaprogramming as well as adding to the existing generative framework. If you want to find out how extensively the MPL library is used in Boost, do a search for "mpl::". I know that the Serialisation library is using it. Also, there are several workarounds for the current lack of typeof/auto in various libraries that need it. My I/O formatters library (boost-sandbox/outfmt) uses a technique similar to this to map a type to a classification (e.g. container, array, n-ary) in order to build the appropriate formatter so that it can be correctly written to/read from a C++ stream. The documentation is currently out of synch with the implementation and examples, but I am revising it at the moment. Also, the STL provides generative support with iterators/iterator_traits, algorithms and functors. The Boost library has enhanced these with the Iterator Adaptors library, a better iterator_traits and other stuff. Hope that helped. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

BOOST_TRY, can we make it into CVS?
by Pavel Vozenilek 01 May '04

01 May '04

I would like to ask someone with write access to CVS to create file boost/details/exception_helpers.hpp (or so) with content: #include <boost/config.hpp> #include <boost/detail/workaround.hpp> #if !(defined BOOST_NO_EXCEPTIONS) # define BOOST_TRY { try # define BOOST_CATCH(x) catch(x) # define BOOST_RETHROW throw; # define BOOST_CATCH_END } #else # if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # define BOOST_TRY { if ("") # define BOOST_CATCH(x) else if (!"") # else # define BOOST_TRY { if (true) # define BOOST_CATCH else if (false) # endif # define BOOST_RETHROW # define BOOST_CATCH_END } #endif circular_buffer, serialization and multi_index_container may use this code. It was discussed on the list and reaction was rather positive. TIA /Pavel

2 1

looping construct
by michael toksvig 30 Apr '04

30 Apr '04

A while back, Erik Niebler was testing the waters for inclusion of his very, very clever looping construct into boost, but nothing really came of it. Erik's technique is described here: http://www.nwcpp.org/Meetings/2004/01.html Yup, macros are involved and they are yucky, and yup, there already exists a for_each in the standard that works just fine if you care to move your loop body away into a function, and yup, the name BOOST_FOREACH could use a little love. But there is no denying the notational clarity and succinctness of e.g.: foreach(double &d, container) d += 2; Versus the rather redundant: for (list<double>::iterator i = container.begin(); i !=container.end(); ++i) *i += 2; (Note that the latter stops working if container is represented using a vector or a built-in array instead) /Michael Toksvig

11 52

Can't access repositories using :ssh:
by Victor A. Wagner Jr. 30 Apr '04

30 Apr '04

Starting yesterday (it's still Thursday here) I started getting errors in my update and build scripts. When I chased it down, I was getting: WARNING - POTENTIAL SECURITY BREACH! The server's host key does not match the one PuTTY has cached in the registry. This means that either the server administrator has changed the host key, or you have actually connected to another computer pretending to be the server. The new key fingerprint is: ssh-dss 1024 4c:68:03:d4:5c:58:a6:1d:9d:17:13:24:14:48:ba:99 If you were expecting this change and trust the new key, hit Yes to update PuTTY's cache and continue connecting. If you want to carry on connecting but without updating the cache, hit No. If you want to abandon the connection completely, hit Cancel. Cancel is the ONLY guaranteed safe choice.1¦ I tried it manually a few times, then surrendered and said yes.... that didn't solve the problem now I get: C:\Projects\boost>cvs update -dPA Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Cannot access /cvsroot/boost/CVSROOT No such file or directory I get this behavio(u)r on both boost and boost-sandbox a simpler command yields (logging in just to make sure...): C:\Projects\boost>cvs login Logging in to :ssh:vawjr@cvs.boost.sourceforge.net:22:/cvsroot/boost CVS password: ******* C:\Projects\boost>cvs co -c Cannot access /cvsroot/boost/CVSROOT No such file or directory Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

cycle_iterator update
by Neal D. Becker 30 Apr '04

30 Apr '04

Here is an update to cycle_iterator. This is based on the original design by Gennadiy Rozental. After fairly extensive performance testing I am getting good results (compared to my old implementation which was hand-written, not based on boost iterators), after adding operator[]. There are two versions, both give about the same performance in my tests. One version, which I prefer, modifies the underlying base iterator for operations such as increment. The other implementation never touches the base iterator, but modifies an integral offset value. Also included is a Ring container adaptor class, which adapts a container (e.g., std::vector) to a ring. Basic operations are there, but more can be added. Also a simple test program.

4 9

boost.test XML output error
by Alex Odinaev 30 Apr '04

30 Apr '04

Hi, When I was trying to export test log to XML format I found that unit test framework doesn't convert '&' symbol to appropriate XML sequence. & shows up in log file if you have something like BOOST_CHECK(a&&b). Everything inside () goes to XML directly. Thanks, Alex Odinayev

1 0

bind.hpp needs a cwpro8 workaround
by David Abrahams 30 Apr '04

30 Apr '04

Pro8 is having trouble parsing these templates. Any ideas, Peter? template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); } template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); } --- ### mwcc Compiler: # In: C:\boost\boost\bind.hpp # From: named_params_test.cpp # ------------------------------ # 131: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) # Error: ^ # ')' expected ### mwcc Compiler: # 132: { # Error: ^ # declaration syntax error ### mwcc Compiler: # 133: return _mfi::dm<R, T>(*pm); # Error: ^^^^^^ # declaration syntax error ### mwcc Compiler: # 136: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) # Error: ^^^^^ # ')' expected ### mwcc Compiler: # 137: { # Error: ^ # declaration syntax error # Too many errors printed, aborting program -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 11

[type traits, mpl] small fix for BCB 6.4
by Pavel Vozenilek 30 Apr '04

30 Apr '04

BCB 6.4 doesnt't like when top level namespace is prefixed with :: type_traits/is_const.cpp contains line BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,::boost::detail::cv_traits_imp<T*>:: is_const) If the leading :: is removed to BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,boost::detail::cv_traits_imp<T*>::is _const) BCB stops complaining. There are few other places there which may be changed similarly. ---------------- The same problem appears in MPL's value_wknd.hpp: # if !defined(BOOST_MPL_MSVC_60_ETI_BUG) # define BOOST_MPL_AUX_VALUE_WKND(C) ::boost::mpl::aux::value_wknd< C > needs to be changed to # define BOOST_MPL_AUX_VALUE_WKND(C) boost::mpl::aux::value_wknd< C > These problems appeared when trying to compile Collection Traits library. /Pavel

2 2

Can libs/regex/build/gcc.mk use $(AR) instead of just "ar"
by Brad Spencer 30 Apr '04

30 Apr '04

When cross compiling, I need to use an "ar" with the correct target and not just "ar". I've patched boost/libs/regex/build/gcc.mk locally as shown in my attachment, but all I really did was replace use of "ar" with $(AR), which I can then override when invoking make. Perhaps this is reasonable to apply to the mainline copy? [BTW, I'm still locally patching iterator/iterator_facade.hpp because of conflicts with system header macros on i386-pc-solaris2.8. That thread seemed to die.] Thanks! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 1

[Boost-bugs] [ boost-Bugs-945000 ] Dereferencing invalid iterator
by SourceForge.net 30 Apr '04

30 Apr '04

Bugs item #945000, was opened at 2004-04-29 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=945000&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Dereferencing invalid iterator Initial Comment: boost 1.31.0, subgraph.hpp, line 179, function find_vertex(vertex_descriptor u_global) const; return std::make_pair((*i).second, i != m_local_vertex.end()); //if i == m_local_vertex.end() - iterator should not be dereferenced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=945000&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

serialization doc buglet?
by Neal D. Becker 29 Apr '04

29 Apr '04

Serialization18 reference suggests this should work (this is almost verbatim from the section on seperate load/store free function): #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/vector.hpp> template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } namespace boost { namespace serialization { template<class Archive> inline void serialize(Archive & ar, std::complex<double>& z, const unsigned int file_version) { split_free(ar, z, file_version); } }} Claims "load" is not declared. But adding boost::serialization namespace will fix it: namespace boost { namespace serialization { template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } }} This was tested with gcc-3.3.2. Is this a doc bug?

1 0

Re:[boost] Re: Re:RE: shared pointer serialization
by Robert Ramey 29 Apr '04

29 Apr '04

Fredrik Blomqvist wrote > Thinking about smart pointer serialization and how to generalize it, ie. > to allow serialization of any "my_ref_count_ptr", I got this idea. > > -How about extending the tracking system with a case something like: > serialization::track_ref_count? (perhaps using a is_smart_ptr<> traits > function). > Based on this tag the serializer would at load time maintain a > map<pointer_value, my_ref_count_ptr<T> > to enable the ref-copy "bumping" > of all the subsequent my_ref_count_ptrs. > Where pointer_value is used as key and obtained by boost::get_pointer > (assumed to be specialized for my_ref_ptr). > This is essentially the same approach I outlined earlier in my reviews and > seems similar to both what Peter Dimov uses and Gennadiy mentions above. > It would of course require extensions to the code but I think it would > possible to use/adapt the existing pointer code-path to some degree. As far as I can tell, this is exactly equivalent to what the shared_ptr case study in the documentation/code currently do. No special modification to the library was necessary to accomplish this. Indeed, that was the point of the demo and documentation. The question that has been raised is whether even this is more than is necessary. I have yet to address this in detail. In my opinion, any situation which required special support to be added to the library would reveal a flaw in the library design or implementation. In the future - the library will be smaller - not larger. Robert Ramey

1 0

serialization - howto build w/ boost_1_31_0?
by Neal D. Becker 29 Apr '04

29 Apr '04

What is a simple way to build serialization given a boost_1_31_0 tree? This is on Linux/gcc.

1 0

boost::test - example error
by Roman Yakovenko 29 Apr '04

29 Apr '04

Hi. I think I found error within example "The class member function based test cases". The error is in the first example: ts->add( BOOST_CLASS_TEST_CASE( &my_complex_test::test_feature1 ) ); BOOST_CLASS_TEST_CASE macro expects 2 parameters, instance parameter is missing. Roman

1 0

[patch] Iterator library docs
by Jonathan Wakely 29 Apr '04

29 Apr '04

The attached patch should be applied to the docs for the iterator library to correct a typo jon -- "Some people have a way with words. Others...not have way." - Steve Martin

2 1

Re:RE: [boost] shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Gennadiy Rozental wrote: > This is about how I expect it to work. But from this description it's > unclear: > 1. Why would you need to save counter into archive? After all value 10 > has nothing to do with resulting 5. > 2. Why would you need direct access to shared_ptr counter? After all > using regular shared_ptr copy would automatically bump it to proper value. I remember my initial implementation just restored the original state. Thinking better of it I made a change to the current system. Now that you mention it, it wouldn't seem to need the counter anymore. Just for laughs I commented out the serialization of the counter and if failed to build the test. I'll have to look into it. Robert Ramey

2 1

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 28 Apr '04

28 Apr '04

Message: 13 Fredrik Blomqvist > * What is your evaluation of the implementation? > As I mentioned in my previous review I would like to see it handle most of > the STL and core boost components "out of the box". I believe all STL is handled. Serialization of other boost components will have to be the responsibility of their authors or others. > In particular I think the smart_ptrs (including auto_ptr) should have > core-support from the serializer, even special cased if necessary (similar > to boost::bind etc). I believe the current library is capable of implementing serialization for all boost components. Much effort was expended to that the library would not have to have special code for any serialization or archive type. In fact, my interest is just the opposite. I would like to see a significant part of the library moved outside. Anyone who wants to volunteer to take responsibility for any of the component please let us know. The library would be improved by making it smaller. > The code to serialize std::auto_ptr could easily be copied to the official > directory for example. There has been some discussion of where the serialization code for other boost libraries should reside. I don't have strong feelings about this other than I would prefer that it reside outside the serialization library itself. The only exception I would make is for the STL serialization which has no where else in boost to reside and it has a "special" status as and official C++ library. > Regarding shared_ & weak_ptr. If the implementation path Robert outlines > in the documentation is to be used I guess an official patch to > shared_count is necessary. Would be interesting to hear what the smart > pointer experts think. I agree - the silence is deafining. I know there are applications that use my smart pointer serialization code right now. I implemented and tested it but I don't really know for a fact that it addresses all aspects that need to be addressed such as exception safety, threading, and who knows what else. > Otherwise, I still think the solution I outlined in my previous review > that doesn't require modifying shared_ptr could be considered. Downside > being that it most likely adds a special-cased codepath to the serializer, > but as I said I think it would be worth it. I would hope that the developer's maintaining shared pointer will address this. putting special case code inside the serialization library would be a serious mistake. Between code, tests, and documentation, its approaching 30,000 lines. > The code is nicely written altough complex. Highly nested template code > and lots of mpl. All compile-time checks and further factorizations are > valuable. > Nitpick: serialization/scoped_ptr.hpp seems to have a typo. An extra > #pragma once is present outside the #ifdef (_MSC..) block. It also > includes serialization/pfto.hpp but doesn't seem to use it. Thanks - I love picking these nits. Its easy and satisfying - really. > * Parts of the library that might become standalone boost libraries > The library already provides good separation of components. tatic_warning, > strong typedef, pfto, stack_allocate etc are all given candidates that > would just need better documentation and (fast-track?) reviews. A little bit more is going to be required. They've been tested in the context of serialization and that's OK. I think they need to be more polished and that's a little more work than it first appears. Also a separate review would probably fine tune their interface, implementation and capability. * What is your evaluation of the documentation? > I would also like to see an improved reference documentation that clearly > states the requirements on the types/concepts involved. Hmmm - that seems pretty unanimous - pretty much a first for boost as far as I know. > I support the separation of documentation (and implementation) of other > boost components that like to support serialization. A simple index with > links would suffice I think but most importantly a _consistent_ structure > should be agreed upon which new components can follow. I followed the boost document on how to write documentation. The only wrinkle I added was the right hand index/contents window. I'm pretty pleased with this. I would appreciate VC7.1 project files for the examples and tests though. > One of my tests added support for the STL container adaptors std::stack, > queue and priority_queue. I think direct support for them could be > convinient since they hide the native containers. I attach my > implementation. Feel free to comment I took a short look. The name stack_hack sort of begs some sort of comment. The main thing is that any component of this type has got to be submitted with a test. Thanks for taking the time to study the library and submit a review. Robert Ramey

3 5

Appology
by Mohammed Iqbal 28 Apr '04

28 Apr '04

Hi.. Sorry because I didn't reply to you about my library. I felt down after three da days from my last message. My head hit the wall. I suffered very much from a headache, pain in my stomach ( ifelt that I need to vomit but I couldn't), and something wrng with my eyes. Till now I still suffer from these things but not very much. I can't tell you about my library now because of many reasons: 1. It is not a library meant for distribution at least for now. Instead, it is a pert of a large project that I am working alone on. 2. It is not complete now because it is going through changing everyday. 3. It is not totally tested. When I told you about context-oriented programming, I didn't mean what Gassassnenko wrote because a context in my technology differs completely from context in his paper. My technology is for video game creation. It consists of many components: 1. A process model for analysis, design, development, and testing. It is very powerfull because it is designed in the first place for this purpose. It is based on experiences of many researches, studies, surveys, etc. But it is not applied for real video game development. 2. A software tool for game creation that let's you develop a complete game without using any external library or software. You can do your animation, develop your code using the integrated language which is based on C++ as the main root but it is not C++ and many changes have been applied to get rid of many features we don't want, etc. The software also uses the above process for game creation. 3. Many other components. My technology is using something that you don't imagine at all. I will not give any information untill I finish eveything. I used Cubism of Picasso. Strange?? The development is done in the Medium ( a 3D space) that contains many contexts. Each context can be anything like, a function, a class, a template, a set of functions, etc. The contexts deals with each other and with the Medium through slots. Slots can accept anything like a function, a type, a class, etc. That's all for now. Mohammed

1 0

[ann] log viewer
by John Torjo 28 Apr '04

28 Apr '04

Dear boosters, Since most of us use some sort of logging, I've developed a free program that allows simple viewing/filtering of log files (for Windows). The really cool thing is that you can monitor files (you can have multiple filters for the same file) while your application is writing to it. I think it's quite simple to use and very useful. Anyway, to make a long story short, if you're interested: http://www.torjo.com/logview/EasyLogView.exe (download) http://www.torjo.com/logview/screenshot1.jpg http://www.torjo.com/logview/screenshot2.jpg It's at a very early stage, so I look forward to your feedback (menu: Help/Send Feedback ;)) Best, John

2 4

RE: [boost] shared pointer serialization
by Rozental, Gennadiy 28 Apr '04

28 Apr '04

> > what if I do not save all of the shared_ptr to the same object? > > Here is a scenario: > > a) a shared_ptr exists and it points to and object which is > pointed by 9 other shared_ptrs. > > b) we create and archive and save some objects. The set > objects saved only includes 5 of the shared_ptrs out of the > possible 10. > > c) later when we load, we create 5 new shared_ptr and one new > object. Object tracking guarantees that only one shared > object is created. As each new shared pointer is loaded, the > shared count is incremented. So the new shared pointer is > not identical to the original - its equal to 5. > > d) the process (almost?) guarantees that all the shared_ptr > are valid in that they all point to shared object and the > shared_count is maintained to be the correct number. The > intention is that this process be exception safe > - I'm not sure that this intention has been realized. This is about how I expect it to work. But from this description it's unclear: 1. Why would you need to save counter into archive? After all value 10 has nothing to do with resulting 5. 2. Why would you need direct access to shared_ptr counter? After all using regular shared_ptr copy would automatically bump it to proper value. Gennadiy.

1 0

A nice library
by Mohammed Iqbal 28 Apr '04

28 Apr '04

This seems like an interesting library: http://www.southern-storm.com.au/libjit.html It isn't even at beta yet, but it is probably something to watch. Mohammed

1 0

shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Rozental, Gennadiy wrote: > There is another counter to direct counter using (I just think out loud - > it may be that you ok): what if I do not save all of the shared_ptr to the > same object? What will happened once they will get restored? Wouldn't it > cause memory leak? > I do realize that any other solution would be more complicated, but I > think we should go for it. I don't really understand what's being said here but I can shed a little more light on the way serialization is implemented right now. It's also used as a case study in the documentation and described in detail. > what if I do not save all of the shared_ptr to the same object? Here is a scenario: a) a shared_ptr exists and it points to and object which is pointed by 9 other shared_ptrs. b) we create and archive and save some objects. The set objects saved only includes 5 of the shared_ptrs out of the possible 10. c) later when we load, we create 5 new shared_ptr and one new object. Object tracking guarantees that only one shared object is created. As each new shared pointer is loaded, the shared count is incremented. So the new shared pointer is not identical to the original - its equal to 5. d) the process (almost?) guarantees that all the shared_ptr are valid in that they all point to shared object and the shared_count is maintained to be the correct number. The intention is that this process be exception safe - I'm not sure that this intention has been realized. A fuller explanation can be found at: http://www.rrsd.com/boost/libs/serialization/doc/shared_ptr.html Robert Ramey.

1 0

Re:[boost] Re: serialization and MFC
by Robert Ramey 28 Apr '04

28 Apr '04

Eric Niebler wrote: > Forgive the possibly naive question -- I have never used the > serialization library, but I have used MFC serialization. I am curious > if the boost serialization library can be made backwards-compatible > with MFC serialization; that is, if I have an old application that > uses MFC serialization, would it be possible to switch to the boost > serialization library and still have the ability to read old (MFC) > archives? > > I'd like to know: > - if it's possible > - how hard it would be (would it require reverse-engineering the > MFC archive format? is that format stable? documented?) > - what the advantages of switching are The easiest way to switch from MFC (or any other systems is to do the following): a) add boost serialization to your code. b) when you open an archive - currently MFC, use code like the following: open stream read the first part of the stream if doesn't contain a boost serialization signature invoke MFC de-serialization else invoke boost de-serialization. c) when you save an archive - just invoke boost serialization. In this way, all your old files will be compatible and will gradually be converted to the new system. The new archives can use all the new facilities without compromise. This is much easier, and forward looking than trying to adapt to an old format wich likely isn't rich enough to support the new facilities. Robert Ramey

1 0

[Boost-bugs] [ boost-Support Requests-943555 ] Path.cpp:85: error: `portable_posix_name' undeclared in name
by SourceForge.net 28 Apr '04

28 Apr '04

Support Requests item #943555, was opened at 2004-04-28 01:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=943555&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Path.cpp:85: error: `portable_posix_name' undeclared in name Initial Comment: i am compiling a game and i get thru ./configure but when i goto make i get this error Path.cpp:85: error: `portable_posix_name' undeclared in namespace `boost::filesystem' i get simmilair errors on 85, 99 and 113 saying portable_posix_name is undeclared ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=943555&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

problems with boost::thread
by "Magomed Abdurakhmanov 28 Apr '04

28 Apr '04

Hello. I have some troubles with boost::thread, and think they are important: 1. condition::timed_wait dangerous to use, because waiting delay specified as time when we are will stop waiting. So this is very surprising when system time is changed! I guess that waiting for specified delay is much more safe than waiting until some time arrive. For example try launch the program bellow and change system time backward (to past) when it's working. I have tested this under win32 + msvc7 // ------------------------------- boost::condition cvar; boost::mutex monitor; void thread1() { for(;;) { boost::mutex::scoped_lock lock(monitor); boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); std::cout << "now: " << xt.sec << std::endl; xt.sec += 5; std::cout << "will wait until: " << xt.sec << std::endl; if (!cvar.timed_wait(lock, xt)) std::cout << "timed out!" << std::endl; std::cout << "next step" << std::endl; } } int main(int argc, char* argv[]) { boost::thread thrd1(&thread1); thrd1.join(); return 0; } // ------------------------------- 2. The secound trouble is that the thread function has catch(...) at the root and when unhandled exception in thread thrown, it's just silently eated and thread stopped. But the process stay alive, and now nothing about it. And ever wrong that catch(...) under VC6 will catch OS exceptions. p.s. sorry for so bad english

8 14

serialization and MFC
by Eric Niebler 28 Apr '04

28 Apr '04

Forgive the possibly naive question -- I have never used the serialization library, but I have used MFC serialization. I am curious if the boost serialization library can be made backwards-compatible with MFC serialization; that is, if I have an old application that uses MFC serialization, would it be possible to switch to the boost serialization library and still have the ability to read old (MFC) archives? I'd like to know: - if it's possible - how hard it would be (would it require reverse-engineering the MFC archive format? is that format stable? documented?) - what the advantages of switching are Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 1

intel-linux toolset doc error
by Richard Hadsell 27 Apr '04

27 Apr '04

I am upgrading from Boost 1.30.0 to 1.31.0, trying to use bjam for the first time to build the libraries (including Regex). When building for intel-linux, I read (tools/build/v1/intel-linux-tools.html) that bjam would be able to find the compiler from the location of the iccvars.sh script. This did not work. Evidence: 162% which iccvars.sh /usr/local/intel/compiler80/ia32/bin/iccvars.sh 163% which icc /usr/local/intel/compiler80/ia32/bin/icc Despite both of these being in my PATH, bjam tried to look elsewhere: 168% bjam "-sTOOLS=intel-linux" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] intel-linux-C++-action bin/boost/libs/date_time/build/libboost_date_time.so/intel-linux/debug/shared-linkable-true/greg_month.o /bin/sh: /opt/intel/compiler70/ia32/bin/iccvars.sh: No such file or directory Specifying the version number did not help: 169% bjam "-sTOOLS=intel-linux" "-sINTEL_VERSION=80" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] intel-linux-C++-action bin/boost/libs/date_time/build/libboost_date_time.so/intel-linux/debug/shared-linkable-true/greg_month.o /bin/sh: /opt/intel_cc_80/bin/iccvars.sh: No such file or directory -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 2

Problems using Boost, Pls Advise
by Steve Bobrowski 27 Apr '04

27 Apr '04

Hi, I'm a C++ newbie trying to use the Boost regex libraries. Here's my situation. My system is Red Hat Linux 9, using the Borland C++BuilderX Personal IDE (which uses the g++ compiler). I downloaded and installed Boost from boost.org using the command: bjam -sTOOLS=gcc install The install seemed to complete fine, with 2900+ targets updated. The libraries install in /usr/local/include/boost-1_31/boost. I created the following link: ln -s /usr/local/include/boost-1_31/boost /usr/include/boost I then use C++BuilderX to try and compile one of the example programs for the regex libaries that I found in the documentation. The source code is: /////////////////////// #include <list> #include <boost/regex.hpp> unsigned tokenise(std::list<std::string>& l, std::string& s) { return boost::regex_split(std::back_inserter(l), s); } #include <iostream> using namespace std; #if defined(BOOST_MSVC) || (defined(__BORLANDC__) && (__BORLANDC__ == 0x550)) // // problem with std::getline under MSVC6sp3 istream& getline(istream& is, std::string& s) { s.erase(); char c = is.get(); while(c != '\n') { s.append(1, c); c = is.get(); } return is; } #endif int main(int argc) { string s; list<string> l; do{ if(argc == 1) { cout << "Enter text to split (or \"quit\" to exit): "; getline(cin, s); if(s == "quit") break; } else s = "This is a string of tokens"; unsigned result = tokenise(l, s); cout << result << " tokens found" << endl; cout << "The remaining text is: \"" << s << "\"" << endl; while(l.size()) { s = *(l.begin()); l.pop_front(); cout << s << endl; } }while(argc == 1); return 0; } /////////////////////// The compiler returns the following errors: /////////////////////// g++ -c -o /home/sbobrows/cbproject/pmetest/linux/Debug_Build/splittest.o -g2 -O0 -MD -I/usr/include -I/usr/include/g++-3 splittest.cpp g++ -o /home/sbobrows/cbproject/pmetest/linux/Debug_Build/pmetest linux/Debug_Build/splittest.o linux/Debug_Build/splittest.o(.text+0x2c9): In function `__tcf_0': "stl_vector.h": /usr/include/c++/3.2.2/bits/stl_vector.h undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::~reg_expression [in-charge]()' at line 998 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail22get_defau lt_expressionIcEERKNS_14reg_expressionIT_NS_12regex_traitsIS3_EESaIS 3_EEES3_+0x39): In function `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const& boost::re_detail::get_default_expression<char>(char)': "perl_matcher_common.hpp": /usr/include/boost/regex/v4/perl_matcher_common.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::reg_expression[in-charge](char const*, unsigned, std::allocator<char> const&)' at line 734 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost11regex_splitISt20bac k_insert_iteratorISt4listISsSaISsEEEcSt11char_traitsIcESaIcENS_12reg ex_traitsIcEES8_EEjT_RSbIT0_T1_T2_ERKNS_14reg_expressionISC_T3_T4_EENS_15reg ex_constants12_match_flagsEj+0x12e): In function `unsigned boost::regex_split<std::back_insert_iterator<std::list<std::basic_string<cha r, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, char, std::char_traits<char>, std::allocator<char>, boost::regex_traits<char>, std::allocator<char> >(std::back_insert_iterator<std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&, boost::regex_constants::_match_flags, unsigned)': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 1059 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEEC1ES6_S6_RNS_13match_resultsIS6_S9_EERKNS_14reg_expr essionIcSB_SC_EENS_15regex_constants12_match_flagsE+0x78): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::perl_matcher[in-charge](__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >&, boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&, boost::regex_constants::_match_flags)': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::get_traits() const' at line 869 ': "basic_string.tcc": /usr/include/c++/3.2.2/bits/basic_string.tcc undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::empty() const' at line 146 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE24estimate_max_state_countEPSt26random_access_iterat or_tag+0x30): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::estimate_max_state_count(std::random_access_iterator_tag*)': "regex_grep.hpp": /usr/include/boost/regex/v4/regex_grep.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::size() const' at line 46 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0xc0): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "regex_grep.hpp": /usr/include/boost/regex/v4/regex_grep.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 49 Build cancelled due to errors linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x202): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 767 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x290): In function `__static_initialization_and_destruction_0': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 1254 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x2d7): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "perl_matcher_common.hpp": /usr/include/boost/regex/v4/perl_matcher_common.hpp undefined reference to `boost::re_detail::verify_options(unsigned, boost::regex_constants::_match_flags)' at line 821 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail8access_tIc NS_12regex_traitsIcEESaIcEE5firstERKNS_14reg_expressionIcS3_S4_EE+0x d): In function `boost::re_detail::access_t<char, boost::regex_traits<char>, std::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&)': "regex_split.hpp": /usr/include/boost/regex/v4/regex_split.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&) at line 36 /////////////////////// After searching around extensively, I've not come up with any solution to my problem. Can someone please point me in the right direction? It seems like I'm just missing some configuration step along the way. Thanks in advance, Steve!

3 3

RE: RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 27 Apr '04

27 Apr '04

> > > The main problem I had was that certain member variable weren't > > > accessible. The STL collections don't have that issue so > there was no > > > problem. > > > Sorry if this is silly question, but why would you need an > access to > > the counter? IMO we should be able to save/load shared_ptr without > > need to save it. > > I checked the code (which was written some time ago) and the > answer to that question isn't obvious to me. I do remember > starting with the idea that it wouldn't be necessary to look > beyond shared_ptr but I had to just keep adding on to make > things work. The implementation of shared_ptr is A LOT more > involved that one would guess. > > My implementation of shared_ptr implementation may not be the > only or best one. It is pretty straight forward however in > that it follows the chain of composition - which includes > shared_count. > > Sorry I can't give a better answer. > > Robert Ramey There is another counter to direct counter using (I just think out loud - it may be that you ok): what if I do not save all of the shared_ptr to the same object? What will happened once they will get restored? Wouldn't it cause memory leak? I do realize that any other solution would be more complicated, but I think we should go for it. Gennadiy.

1 0

Re:RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 27 Apr '04

27 Apr '04

> > The main problem I had was that certain member variable weren't > > accessible. The STL collections don't have that issue so there was no > > problem. > Sorry if this is silly question, but why would you need an access to the > counter? IMO we should be able to save/load shared_ptr without need to > save it. I checked the code (which was written some time ago) and the answer to that question isn't obvious to me. I do remember starting with the idea that it wouldn't be necessary to look beyond shared_ptr but I had to just keep adding on to make things work. The implementation of shared_ptr is A LOT more involved that one would guess. My implementation of shared_ptr implementation may not be the only or best one. It is pretty straight forward however in that it follows the chain of composition - which includes shared_count. Sorry I can't give a better answer. Robert Ramey

1 0

shared_ptr and BOOST_DISABLE_THREADS
by Carl Daniel 27 Apr '04

27 Apr '04

Playing with a Spirit-based parser for a simple scripting language I noticed that #defining BOOST_DISABLE_THREADS resulted in a parser that was nearly 3 times faster. For reasons that aren't relevant to the discussion, this had to be an MT build, but the parser didn't need thread safety. That made me wonder though: If I #define BOOST_DISABLE_THREADS in some translation units but not in others, what's going to happen? I suppose one way of summarizing it is this: does BOOST_DISABLE_THREADS change the type of shared_ptr that's made? If not, that seems like a rather serious problem to me - especially given the enormous difference in performance that I measured (optimized build with VC8 alpha). What obvious thing am I overlooking? -cd

10 23

dynamic_bitset: work in progress...
by Gennaro Prota 27 Apr '04

27 Apr '04

Hi, for those interested in dynamic_bitset I wanted to reassure them that it will be stabilized soon. It's just, as I said, that I can work on it only for a couple of days per week, and for a couple of hours. This week, for instance, it happened that I saw the Borland regressions *after* my time expired (my timezone is in the way, too). I've integrated the new dyn_bitset_unit_test4 file in the Jamfile and fixed some errors of VACPP and gcc 3.4. Please, expect a correction time-frame of about 1/2 weeks. In the meantime, I hope to work on the documentation, which I can do from the office, during the launch break. I also wait for comments/suggestions, especially about the issues raised in http://lists.boost.org/MailArchives/boost/msg63220.php. Cheers, Genny. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

Serialization Formal Review #2 -- Review Period Closed
by Jeff Garland 27 Apr '04

27 Apr '04

The review period for the Serialization library is now over. Thanks to all the reviewers for their time in reviewing the library. Reviewers were unanimous in voting to accept the library. As a result, Serialization will be accepted into Boost. It will take me about a week to post a summary of the review comments and requested changes. And finally, thanks again to Robert for his unyielding effort to bring this library to Boost! Jeff

1 0

[iterator + named params] includes #error
by Vladimir Prus 27 Apr '04

27 Apr '04

When I try to compile the following code: #include <boost/named_params.hpp> #include <boost/iterator/transform_iterator.hpp> I get: ghost@zigzag:/tmp$ g++ -I ~/Work/boost -I ~/Work/boost-sandbox np.cpp In file included from /home/ghost/Work/boost/boost/iterator/detail/enable_if.hpp:15, from /home/ghost/Work/boost/boost/iterator/transform_iterator.hpp:14, from np.cpp:3: /home/ghost/Work/boost/boost/iterator/detail/config_def.hpp:22:3: #error you have nested config_def #inclusion. I suspect that the attached patch might need to be applied, but since I don't understand 'config_def.hpp' I though I'd ask first. - Volodya

1 0

[serialization, bind, vc7.1]
by Alexey Nikitin 27 Apr '04

27 Apr '04

Next example (only 2 lines) not compiled: ---- t120.cpp ----- #include <boost/bind.hpp> #include <boost/archive/text_iarchive.hpp> -------------------- D:\Alnik\cpp>cl /c /GX t120.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. t120.cpp C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(51) : see reference to class template instantiation 'boost::mpl::less<T1,T2>' being compiled C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2144: syntax error : 'const bool' should be preceded by '}' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2062: type 'const bool' unexpected C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2238: unexpected token(s) preceding ';' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(42) : error C2065: 'value' : undeclared identifier But if to rearrange lines then compiled. Is this the bug of compiler? Regards, Alexey.

2 1

logging library?
by John Torjo 27 Apr '04

27 Apr '04

Dear boosters, I know a while ago there was some interest in a logging library. And of course, there are so many ways you can do logging, that it was somehow agreed that a unique logging library can't address them. However ;), recently I discovered a very easy way to do logging. Gradually, I've come to this class (shown at the end). Using it is extremely easy, and it totally decouples what you write from where it's written. The idea is to have a function that takes a const std::string& parameter, and it will be called whenever a new message is logged. If you want thread-safety, it's just too simple... Just implement it within your function. Example: // log.h logstream errors_log(); logstream activity_log(); // log.cpp void do_log( const std::string & msg) { // ... thread-safe writing to cout scoped_lock lock(some_static_mutex); std::cout << msg; std::cout.flush(); } logstream errors_log() { return logstream(&do_log) << "[ERROR] "; } logstream activity_log() { return logstream(&do_log) << "[activity] "; } // in code #include "log.h" activity_log() << "application started (" << ver.major_ver << "." << ver.minor_ver << ")" << std::endl; errors_log() << "too many users" << users << std::endl; // etc. Also, I have an idea of how to enable/disable (parts of) logging at runtime. Same for very easily enabling/disabling logging of different modules. Any interest in such a library? Best, John #ifndef LOG_LOGSTREAM_HPP #define LOG_LOGSTREAM_HPP #pragma once // Copyright (c) John Torjo - 2004 #include <iosfwd> #include <sstream> namespace log { // allow finding the prototype for a log function template<class char_type, class traits = ::std::char_traits<char_type>, class aloc = ::std::allocator<char_type> > struct log_func { typedef void (*type)(const std::basic_string<char_type,traits,aloc> &); }; // allow writing to a log template<class char_type, class traits = ::std::char_traits<char_type>, class aloc = ::std::allocator<char_type> > struct basic_logstream { typedef typename log_func<char_type,traits,aloc>::type log_func_type; typedef ::std::basic_ostringstream<char_type,traits,aloc> ostring_stream_type; explicit basic_logstream( log_func_type func) : m_func(func) {} basic_logstream( basic_logstream & other) : m_func(other.m_func) { m_buffer << other.m_buffer.str(); other.m_func = 0; } ~basic_logstream() { if ( m_func) m_func( m_buffer.str() ); } template< class T> basic_logstream & operator<<( const T & val) { m_buffer << val; return *this; } typedef std::ostream & (*ostream_func)(std::ostream & ); basic_logstream & operator<<( ostream_func f) { f( m_buffer); return *this; } private: ostring_stream_type m_buffer; log_func_type m_func; }; typedef basic_logstream<char> logstream; typedef basic_logstream<wchar_t> wlogstream; } #endif

7 19

[iterator] concept checking for transform_iterator
by Vladimir Prus 27 Apr '04

27 Apr '04

I've just passed argument to make_transform_iterator in the wrong order, and could not understand the problem for quite some time. Maybe, it's possible to add some concept checking to catch such errors earlier. For example, the attached patch? Thoughs? - Volodya

1 0

program-options thread problem
by Neal D. Becker 27 Apr '04

27 Apr '04

I have both added current program-options to my boost build tree, and all the usual variants of libboost_program_options-gcc.a, also libboost_python-gcc-mt.a. Linking against libboost_program_options-gcc.a I get errors about pthread symbols. Adding -pthread fixes it. It looks to me that libboost_program_options-gcc.a is referencing pthread symbols. nm /usr/local/src/boost_1_31_0.gcc34/stage/lib/libboost_program_options-gcc.a | grep thread U pthread_mutex_destroy U pthread_mutex_init w pthread_mutex_lock w pthread_mutex_unlock w pthread_mutex_lock w pthread_mutex_unlock Yup,sure is.

3 7

Re:Re: [boost] Serialization Formal Review #2
by Robert Ramey 27 Apr '04

27 Apr '04

Matthias Troyer wrote: > I have tried extending the library since I want to swap our old > serialization library used at http://alps.comp-phys.org with a Boost > serialization library as soon as possible. It was important to keep the > same archive format, since we have gigabytes of data collected over ten > years in millions of CPU-hours and need to be able to read those with > both new and old codes. With the help of Robert I managed to convince > myself that this is indeed possible Perhaps it might be possible, but I'm doubtful that it's the best way to address the problem. If the legacy format is a meta-data format it can be possible in a way similar to the way the XML was handled. But in general it will not be desirable nor necessary. To see this take an extreme example. Suppose over the last 10 years we had 10 different programmers working on a the project. Each one had to save and reload data for his classes. Now we want to convert to the new system. We would need a new archive class that tracked all the idiosyncracies in the current code. A huge job. And there exists a much simpler approach. Loading legacy data(legacy_data & ld) ==================== Ifstream is("old_data"); // read first line of old_data file // if it doesn't have the serialization signature // load the data using the legacy system. else{ Boost::binary_iarchive ia(is); ia >> ld } Save data // save in using serialization. As file are processed they are automatically converted to the new system. No special programming is required as the code to load the class instances from the legacy data format already exists - it's the legacy code ! its free at this point. > 4. Documentation of archive formats, especially what class and object > information is stored. I want to be able to predict, from reading the > documentation, what exactly will be written to the archive and in which > order. This would entail a detail paraphrasing of the operation of the code. In the case where there is no versioning, no tracking and no pointer serialization its fairly simple. When any of the others are present, its starts to get pretty complex. There is a comment in basic_archive.cpp which in fact summarizes the format - but I'm not convinced it something that belongs in user documentation. ////////////////////////////////////////////////////////////////////// // // class_information is stored as // // class_id* // -1 for a null pointer // if a new class id // [ // exported key - class name* // tracking level - always/never // file version // ] // // if tracking // [ // object_id // ] // // [ // if a new object id // data... // ] // // * required only for pointers - optional for objects This recursively defines the file format for any serialized data structure. > This is essential when exchanging data with an application that > does not use this library. I'm skeptical that this is going to be fruitful. The "other" application is going to have to effectively re-implement this whole library. Why bother, just use this one. To send data to "other" applications, there is always the XML archive. I don't think that a general purpose tool such as serialization is going to be very helpful in trying to implement some externally defined data format. Some meta-data formats (e.g. XML and windows ini files) are doable but in general it's not going to be productive. Robert Ramey

2 1

Type traits question
by Robert Ramey 26 Apr '04

26 Apr '04

Is there a type traits guru that can explain to me why the following doesn't work as I expect. It's got to be something very, very obvious but I can't see it. Thank you Robert Ramey #include <boost/static_assert.hpp> #include <boost/type_traits/is_base_and_derived.hpp> #include <boost/type_traits/remove_pointer.hpp> class Base1 { char a; }; class Base2 { int b; }; class Derived : public Base1, public Base2 { long c; }; void main(){ // this passes BOOST_STATIC_ASSERT((boost::is_base_and_derived< Base1, Derived >::value)); // this fails !? BOOST_STATIC_ASSERT((boost::is_base_and_derived< boost::remove_pointer<Base1 *>, boost::remove_pointer<Derived *> >::value)); }

3 2

RE: Type traits question
by Robert Ramey 26 Apr '04

26 Apr '04

Never mind, I see it now. Sorry I was desperate. Robert Ramey Robert Ramey wrote: > > #include <boost/static_assert.hpp> > #include <boost/type_traits/is_base_and_derived.hpp> > #include <boost/type_traits/remove_pointer.hpp> > > class Base1 > { > char a; > }; > > class Base2 > { > int b; > }; > > class Derived : public Base1, public Base2 > { > long c; > }; > > void main(){ > // this passes > BOOST_STATIC_ASSERT((boost::is_base_and_derived< > Base1, > Derived > >::value)); > > // this fails !? > BOOST_STATIC_ASSERT((boost::is_base_and_derived< > boost::remove_pointer<Base1 *>, > boost::remove_pointer<Derived *> > >::value)); > }

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 26 Apr '04

26 Apr '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 26, 2004 10:16 pm Asunto: Re: [boost] [multi_index] composite keys: request for advice > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > > struct record > > { > > int first; > > int second > > int third; > > }; > > > > multi_index_container< > > record, > > indexed_by< > > composite_key< > > record, //base value > > member<record,int,&record::first>, // first key > > Would that you could make this work to avoid the duplication and > chance for errors: > > member< &record::first > > > I know a function template can deduce the other types, but I > can't think of how to make it work here. > I'd be the happiest man on the block if I could have that, but AFAIK it is not possible. The fact that member<> is here specified in the context of composite_key does not help, either. This has been previously brought into discussion several times. If you have a typeof() utility and don't object to some macro hackery, this is an approximation: template<typename Class,typename Member> Class base_from_ptr_to_member(Member Class::*); template<typename Class,typename Member> Member member_from_ptr_to_member(Member Class::*); #define BOOST_MULTI_INDEX_SMART_MEMBER(PtrToMember) \ member< \ typeof(base_from_ptr_to_member(PtrToMember)),\ typeof(member_from_ptr_to_member(PtrToMember)),\ PtrToMember\ > ... multi_index_container< record, indexed_by< ordered_unique< BOOST_MULTI_INDEX_SMART_MEMBER(&record::x) > > > Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] composite keys: request for advice
by Joaquin M Lopez Munoz 26 Apr '04

26 Apr '04

> I'm working through the post review changes of multi_index and hope to have something released in one or two weeks. One of the issues raised in the review was the possibility to promote what was an example of composition of keys to be part of the library. I've come up with something more ambitious, but there's a design decision of which I'm not quite certain wich way to go, and I'd like to ask you for advice. Composite keys can be specified by a new construct called composite_key in the following manner: struct record { int first; int second int third; }; multi_index_container< record, indexed_by< composite_key< record, //base value member<record,int,&record::first>, // first key member<record,int,&record::second>, // 2nd member<record,int,&record::third> // 3rd > > > mc; In the example the composite key is composed of three key extractors, and the sorting is made in lexicographical order, for instance: 0,0,1 0,0,2 0,1,0 0,5,4 1,0,0 1,0,2 1,2,3 ... Given the lexicographical order, it is possible to efficiently search for incomplete keys where only the first values are given: mc.equal_range(make_tuple(1,0)) yields 1,0,0 1,0,2 mc.equal_range(make_tuple(0)) yields 0,0,1 0,0,2 0,1,0 0,5,4 and so on. Accordingly, comparison operators between composite_key results and tuples are overloaded so that the following holds: composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); // yields true make_tuple(1,2)<=ck(record(1,2,3)); // yields true So far, this is all IMHO perfectly consistent, but the following design decision is not obvious to me: given the previous, what should be the result of ck(record(1,2,3))==make_tuple(1,2); // true or false? As these two objects are neither greater than the other, at least they are *equivalent*, but maybe allowing operator== to return true is too much. An argument against making them equal is that, with future hashed indices in mind, hashing has to be done on the whole tuple of values returned by the composite key so that: multi_index_container< record unordered_unique< //hashed composite_key< /* as before */ > > > mc; mc.find(make_tuple(1,2,3)); //OK mc.find(make_tuple(1,2)); //KO, we need the whole tuple If we make ck(record(1,2,3))==make_tuple(1,2) return true, the impossibility of having the last line to work is puzzling. If we make it return false, it is also puzling that neverthelss operator<= is true in both senses. What do I do? a. require operator== between composite_key results and tuples to work only on full tuples. b. define operator== in the same line operator<, <= etc. are defined. Thanks for your comments. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 26 Apr '04

26 Apr '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey > Sent: Monday, April 26, 2004 2:02 PM > To: boost(a)lists.boost.org > Subject: Re:Re: Re:[boost] Re: Serialization Formal Review #2 > > > Peter Dimov wrote: > > > FWIW, in my own library I do, indeed, have a special case code for > > serializing an unmodified shared_ptr, for two reasons. First, this > > shows that the library is flexible enough. Second, even if > we modify > > boost::shared_ptr to be boost::serialization-friendly, we won't be > > able to patch std::tr1::shared_ptr. > > The main problem I had was that certain member variable > weren't accessible. The STL collections don't have that issue > so there was no problem. Sorry if this is silly question, but why would you need an access to the counter? IMO we should be able to save/load shared_ptr without need to save it. Gennadiy.

1 0

RE: [boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 26 Apr '04

26 Apr '04

> > Your library cannot be used to save/load anything before main() is > > entered nor can it be used to save/load anything after > main() has been > > left. > > Correct. It never occurred to me to mention this. > > Robert Ramey It probably could be addressed by some kind of lifetime management scheme. Essentially you need to make sure that before any serialization code is invoked all static initializes gets instantiated. I am not sure it doable since you actually within the library code may not know what should be instantiated. On the other hand I an not sure that any move in this direction even worth the trouble. I guess it may be convenient in some cases. Gennadiy.

1 0

Re:Re: Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Peter Dimov wrote: > FWIW, in my own library I do, indeed, have a special case code for > serializing an unmodified shared_ptr, for two reasons. First, this shows > that the library is flexible enough. Second, even if we modify > boost::shared_ptr to be boost::serialization-friendly, we won't be able to > patch std::tr1::shared_ptr. The main problem I had was that certain member variable weren't accessible. The STL collections don't have that issue so there was no problem. > However, should you decide to use your current scheme, I'll happily insert > whatever friend declarations are necessary in shared_count. > I'm away from my computer right now, so I can't paste my read/write > functions for shared_ptr, but the general idea is that they keep a > map< shared_ptr<void>, int > on writing, mapping every shared_ptr > ownership group to a pointer id, and a corresponding map< int, > shared_ptr<void> > on reading, for the reverse transformation. > The main problem for implementing a non-intrusive serialize() for > shared_ptr is that these pointer maps need to be held in the archive, > which requires either archive modification, or a general "extra state" > support in all archives. That's pretty much the same as what the serialization system does - albeit in perhaps in a more generic way. Its not clear to me how enhanced library code could be made to work work without granting access to shared_count. Of course, if access is granted to shared_count, then everything works already. Robert Ramey

1 0

ReL[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

David Abrahams wrote: >"Peter Dimov" <pdimov(a)mmltd.net> writes: >>> http://www.boost.org/libs/smart_ptr/intrusive_ptr.html#Introduction >>> >>> However, the situation is different there as the called function >>> only accepts exactly one parameter. >> >> It doesn't matter. ADL should find the overload, provided that >> 'serialize' >> is not qualified at the point of the call. > >> In my own library I use very similar read/write overloads that are, >> indeed, placed in the namespace of the corresponding class and found by >> ADL. Yes, it works with VC 7.1. >The recommended "overload in the library namespace" procedure was a >big concern for me, but I didn't post anything because I couldn't >remember why it's an issue. I have in my mind, left over from my work >with Peter on this problem, a rule that in the current language you >shouldn't do that, and should rely instead on ADL. I don't know why >I think that anymore, but I *can* say that Peter should be listened >to in this area; he's more aware of the issues than almost anyone. OK, I've looked at code and found that found that my calls to "serialize" are qualified by boost::serialization. So this can be fixed. It seems that users of older compilers will have to overload in the library namespace but that it will not be necessary for users that are only concerned with newer compilers. So its not a problem for the library. Except... What about when I've overloaded from with in the library - such as when default serialization traits are overloaded. Should this namespace specification be #ifdef/#endif depending on the compiler config? Should this be dependent on BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP? Robert Ramey

1 0

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Andreas Huber wrote: > Ok, but IIUC this undermines the original promise that a class > implementing serialize or safe/load can be serialized to *any* archive, > even future ones without changing its implementation. I see that I > wouldn't need to change the serialization *code* but I'd need to add > an include to the .cpp file, right? Correct. But I don't see that as undermining the original promise. You will have to re-compile for future archives, but code will not have to be changed. The polymorphic archive (in progress) will lift even that restriction. > > >> 9. The library registers all kinds of stuff with static instances. > >> This precludes its use outside main(). > > > Hmmm - that would be news to me. > Your library cannot be used to save/load anything before main() is entered > nor can it be used to save/load anything after main() has been left. Correct. It never occurred to me to mention this. Robert Ramey

1 0

Re:[boost] Re: Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Jeff F wrote: > template<class Archive> > inline void serialize( > Archive& ar > , boost::filesystem::path& t > , unsigned int version ) > { > std::string lPathString; > > if( is_saving(ar) ) > lPathString = t.native_file_string(); > > ar & make_nvp( "PathString", lPathString ); > > if( is_loading(ar) ) > t = boost::filesystem::path( lPathString, > boost::filesystem::native ); > } The "real" solution here is to implement serialization for "native_file_string() So that things look like template<class Archive> void serialize( Archive &ar, boost::filesystem::native_files_sting_type & t, unsigned int version ){ ... ?; } template<class Archive> void serialize( Archive &ar, boost::filesystem::path & t, unsigned int version ){ ar & make_nvp("PathString", t); } Robert Ramey

1 0

Re:[boost] Re:Re:Re:Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Vladimir Prus wrote: >Hmm... gotta look into this. What about my second question: >>> 2. For random access I need to make sure that all saved objects have >>> export key. How do I do that? Not necessary out-of-the box but where >>> I can plug the check? Actually, its not necessary that ALL saved objects have export keys. Only those objects that are serialized through polymorphic pointers need to be exported or registered. An attempt to serialize a polymorphic pointer that has neither been exported nor explicitly registered will trigger a run-time exception "unregistered_class". If you wanted to enforce the idea that all types should be exported I believe it would be possible to something like the following in your archive class: a) override implementation of save(class_id_type & t) and save(class_id_optional_type) so that they set a flag. b) override implementation of save(class_name & t) it sets a flag c) override end_preamble so that it checks for an undesired set of flags. I never considered this before so you'll have to check the above yourself. >>> one for dynamic arrays with element-wise save >> >> I would envision one using >> >> ar << element_count >> For(i = 0; I < element_count; i++) >> ar << element[i] >> >> I'm not sure that its worth adding and documenting such an obvious and >> trivial thing as a separate wrapper. >But on loading you need to add 'new[]' call. So load and save become >non-symmetric, and you need to split serialize, which is rather >inconvenient. Actually, I forget the original question. But in any case, I'm wondering about trying to anticipate every application. OTOH, having considered again dynamic_array I'm now more inclined to include it. I'll take a look a the other ones. These would be described in the document under "serialization wrappers". > > There are cases when an object id is > > assigned but not written to the archive I don't see these as having much > > utility outside of serialization. > So, it's not easily possible to plug a different algorithm? In a general sense - NO. Any of the "bookkeeping" types in common_?archive can be overloaded to taste. Overloading these in a special way was how XML was implemented. I'm sure that these could be used for creating other special purpose archives but I really can't know for any particular case until one tries to implement them. >>> Ah, I've missed that. Do I need to provide both 'type' and 'value'? >>> Can't serialization library work with just one? > >> Could be. I just provided both so that I could interoperate with mpl >> without having to think about each specific case. > But for user this can be inconvenient. Actually I was thinking most users would use the macros. If one fails to include one that's used it should fail compilation so I don't see it's a show stopper. Actually I think it's easier just to always include both rather than trying to document/remember which ones use which. > It it possible that you make BOOST_EXPORT always > register classes with the polymoprhic archive. > and use polymoprhic archive as fallback for serializing classes? I'm still fine tuning this (smart_cast anyone?). But basically things work like this. a) Just as now, one could pre-compile a serialization instantiating code for particular archives. In this case one of the archives would be the "polymorphic_?archive" class which is nothing but a bunch of virtual function declarations. b) when the application is built, a specific archive implemenatation is selected. E.G polymorphic_text_?archive. The is archive inherits the implementation from text_?archive and the interface from polymorphic_?archive. c) the application will link with the pre-compiled classes. I'm not sure this answers your question - but there it is. Thank god no ones asked about DLL implementations yet. Robert Ramey

1 0

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Message: 11 Andreas Huber wrote: > 1. On compilers supporting ADL, it seems the user-supplied serialization > function for non-intrusive serialization > template<class Archive> > void serialize(Archive & ar, gps_position & g, const unsigned int > version); > could also be put into the namespace of the type that it serializes. If > this is correct it should be mentioned in the tutorial & reference. If > not, there should be a rationale why not. I did try this in my environment VC 7.1 and it failed to work. Does anyone want to assert that it should or shouldn't work? > 2. save/load naming: All functions that have to do with reading from an archive are named load*, > all functions that have to do with writing to an archive are named save*. > To me (non-native speaker) these names are generally associated with > persistence only. Since the library is more general (one could use it for > network communication, etc.) load/save are a bit missleading. I'd rather > see read/write or other names that more clearly communicate what the > functions are doing. I used save/load consistently specifically to distinguish from read/write which seemed to me too suggestive of persistence, files and streams. > 3. archive naming: > The word archive also seems to be associated with persistence. I think > serializer would much better describe the functionality. Another option I > could live with is serialization_stream (I slightly disagree with the > assertion in archives.html that an archive as modelled by this library is > not a stream. It might not be what C++ folks traditionally understand a > stream is but to me it definitely is a more general stream, i.e. a stream > of objects/things/whatever). Archive is perhaps a little too suggestive. I borrowed from MFC. Making changes would have a huge ripple effect through code, file names, namepace names and documentation. I don't find any proposals for alternate naming sufficiently compelling to justify this. > 4. Object tracking 1: Seeming contradiction > I've had difficulty determining how exactly object tracking works. I > believe the associated docs are slightly contradictory: > - Under exceptions.html#pointer_conflict I read that the pointer_conflict > exception is thrown when we save a class member through a pointer first > and then "normally" (i.e. through a reference). Correct. > - traits.html#tracking says "... That is[,] addresses of serialized > objects are tracked if and only if an object of the same type is anywhere > in the program serialized through a pointer." Correct. > The second sentence seems to contradict the first one in that it does not > specify that the sequence of saving is important I see no conflict here > (I assume that pointer_conflict exception is not thrown if we save > normally first and then through a pointer). Correct > Moreover, I don't see how the library could possibly > achieve the "anywhere in the program" bit. It is tricky and it does work. I works by instantitiating a static variable. Static variables are constructed before main() is invoked. These static variables register themselves in global table when constructed. So even though a template is used "anywhere in the program" the entry in the global table exists before execution starts. I'm reluctant to include such information in the manual. > 5. Object tracking 2: It should not be possible to serialize pointers > referencing objects of types that have track_never tracking type. LOL - tell that to library users. There are lots of things that users are convinced they have to do that I don't think are a good idea. As a library writer I'm not in position to enforce my ideas how users should use the library. On this particular point I would be very suspicious about such a usage but as practical matter I just have to include a warning and move on. special.html#objecttracking says: <quote> By definition, data types designated primitive by Implementation Level class serialization trait are never tracked. If it is desired to track a shared primitive object through a pointer (e.g. a long used as a reference count), It should be wrapped in a class/struct so that it is an identifiable type. The alternative of changing the implementation level of a long would affect all longs serialized in the whole program - probably not what one would intend. </quote> > I think serializing untracked pointers almost never makes sense. If it > does anyway the pointed-to object can always be saved by dereferencing the > pointer. Such an error should probably be signalled with an exception. I don't understand this. > 6. Object tracking 3: One should be able to activate tracking on the fly > Rarely it makes sense to save even primitive types in tracked mode (e.g. > the example quoted in 6.). That's why I think setting the tracking type > per type is not flexible enough. It should be possible to override the > default somehow. I could imagine to save such pointers as follows: > class T > { > ... > int i; > int * pI; // always points to i > }; > template<class Archive > > void T::save(Archive &ar) const > { > ar << track( i ); // save the int here, keep track of the pointer > ar << track( pI ); // only save a reference to the int > } > Since it is an error to save an untracked type by pointer even the second > line needs the track( ) call. A main function of using a trait is to avoid instantiation of code that won't ever be used. If I understand your proposal we would have to instantiate tracking code even if it isn't used. But my main objection thing about this proposal is that it introduces a runtime modality into the type traits. This sound like it would very hard to debug and verify. I see lots of difficulties and very little advantage to trying to add this. > 7. I think the enum tracking_type should rather be named tracking_mode as > the _type suffix suggests something else than an enum. I don't think the change is sufficiently compelling to justify the hassle associated with this. > 8. I don't understand how function instantiation as described under > special.html#instantiation works. The description seems to indicate that > all possible archive classes need to be included in the files of all types > that are exported. Is that true? True. All archives that might be used have to be included. This is an artifact of using templates rather than virtual functions. Templates regenerate the code for each combination of serializable type and archive. This results in faster code - but more of it. There were strong objections raised in the first review about the fact it used virtual functions rather then templates - so it was changed to templates here. > 9. The library registers all kinds of stuff with static instances. This > precludes its use outside main(). Hmmm - that would be news to me. Robert Ramey

6 7

Re: [boost] [serialization] not so formal review
by Robert Ramey 26 Apr '04

26 Apr '04

Gennadiy Rozental wrote > Unfortunately I was not able to look with proper attention onto your > submission during review. One thing I did though: all the major issues I > mentioned in my original review looks resolved. I am sure will look into > more details later, but for now it is enough for me to cast YES vote. > This library cover very important problem domain in software development > and I think we all have now solid solution. Thanks and congratulation to > Robert for being able to bring it to us. I was waiting for a comment from you. Your incredibly insightful, exhaustive and focused review of the previous version was the main driving force behind this version. Looking back, it's still hard to for me to believe that in the six hours you said you spent anyone could really understand the implementation to the depth you did. Basically, all I did was to implement all your suggestions one at a time. Early on I switched over to your test library. This permitted me to add features one at a time and test at each stage. It did result in a lot of code being rewritten several times. But I think in system like this one can't really look far enough into the future implementation to avoid this. So it's not too much to say that if this library lives up to the hopes and expectations I have for it, it will be due to a collision between your previous review and my personality flaw that inspires me to throw myself at lost causes. I was going to suggest you might separate some time to review it. On the other hand, maybe I should quite while I'm ahead. Robert Ramey

1 0

Formal review: serialization
by Jeff Flinn 26 Apr '04

26 Apr '04

I was not involved in the original review. > Do you think the library should be accepted as a Boost library? Yes. > What is your evaluation of the design? The design, from a usage standpoint is excellent. Coming from the MFC world, boost::serialization far surpasses MFC's in usability and flexibility. Particularly notable are: no need for a common base class, a single serialize method used both for input/output. The only problem I see is that programming errors in some cases can be difficult track down, but no more so than with any template intensive library. While the current methods for Free Functions and Splitting save/load methods are certainly understandable and work. It would be nice to be able (partial)specialize the "serialize" function base on its IO type. It would also be nice to utilize enable_if to generate different code when the serialize function is instantiated for input/output archives. This would allow compile time constructs similar to mfc's runtime Ar.IsLoad(). > What is your evaluation of the implementation? I've been using the serialization library since version 13. All previous version bugs/issues have been cleared up with version 18. I've been able to remove all workarounds from my code, in particular dealing with support of multiple archive types in a single translation unit including binary, text and xml. Performance is more than adequate for my purposes. My application uses binary serialization to implement drag/drop. On a 3 year old 2GHz pc, a pair of save/loads of a ~2MB including graphical updates takes less than 2 seconds. I have only briefly viewed library source code when finding workarounds in previous versions. Others here are much more qualified to render a verdict in this regard. > What is your evaluation of the documentation? The documentation allowed me to add serialization to my application without needing to look at header/implementation files. Though, I'm sure I carry some context from having worked with MFC serialization. One misleading aspect IMO is with the Non-Intrusive Version example. The example implies that you would need access to the data members. I think an example of what to do when you don't have access to the data members is needed. For example, how would one serialize a boost::filesystem::path object. namespace boost { namespace serialization { template<class Archive> void save( Archive & ar, const boost::filesystem::path & t, unsigned int version ) { std::string lPathString( t.native_file_string() ); ar << make_nvp( "PathString", lPathString ); } template<class Archive> void load( Archive & ar, boost::filesystem::path & t, unsigned int version ) { std::string lPathString; ar >> make_nvp( "PathString", lPathString ); t = boost::filesystem::path( lPathString, boost::filesystem::native ); } } } BOOST_SERIALIZATION_SPLIT_FREE( boost::filesystem::path ) I'm sure this could be improved upon, but without it, there is a danger that many will think - "can't be used for my application". Seeing an examples like this makes it a little easier to remember that the template functions need to be defined in the boost::serialization namespace. > What is your evaluation of the potential usefulness of the library? I've always considered serialization to be a major element missing from C++. Nearly every application uses some method of custom serialization today. I've saved 100's of hours already in using boost::serialization rather than spinning custom file formats or implementing connections to DBMS systems to store/retrieve data. > Did you try to use the library? With what compiler? Did you have any problems? Yes, with VC71. As stated above, all problems with versions previous to version 18 have been corrected. One, recent problem is an access violation when loading a saved shared_ptr(NULL). > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Applied in an actual development project over the last several months. > Are you knowledgeable about the problem domain? I've some experience with MFC serialization. Thanks for a great library! ----------------- Jeff Flinn Applied Dynamics, International

2 3

[Boost-bugs] [ boost-Support Requests-942349 ] Problem compiling :/
by SourceForge.net 26 Apr '04

26 Apr '04

Support Requests item #942349, was opened at 2004-04-26 07:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=942349&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem compiling :/ Initial Comment: Hi :) I've some problems compiling code that use \boost\iterator\transform_iterator.hpp (under VC++ 7 - VS2K2) : transform_iterator.hpp(45) : error C2825 : 'UnaryFunction::result_type': cannot form a qualified name transform_iterator.hpp(45) : error C2039: 'result_type' : is not a member of 'operator``global namespace''' transform_iterator.hpp(45) : fatal error C1507 : previous user errors and subsequent error recovery halt further compilation Thanks in advance :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=942349&group_i… ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re:[boost] Re:Re:Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Vladimir Prus wrote: > > Robert Ramey wrote: > > I guess I have two questions: > 1. Won't serialization fail in some way if I just seek the stream to the > position found in index and try reading. > 2. For random access I need to make sure that all saved objects have > export > key. How do I do that? Not necessary out-of-the box but where I can plug > the check? > I believe the original question referred the ability to "browse" the archive for purposes of debugging etc. My view would be that the best way to do this would be to create and xml_archve. Your use case suggested a 30 data would probably would end up as a 90MB XML datafile. The reason for thinking in XML would be that I would hope that here exists "XML Browser for large files" which would be suitable for this case. If such a thing doesn't exist - I would prefer spending time making this general purpose tool - (and maybe a commercial product) to making a custom archive of narrow purpose. Random access into an archive would require some thought. First, it's not clear how it would be used. In general archives are nested structures, one could de-serialize an inner piece - but to where? The original data structure was embedded in something else which is not now there. So this can really only consider in the context of a specific application. Here are a couple of plausible scenarios. a) A general purpose archive browser - this could browse the archive in a random manner but wouldn't actually de-serialize the data. I don't see any real problem here. One would need to create an index either as a side effect of archive create or with a second pass over the final archive. b) using serialization for a data-state logging. Log(Archive ar, statedata){ // save seek point to index // append to archive ar << statedata; } Recover(Archive ar, statedata &, seekpoint) // set stream seekpoint ar >> statedata } I could envision something like this being made to work. So I would say that generally, serialization would be expected to be a serial operation. (surprise!). On the other hand, in certain special situations it might be possible/convenient to provide for some random access but I would expect that to be application specific. > >> The reason why I think the other is important, it that's it's actually > >> saving/loading support for plain C++ array -- which is rather basic > >> thing. > >> > > > > Hmmm - the library already implements serialization of plane C++ arrays > by > > serializing each element. > > For *fixed-size* arrays. But not for dynamically allocated arrays. BTW, it > seems we need two wrappers for completeness: > one for dynamic arrays with element-wise save I would envision one using ar << element_count For(i = 0; I < element_count; i++) ar << element[i] I'm not sure that its worth adding and documenting such an obvious and trivial thing as a separate wrapper. > and another for dynamic arrays with binary save. I see the binary object as filling that role. Ar << make_binary_object(dynamic_array_address, element_size * element_count); I once did propose a manual section name "Serialization Wrappers" which would have a couple of examples and highlight the fact that nvp and binary_object are instances of this concept. The idea was received unenthusiastically at the time but now I'm becoming convinced It's more effective to explain and illustrate the concept rather than try to anticipate all the wrappers that users might need. Actually, I think having such a section would have avoided the confusion surrounding the intended usage and purpose of binary_object. > I agree. I actually have a *crazy* but cute idea that one can use file > offset for object id. How object ids are assigned and can I customize that > process? That would keep overhead at absolute minimum. Object_id are assigned sequentially starting with 0. They are only used for classes which require tracking (e.g. when instances are serialized through pointers) they are used as indices into a vector so using these indices keeps overhead to a minimum. There are cases when an object id is assigned but not written to the archive I don't see these as having much utility outside of serialization. > Ah, I've missed that. Do I need to provide both 'type' and 'value'? Can't > serialization library work with just one? Could be. I just provided both so that I could interoperate with mpl without having to think about each specific case. > >> It also necessary to provide overload for char*. Does not count as > >> primitive > >> type? > > > > Default implementation for char * will work as it does for other > pointers. > > Eh... I though that serialization of pointers to builtin types is just not > allowed. > Default implementation level for pointers to primitives is set to not-serializable. This is resetable as it is for any other type. I doubt that on would want to do it for something like int or double as I would expect a lot of unintended side effects. One might want to use STRONG_TYPEDEF to define another int or double type and reset the implementation level of that - but that going off on a tangent. > Actually, my archive initially have only one (non-templated) 'save' for > unsigned. I got compile error until I've declared 'save' for const char*. > I'm not sure why. Its probably because of the above (pointer to a primitive type). Attempts to serialize instances of types whose implementation level is set to not-serializable will result in compile time assertions. (these assertions are sometimes the reason for the deep nested mpl). > > I came to conclude it presented a big security risk. The problem is the > > following: > > > later: > > > > char str[MAX_STRING_SIZE] > > > > ar >> static_cast<char *>(str); // to avoid str being treated as an > array > > > > suppose the text archive gets corrupted to: > > > > 3000 abc............ > > > > The archive will load with a buffer overrun - a security risk. > > Right. I think this problem can be addressed with a wrapper for dynamic > array > > char* str(0); > ar >> make_dynarray_wrapper(str) > > so that the library allocates the string itself. How does it know what size to make the array? Maybe you meen Ar >> make_dynarray_wrapper(str, number of elements * element size) Of course for char arrays one could use Ar << binary_object(str, element_count * element_size) And it would still be portable. > >> Can I define only one 'load' for unsigned int? > > > > As oppose to ? > > As opposed to overloads for all builtin types. For polymorphic_archive we > can't have templated function which 'fallbacks' anywhere. We need to have > a > closed set of virtual functions and I wonder what's the minimal set. > > the rest. BTW this provided a huge benefit. In the original version of > > last year I got into a never-ending battle to specify virtual functions > > which was > > dependent on the compiler - long long, etc. It was hopeless - moving to > > templates solved that. > > :-( I guess we're back to those problems. > I have recently got the polymorphic array working on my machine. Only a couple really small changes to the library code were required. For the list of primitive types I included all portable C++ primitive types. (that is no long long, __int64 etc.) I'm not sure how much interest the polymorphic archive will engender and it's a little hard to understand until you've actually spent enough time with the library to appreciate the limitations of templated code in certain scenarios. So although its clean (and clever) its not going to be easy to explain. Robert Ramey

3 2

[serialization] not so formal review
by Gennadiy Rozental 26 Apr '04

26 Apr '04

Hi, Robert. Unfortunately I was not able to look with proper attention onto your submission during review. One thing I did though: all the major issues I mentioned in my original review looks resolved. I am sure will look into more details later, but for now it is enough for me to cast YES vote. This library cover very important problem domain in software development and I think we all have now solid solution. Thanks and congratulation to Robert for being able to bring it to us. Regards, Gennadiy.

1 0

Serialization Formal Review #2
by Jeff Garland 26 Apr '04

26 Apr '04

All - Today (April 13th) is the start of the formal review of the Serialization library by Robert Ramey. The review will run until Monday April 26th. I will be serving as review manager. Library details are below. I have a number of special requests for this review: 1) This is a large, complex, and important library. Please don't wait till the end of the review period to start your review -- there is no additional room in the review schedule to extend the review period. 2) I am particularly interested in hearing from parties that have tried to extend the library by adding serialization for a new type or by building a new type of archive. The ability to easily extend the library for new types and novel types of archives is critical for this library. 3) If you reviewed the library during the first review, I would like your evaluation of whether the new version of the library addresses your original concerns. Also, if this is a re-review I would appreciate if you could send me a weblink from the mail archive to your original review posting(s). 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Details: ********************************************** >From the library synopsis: Here, we use the term "serialization" to mean the reversible deconstruction of an arbitrary set of C++ data structures to a sequence of bytes. Such a system can be used to reconstitute an equivalent structure in another program context. Depending on this context, this might used implement object persistence, remote parameter passing or other facility. In this system we use the term "archive" to refer to a specific rendering of this stream of bytes. This could be a file of binary data, text data, XML, or some other created by the user of this library. The latest package can be found at the following locations: http://www.rrsd.com/boost/index.htm http://groups.yahoo.com/group/boost/files/serialization18.zip Thanks, Jeff

5 6

documentation bug report for boost::random
by Dave Gomboc 25 Apr '04

25 Apr '04

The code sample at the top of the documentation is missing a semicolon. > boost::uniform_int<> six(1,6) // distribution that maps to 1..6 > // see random number distributions Dave

1 0

boost:filesystem::path throws eception on valid path name
by Andreas Pokorny 25 Apr '04

25 Apr '04

Hi, $ cat test.cpp #include <stdexcept> #include <iostream> #include <boost/filesystem/path.hpp> int main() { try { boost::filesystem::path p("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/"); } catch( std::exception &e ) { std::cout << e.what() << std::endl; } catch(...) { std::cout << "Unknown exception" << std::endl; } } $ g++ test.cpp -o test -lboost_filesystem $ ./test boost::filesystem::path: invalid name "g++-v3" in path: "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/" Is that supposed to happen? Regards, Andreas Pokorny

2 1

Quick thought on Date-Time
by Daryle Walker 25 Apr '04

25 Apr '04

[NOTE: I haven't worked on this library; I'm just going by the posts I see here.] For this increment/decrement by a month problem, is there any way to store a date with only a month resolution? Nothing smaller will be stored, so day crossovers won't be a problem. Wouldn't something similar have/already-had been done when skipping days but ignoring the exact hour? (Or does every date-time object work at the fractional-second level? If so, maybe that's what needs fixing.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 11:19 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates [...] > > #include "boost/archive/basic_archive.hpp" > > #include "boost/serialization/split_free.hpp" > > #include "boost/serialization/string.hpp" > > > > I think the two first are unnecessary (could you > > try this out? thx) > > Actually none of them are necessary. Ah the wonder of templates :-) > Wonderful they are, you're right :) So, I guess this is as good as it can get. Slightly OT: this issue of POI could be taken a little further to allow interoperability between (not necessarily template-based) libraries without the headache of having to include portions of them. This is what I have in mind: suppose a header-based library A provides support for or somehow uses a non-header (i.e. requires linking) library B, like this: // lib A #include <b.hpp> inline foo(){...} // does not depend on B inline bar(){...} // does not depend on B inline mess_with_B(){...} Now, if B is not linked in the project mess_with_B won't compile, so one has to move this function to a separate header that the user will/won't include depending of whether she wishes that functionality. Instead, one can do the following: // lib A #include <b.hpp> inline foo(){...} inline bar(){...} template<typename dummy> inline mess_with_B(dummy* =0){...} Voila, A works even if B is not linked in. If the user has linked B and wants to use mess_with_B, then she just has to call mess_with_B() as usual, template instantiation model will do the rest. Maybe I'm missing something, but I think this approach could be investigated a little further. One good example of use is for interoperability with Boost.Threads, for instance. Totally OT: I've posted a question regarding multi_index and composite keys a few posts ago. You being one of the reviewers, your opinion on that is greatly appreciated :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 9:25 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates > On Sun, 25 Apr 2004 20:34:34 +0200, JOAQUIN LOPEZ MU?Z wrote > > > Regarding the need to include "greg_serialize.hpp", I think > > a better approach, from the point of view of the user, is > > that serialization support is already embedded into > > "boost/date_time/gregorian/gregorian_types.hpp" and > > automatically provided if one of the archive headers > > > >...snip details... > > > > See what I mean? For this to work with minimum > > overhead, we'd need some forward headers for serialize, > > save, load, etc. to be included by > > "boost/date_time/gregorian/gregorian.hpp". > > Yes, I agree on the user perspecitive. I'm sorry I forgot to say > that in the > first few emails. I did say it here: > http://lists.boost.org/MailArchives/boost/msg63885.php > > > I'm not sure whether this forward headers are already > > provided by Robert's library. > > Why would I need 'forward headers' for this? > Well, since serialization support is entirely contained in function templates, you don't need any actual definition till POI (I might be wrong here, but I guess I'm not.) This can help reduce compilation time if you're not going to serialize dates at all. Matter of fact, seeing the includes in your example #include "boost/archive/basic_archive.hpp" #include "boost/serialization/split_free.hpp" #include "boost/serialization/string.hpp" I think the two first are unnecessary (could you try this out? thx) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[static_assert] Bad compiler message
by Vladimir Prus 25 Apr '04

25 Apr '04

Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya

6 7

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 0:37 am Asunto: [boost] [serialization+date_time] Serialization Review: serialization of dates > All - > > Since I'm the review manager I'm not doing a formal review of the > library, but > I thought I'd share some code and a few thoughts. If > serialization is > accepted users people will ask me and other library authors to provide > serialization support for some of the types in their libraries. So > to get a > feel for the difficulty of extending serialization for new types I > wrote the > serialization code for gregorian::date and some example code to > try it out. Regarding the need to include "greg_serialize.hpp", I think a better approach, from the point of view of the user, is that serialization support is already embedded into "boost/date_time/gregorian/gregorian_types.hpp" and automatically provided if one of the archive headers are included by the user program: // case 1 "boost/date_time/gregorian/gregorian.hpp" int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // does not work, text_oarchive not defined. oa << d; } // case 2 "boost/date_time/gregorian/gregorian.hpp" #include <boost/archive/text_oarchive.hpp> int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // OK, no need to include anything else fromd date-time oa << d; } See what I mean? For this to work with minimum overhead, we'd need some forward headers for serialize, save, load, etc. to be included by "boost/date_time/gregorian/gregorian.hpp". I'm not sure whether this forward headers are already provided by Robert's library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: >Well, I think it belongs in the library supplying the data type not in > serialization. Few reasons for this... ... good reasons listed 4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes. FWIW - this gets my vote: > So for the particular case I posted I was planning on putting this code in > boost/date_time/gregorian/greg_serialize.hpp > Time could would go into > boost/date_time/posix_time/time_serialize.hpp Considering the above, you might want to think about tweaking date time. By making a default constructor (that initializes as "not a date"), you could implement serialization as template member functions along the lines of the above. In this way adding serialization would: a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used. Robert Ramey

3 3

Re:Re:Re: [boost] [serialization+date_time] Serialization
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: > > a) no extra compile time overhead > > b) no extra run-time overhead > > c) no extra file inclusion > > d) no extra "conceptual" overhead. That is one would never have to even > > think about it - it would always be there just lurking waiting to be > > of service. It would just work when used. > > Are you saying there is actually extra runtime overhead with the way I've > implemented serialization? If so, that needs to be in the docs b/c I was > under the impression that external versus internal implementations would > be > the same... > I didn't mean to imply your method had any runtime overhead - I was just restating all the features. However, the other points are real advantages of just putting it in with the class definition. BTW the non - intrusive version could also be put in the normal class header. However if its too complicated it might end up requiring more file inclusion so it would have to be considered on a case by case basis. I personally don't have a strong position on this. As far as serialization is concerned the alternatives are all equivalent. The decision where to but the serialization templates can be decided on other factors. Robert Ramey

2 1

New dynamic_bitset
by Gennaro Prota 25 Apr '04

25 Apr '04

Hi everybody, as I have mentioned in some post here, a new version of dynamic_bitset is in the sandbox. I've finished everything 4/5 days ago (including new and more tests) and thought to move it to the main repository, as Jeremy asked too. But I've had an important familiar problem and I'm looking for a job and an apartment at the same time. With all likelihood I'll be at my old home, where is my pc, just for a couple of hours on Saturday and Sunday (except for this weekend, where Monday is holidays too). There could be other free mornings here and there but I can't guarantee. So I ask: should I move everything to the main repository or should I wait until I can devote more time to follow discussions and fix possible regressions? If the next release is far away then 5 or 6 hours a week should be adequate to review the regression logs and fix any problems that could arise. I'll check the list again tomorrow. Sorry for the inconvenience. PS: I had a (very) quick look at the thread about the FC++ review result. Just want to say that I think Brian is a great asset to the C++ community at large. His only mistake is that he isn't posting anymore to the groups, if not sporadically. Please, come back soon, Brian :) Genny.

6 23

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Abril 25, 2004 6:05 am Asunto: Re: [boost] [multi_index] composite keys: request for advice > On Sun, Apr 25, 2004 at 03:54:31AM +0200, JOAQUIN LOPEZ MU?Z wrote: > > > that if you call these two object "k" and "t" (key and tuple), > > > then you should have > > > k < t false > > > t < k false > > > t == k does not compile > > > That's just my quick hunch based on what I've quoted above; I > haven't> > considered what consequences it has for the library, > but that's my > > > intuitive notion of how tuples as "partial keys" ought to work. > > > > I guess I agree with you, but I wanted to bring this > > in to the list to gather some opinions. Following your > > approach, what should we do with > > > > k <= t > > t <= k > > > > The options are: > > > > a. they hold true > > b. they do not compile > > > > I don't have any strong argument in favor of any option. > > If there are other std:: or boost:: types which model the > StrictWeakOrdering concept (without having total orders), I would see > what they do and follow their lead. > > If not, I would make the "<=" operators not compile, since > k <= t > can always be rewritten by clients as > !(t < k) > and the narrower interface reduces the likelihood of someone > mistakenlygetting the impression that there's a total ordering > here (IMO). > I've scanned Boost and results are not conclusive. At least one class (shared_ptr) does define operator< and does not define <=, >= etc. so I'm not alone. I think I'll follow your advice and be conservative here (we'll always have time to extend this; the other way around is more problematic). So, the rules I'll stick with are: 1. if k and t have the same number of elements then k==t, k!=t, k<t, k>t, k<=t, k>=t, t==k, t!=k, t<k, t>k, t<=k, t>=k, are all defined and follow the lexicographical convention. 2. If k and t have different number of elements, then k<t,k>t, t<k,t>k are the only operators defined and follow the "clipping rule" (compare lexicographically taking the minimum of the lengths of the operands.) 3. std::less and std::greater are specialized to accept comparison between composite_key results and tuples, according to the previous definition. No other std comparison object is specialized. If nobody finds a problem with this, these are the rules that'll go into the implementation of composite_key. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[serialization+date_time] Serialization Review: serialization of dates
by Jeff Garland 25 Apr '04

25 Apr '04

All - Since I'm the review manager I'm not doing a formal review of the library, but I thought I'd share some code and a few thoughts. If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries. So to get a feel for the difficulty of extending serialization for new types I wrote the serialization code for gregorian::date and some example code to try it out. Of course this sort of extension is a critical aspect of the library design since everyone with a unique type will need to write serialization code. Overall I felt the docs did a pretty good job of explaining what need to be done and the code turns out to be reasonably trivial. Note that the code is more verbose than required as I did not use all of Robert's macros. Also, gregorian::date doesn't currently have a default constructor and hence it is a more challenging case (as I recall the first submission of the serialization lib required default constructors). When programming with dates and times putting them into collections is quite common. Fortunately, one of the most impressive aspects of the current serialization library is the ability to handle stl collections. So I was glad to find (as I expected) that by enabling the serialization of gregorian::date serialization of collections of date's comes along for free. I've attached the code and the serialized file for your reading enjoyment :-) Jeff

2 4

Boost Unicode support ideas
by Jeremy Maitin-Shepard 25 Apr '04

25 Apr '04

It seems that Unicode support in Boost (which could lead to Unicode support in the C++ language and standard library) would be quite desirable. The IBM International Components for Unicode (ICU) library (http://oss.software.ibm.com/icu/) is an existing C++ library with what appears to be a Boost-compatible license, which provides all or most of the Unicode support that would be desired in Boost or the C++ standard library, in addition to Unicode-equivalents of libraries already either in the standard library or in Boost, including number/currency formatting, date formatting, message formatting, and a regular expression library. Unfortunately, it does not use C++ exceptions to signal exceptional conditions (but rather it uses an error code return mechanism), it does not follow Boost naming conventions, and although there are some C++-specific facilities, most of the C++ API is the same as the C API, thus resulting in a less-than-optimal C++ interface. Nonetheless, I think Boostifying the ICU library would be quite feasible, whereas attempting to reimplement all of the desired functionality that the ICU library provides would be extremely time consuming, since the collating and other services in the ICU library already support a large number of locales, and the character-set conversion facilities support a large number of character sets. The representation of locales does present an issue that needs to be considered. The existing C++ standard locale facets are not very suitable for a variety of reasons: - The standard facets (and the locale class itself, in that it is a functor for comparing basic_strings) are tied to facilities such as std::basic_string and std::ios_base which are not suitable for Unicode support. - The interface of std::collate<Ch> is not at all suitable for providing all of the functionality desired for Unicode string collation. A suitable Unicode collation facility should at least allow for user-selection of the strength level used (refer to http://www.unicode.org/unicode/reports/tr10/) and would ideally also support customizations as extensive as the ICU library does (refer to http://oss.software.ibm.com/icu/userguide/Collate_ServiceArchitecture.html and http://oss.software.ibm.com/icu/userguide/Collate_Customization.html) - Facilities such as Unicode string collation are heavily data-driven, and it would be inefficient to load the data for facilities that are not used. This could be avoided by using some sort of lazy loading mechanism. It would still be possible to use the standard locale object as a container of an entirely new set of facets, which could be loaded from the data sources based on the name of the locale, and ``injected'' into an existing locale object, by calling some function. It is not clear, however, what advantage this would serve over simply using a thin-wrapper over a locale name to represent a ``locale,'' as is done in the ICU library. -- Jeremy Maitin-Shepard

9 36

Re: [boost] Re: [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Domingo, Abril 25, 2004 10:11 am Asunto: [boost] Re: [multi_index] composite keys: request for advice > > "Joaquin M Lopez Munoz" <joaquin(a)tid.es> wrote: > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > OT question 1: will it be possible to specify calculated > index as part of composite index? I take you mean "calculated key" and "composite key". Yes, it is possible, composite_key does accept any key extractor, it needs not be multi_index::member. > > > OT question 2 (I could had asked already): would it be somehow > possible for calculated index to use user supplied functor > and then sorting sequenced index according this index? > > This would create 'dynamic index', modifiable during runtime. I'm not quite getting you; the following shows how to specifiy the comparison predicate at run time, I don't know if this is what you are asking. typedef multi_index_container< employee, indexed_by< ordered_unique< identity<employee>, boost::function<bool (const employee&)> > > > employee_set; ... bool foo(const employee&); ... employee_set::ctor_args_list cal; cal.get<0>.get<1>=foo; // 2nd argument of the first index employee_set es(cal); Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] regex lib: bug with sets and back ref
by Benzinger, Ralph 25 Apr '04

25 Apr '04

> > The following behavior seems to be a bug: > > > > * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' > > That looks correct. > > > * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' > > That looks correct. > > > * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? > > It should 'bcbc' if you're calling regex_search and nothing if you're > calling regex_match. Sorry if I wasn't clear enough. All tests use regex_grep. In the last example, however, regex_grep _doesn't_ find "bcbc", even though it should. I would assume it's an issue with regex_compile, as the only difference between (2) and (3) is the way the set is defined. Ralph

2 1

alternative stringstream class
by Samuel Krempp 25 Apr '04

25 Apr '04

I meant to mention this for a while : I've written an alternative stringstream class implementation as part of boost::format, with 2 motivations : a. make boost::format compile on platforms that don't provide std::stringstream (gcc-2.95) b. allow more efficient use of stringstream in the context of boost::format (by adding copy-less access to the stringstream's buffer, and allowing reuse of the buffer) Now it's been there working hand in hand with boost::format for a while, compiling ok on mostly all platforms, but I dont know what to do about this class, if I should leave it there undocumented and unmentionned, or document it, or make it a mini-library, or a detail or whatever. IMO this class might interest some users, as it is more flexible than std::stringstream (allowing more efficient uses in some situations), while it includes the original stringstream's interface, keeps its overall design, and ease-of-use. It lies in boost/format/alt_stringstream.hpp (and _impl.hpp) it depends on the rest of boost::format only due to workaround settings (mainly required by gcc-2.95) alt_stringstream provides the features of std::stringstream, plus : void clear_buffer(); // calls seekpos // 0-copy access : Ch * begin() const std::streamsize size() const std::streamsize cur_size() const // copy buffer to string : string_type cur_str() const // [pbase, pptr[ This cur_str() function differ from the std::stringstream str() function, which returns a copy of [pbase, epptr[, thus unaffected by calls to seekpos, actually preventing buffer-reuse. (alt_stringstream defines functions cur_str() and str(), so it can have the same behaviour as std::stringstream if used with str() ) So, what should I do with this class ? -- Samuel

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- [...] > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > make_tuple(1,2)<=ck(record(1,2,3)); // yields true > > > > So far, this is all IMHO perfectly consistent, > > but the following design decision is not > > obvious to me: given the previous, what should > > be the result of > > > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > > > As these two objects are neither greater than the > > other, at least they are *equivalent*, but maybe > > allowing operator== to return true is too much. > > It sounds to me like you have a partial ordering or a strict weak > ordering, but not a total ordering. > http://www.sgi.com/tech/stl/StrictWeakOrdering.html > That is, these two objects: > ck(record(1,2,3)) make_tuple(1,2) > are in the same equivalence class, but they are not equal. My > hunch is > that if you call these two object "k" and "t" (key and tuple), > then you > should have > k < t false > t < k false > t == k does not compile > That's just my quick hunch based on what I've quoted above; I haven't > considered what consequences it has for the library, but that's my > intuitive notion of how tuples as "partial keys" ought to work. > I guess I agree with you, but I wanted to bring this in to the list to gather some opinions. Following your approach, what should we do with k <= t t <= k The options are: a. they hold true b. they do not compile I don't have any strong argument in favor of any option. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [multi_index] composite keys: request for advice
by Dave Gomboc 25 Apr '04

25 Apr '04

[reformatted] > // yields true > composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); > > // yields true > make_tuple(1,2)<=ck(record(1,2,3)); > > So far, this is all IMHO perfectly consistent, > but the following design decision is not > obvious to me: given the previous, what should > be the result of > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > As these two objects are neither greater than the > other, at least they are *equivalent*, but maybe > allowing operator== to return true is too much. operator== should return false here. The operands are equivalent, but not equal. Dave

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Sábado, Abril 24, 2004 11:13 pm Asunto: Re: [boost] [multi_index] composite keys: request for advice > Joaquin M Lopez Munoz <joaquin(a)tid.es> writes: > > > [snip: composite key system] > > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > This is not lexicographical order. According to lexicographical > ordering: > > (1, 2) < (1, 2, 3) > I did not claim that composite_key results and tuples are ordered lexicographically. What I said is that, given that a composite_key induces a lexicographical order on the elements of the multi_index_container it is used in, this can be taken advantage of to perform searches where only the first keys are given. For this to work, (1, 2) must be equivalent to (1,2,3) (meaning that !((1, 2)<(1,2,3)) and !((1,2,3)<(1,2)). I don't think there's any flaw with this approach, my doubt is about whether the fact that ck(record(1,2,3))<=make_tuple(1,2) and make_tuple(1,2)<=ck(record(1,2,3)) is reason enough to also make ck(record(1,2,3))==make_tuple(1,2) hold true. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

max elapsed time of boost::timer
by Toon Knapen 24 Apr '04

24 Apr '04

The documentation of boost::timer states that 'The maximum measurable elapsed time may be as low as 596.5 hours (or even less) ...'. Well on many 32bit platforms this would probably even be about 71 hours. Apparantly POSIX requires CLOCKS_PER_SEC to be 10e6, so if clock_t is 32 bit, the maximum of ( clock() / CLOCKS_PER_SEC ) is 4294 seconds. Because accuracy for clock() is generally about 1 sec, using clock() is not very usefull for doing timings of short (in time) events. Even more, for short events, the boost::timer might also influence the timing too much. So clock() is generally interesting for longer timings (from 10 sec onwards). But for long events the clock_t wraps around too fast (as mentioned above). And if you're unlucky that you _start_time = clock() is or a bit smaller than std::numeric_limits< clock_t >::max() (thus near the wrap-around point), directly afterwards the expression 'clock() - start' will result in a negative value. So I would like to suggest for boost::timer to use std::time_t and use std::time(NULL) instead of clock() and use std::difftime to calculate the elapsed time. toon

4 4

A question to preprocessor gurus
by Arkadiy Vertleyb 24 Apr '04

24 Apr '04

Hi all, The MS preprocessor has the __COUNTER__ extension that expands to the next integer every time when used. Can something like this be achieved in a portable manner, maybe with the help of Boost.Preprocessor library? Thanks, Arkadiy

4 7

[circular buffer] Status of Circular Buffer lib
by Jeff Garland 24 Apr '04

24 Apr '04

I'm looking at using circular buffer on a project. With only minor adaptation it does exactly what I need. I know it has been accepted, but isn't yet in CVS. So I have a few questions: 1) Is 3.6 from the files section the latest version? 2) Any showstopper bugs I should be aware of? 3) I'm assuming it works with VC7.1 and gcc 3.x? 4) Looks like my interface needs will be pretty basic: push_back, erase, clear. I assuming review changes won't impact these, correct? 5) Any reason it is NOT ready for prime time? Thx for the great submission! Jeff

2 2

[Boost-bugs] [ boost-Bugs-940941 ] failure in boost jam unit tests on cygwin
by SourceForge.net 23 Apr '04

23 Apr '04

Bugs item #940941, was opened at 2004-04-23 12:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=940941&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kannan Goundan (cakoose) Assigned to: Nobody/Anonymous (nobody) Summary: failure in boost jam unit tests on cygwin Initial Comment: Boost Jam Version 3.1.9 The unit tests seem to assume that the "/cygdrive" mount exists. I had changed mine to "/drive" and when I tried to build, I got an assertion failure: assertion "self->size < self->capacity" failed: file "strings.c", line 16 self->size == -165761813 self->capacity == 64 backtrace: assert_invariants (strings.c:15) string_free (strings.c:44) var_expand (expand.c:410) var_expand_unit_test (expand.c:696) run_unit_tets (jam.c:197) main (jam.c:299) Even if it's not worth it to accomodate non-standard Cygwin setups such as mine, I wouldn't expect the assertion failure to occur in strings.c. I think this can be reproduced by changing the "/cygdrive/c/foo/bar" string constants to invalid paths (in expand.c on lines 682 and 702) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=940941&group_i… ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

gcc34: undefined reference to `__gcov_init'
by Neal D. Becker 23 Apr '04

23 Apr '04

Any clues? I am trying to rebuild an app that worked with boost_1_31_0 and gcc3.3, now with gcc3.4. I completely rebuilt boost_1_31_0 libs using: PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 stage Then I clean out all objects from my build, and rebuilt with g++34, but I got this error: g++34 -Wl,-rpath,/usr/local/src/boost_1_31_0.gcc34/stage/lib,-rpath,./ -o Test2 Test2.o -L/usr/local/src/boost_1_31_0.gcc34/stage/lib -L. -lshannon -lboost_program_options-gcc -lrfftw -lfftw Test2.o(.text+0x7d6e): In function `global constructors keyed to _Z21DesignImpulseResponseRKN10__gnu_norm6vectorISt7complexIdESaIS2_EEE_GCOV': /home/nbecker/shannon/TestAloha/Test2.cc:360: undefined reference to `__gcov_init'

2 1

[serialization] and shared_ptr
by Jeff Flinn 23 Apr '04

23 Apr '04

The following code produces and access violation when loading the NULL shared_ptr. Is this an issue of not having registered the type pointed to? What would I need to do to appropriately handle this situation? #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/string.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <fstream> typedef std::string tName; class PointedToClass { tName mName; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Name", mName ); } public: ~PointedToClass(){} PointedToClass():mName("def"){} }; typedef boost::shared_ptr<PointedToClass> tPtr; class SomeClass { tName mName; tPtr mPtr; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Name", mName ); ar & boost::serialization::make_nvp( "Ptr", mPtr ); } public: SomeClass():mName("abc"),mPtr(){} }; int main( int argc, char* argv[] ) { SomeClass lSomeClass; { std::ofstream lOut( "SomeClass.archive", std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::xml_oarchive oa( lOut ); oa & boost::serialization::make_nvp( "SomeClass", lSomeClass ); } } { std::ifstream lIn( "SomeClass.archive" ); if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); } } return 0; }

1 0

numeric_cast
by Dill, John 23 Apr '04

23 Apr '04

I am wondering about the use-case of numeric_cast in this sample. unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); char schar_value = 0; try { schar_value = boost::numeric_cast<char>( uchar_max ); } catch ( boost::bad_numeric_cast ) { std::cout << "Overflow occurred..." << std::endl; } When I execute this sample, I don't get the exception. What's the background on this behavior? I'm using gcc 3.3.1. John

5 6

Assignment Library Review Result
by Tom Brinkman 23 Apr '04

23 Apr '04

Assignment Library Review Result Thanks to Thorsten Otteson for creating the Assignment Library. Review Comments: * Participation by boost members in the review was minimal, but the comments were generally constructive. * Considering that library is relatively small and the scope is fairly limited, less than normal review participation by boost members is to be expected. * The basic functionality of the library relieves the c++ developer from typing redundent c++ code for inserting/appending hard-coded data into containers. * Some issues about how the library is organized remain, but are easily resolved by seperating the headers and removing global dependencies. * There are many issues regarding the advanced functionality of this library that were not resolved during the review period. An additional review period should be provided to discuss advanced/optimized techniques for container population. * The name of the library should be changed. The name 'Assignment' does not fully describe the functionality of this library and could be improved. Review Conclusion: This library should be accpeted into boost under the following conditions: 1) Add a header file for each wrapped stl container. One header file containing all of the commonly used headers should also be provided. 2) Remove the global += operator. 3) Rename routines to reflect whether they are initializing, appending or inserting data. 4) Move all routines that extend boost libraries to the examples folder. 5) Documentation should broken up into a basic section and advanced section. 6) Documentation should add a short description about the advantages and disadvantage of each method provided by the library. 7) The library needs to add a boost test file. 8) Routines provided by the Assignment library having boost dependencies will require additional discussion during the post review period. 9) Basic library useage should not require any boost libraries outside of the boost::asignment library headers itself. 10) The techniques provided in the basic functionality of the library may not be optimal. Consideration of techniques for advanced generalized container initialization should be made. A post review period will be required to address advanced library useage. Thanks again and congratulations to Thorsten Otteson for creating a useful set of routines for the boost community. Review Manager, Tom Brinkman __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

lightweight replacement for boost::format
by John Torjo 23 Apr '04

23 Apr '04

Dear boosters, When needing to dump a lot of data into a string, we usually use boost::format. However, there have been lots of times when I needed a simple and lightweight replacement. I've used one for quite a while (see attachement). Basic usage: str_stream() << "str" << s << "int " << i; // automatic conversion to string. Example: std::string msg = str_stream() << "There have been " << users << " users logged on so far"; Also, attached an example. Any interest in something like this in boost? Best, John <cid:part1.07010200.01010400@torjo.com> ////////////////////////////////////////////////////////////////////// // example.cpp #include "str_stream.hpp" #include <iomanip> std::basic_ostream< wchar_t> & width_4( std::basic_ostream< wchar_t> & out) { out.width( 4); return out; } void print_c_like_str( const char * str) { std::cout << str << std::endl; } void test() { using namespace boost; // for wide strings. std::wstring str = wstr_stream() << std::oct << 8; str = wstr_stream() << std::setfill( L'0') << width_4 << 35 << std::endl; std::wcout << str; // for strings int users = 45; std::string s = str_stream() << "There have been " << users << " users logged on so far"; std::cout << s << std::endl; int words = 78; s = str_stream( "We found ") << words << " words."; std::cout << s << std::endl; // convert it to C-like string print_c_like_str( (str_stream() << "testing " << 1 << 2 << 3).c_str() ); std::cin.get(); } int main() { test(); } ////////////////////////////////////////////////////////////////////// // str_stream.h #ifndef BOOST_STR_STREAM__HPP_JT_2003MAR04 #define BOOST_STR_STREAM__HPP_JT_2003MAR04 // Copyright John Torjo 2003-2004 // Use, modification, and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) #include <string> #include <sstream> #include <iosfwd> namespace boost { namespace stream_detail { template< class char_type, class char_traits> struct as_c_str_res { typedef std::basic_string<char_type,char_traits> str_type; as_c_str_res( const str_type & str) { m_str = str; } operator const char_type*() const { return m_str.c_str(); } private: str_type m_str; }; } // basic_str_stream - allow stream usage, and then conversion to string template< class char_type, class char_traits = std::char_traits<char_type> > class basic_str_stream { typedef std::basic_stringstream< char_type, char_traits> stringstream_type; typedef std::basic_string< char_type, char_traits> string_type; typedef stream_detail::as_c_str_res<char_type,char_traits> c_like_str_type; public: // default construction basic_str_stream() {} // allow to_string like usage template< class type> basic_str_stream( const type & value) { *this << value; } stringstream_type & underlying_stream() const { return m_out; } // implicit conversion operator string_type() const { return m_out.str(); } // explicit conversion to string string_type str() const { return m_out.str(); } // explicit conversion to C-like string c_like_str_type c_str() const { return c_like_str_type( m_out.str() ); } private: mutable stringstream_type m_out; #ifndef NDEBUG public: void recalculate_string() const { m_string = m_out.str(); } private: mutable string_type m_string; #endif }; // class basic_str_stream typedef basic_str_stream< char> str_stream; typedef basic_str_stream< wchar_t> wstr_stream; template< class char_type, class char_traits, class type> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, const type & value) { out.underlying_stream() << value; #ifndef NDEBUG out.recalculate_string(); #endif return out; } // allow function IO manipulators template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::ios_base & (*func)( std::ios_base&) ) { func( out.underlying_stream()); return out; } template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::basic_ios< char_type, char_traits> & (*func)( std::basic_ios< char_type, char_traits> &) ) { func( out.underlying_stream()); return out; } template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::basic_ostream< char_type, char_traits> & (*func)( std::basic_ostream< char_type, char_traits> &) ) { func( out.underlying_stream()); return out; } } // namespace boost #endif // End of file

5 10

Date-Time, microsec_time_clock.hpp, bug?
by Val Samko 22 Apr '04

22 Apr '04

What is the type of timeval, used in class microsec_clock? It is not declared anywhere, and thus a compile time error in microsec_time_clock.hpp. Val Samko http://val.digiways.com

2 2

Re: Re: [boost] Serialization Formal Review #2
by Robert Ramey 22 Apr '04

22 Apr '04

Matthias Troyer > On Apr 13, 2004, at 9:42 PM, Robert Ramey wrote: >> Making a new archive class is described in the section "New Archives - >> Implementation". The model for an archive class is: > >> ////////////////////////////////////////////////////////////////////// >> /// >> // class trivial_iarchive - read serialized objects from a input text >> stream >> class trivial_iarchive > >> : public boost::archive::common_iarchive<trivial_iarchive> >> { >> // permit serialization system priledged access to permit >> // implementation of inline templates for maximum speed. >> friend class boost::serialization::load_access; > >> // member template for loading primitive types. >> // Override for any types/templates that special treatment >> template<class T> >> void load(T & t); > >> public: >> ////////////////////////////////////////////////////////// >> // public interface used by programs that use the >> // serialization library > >> // the >>> operator >> template<class T> >> trivial_iarchive & operator>>(T & t){ >> boost::serialization::load(* This(), t); >> return * This(); >> } > >> // archives are expected to support this function >> void load_binary(void *address, size_t count); > >> }; > >> So in theory one has to implement the two undefined functions. > >> For each primitive data type, int, float, etc. or any type designated >> as primitive define a "load" template for function to read them from the >> file. > >> For each data type that you want to treat specially - rather than >> allowing the serialization library to do the job - define an overload >> for operator. > Just a quick question: what should the default load (I mean > template<class T>> void load(T & t);) function do? Do I guess correctly > that it should never be called and is thus undefined to cause link-time > errors? It should handle all primitives not otherwise handled specifically. For example the default load for text archives resolves to input_stream >> t While for binary archives it resolves to load_binary(sizeof(t), t). > Looking through the documentation I find references to virtual > functions: And? >> class trivial_iarchive >> // all input archives must be derived from this base class. This base >> // class defines the virtual functions necessary for the serialization >> // library to handle special types for the serialization system. > I guess that these are incorrect comments left over from an old version? Correct. Robert Ramey

3 2

"typeof" implementation idea
by Arkadiy Vertleyb 22 Apr '04

22 Apr '04

"David Abrahams" <dave(a)boost-consulting.com> wrote > That's the basic idea behind all typeof() emulations that I've ever > seen. They all require some type registration to associate a > compile-time integral constant with a type. The innovation that Steve > brought, IIUC, was that with the registration of only class types, the > rest of the transformations possible in the type system could be > encoded by the library automatically. For example, if you register > class Foo, then the library can generate encodings for Foo*, Foo[2], > Foo**, int (Foo), Foo(*)(Foo,Foo), etc., so you don't have to register > those types. The problem is that those numbers can get very large... Right. What I am even more interested in, is the ability to generate encodings of complicated templates. Say I registered int, std::vector, and mpl::vector2, and the library should be able to work with std::vector<int>, mpl::vector2<std::vector<int>, mpl::vector2<int, int> >, etc. It looks like this can be solved pretty easily. I imagine that Boost.Lambda, for example might also benefit from the ability to encode/decode templates (and maybe Spirit, but I am not sure). > My guess is that manipulating array types in that way has a lower > cost at compile-time than using a vector_c, though using mpl probably > yields much nicer library code and vector_c is more portable. I don't suspect my solution is very compile-time efficient. But I don't have enough knowledge of compilers internals to estimate this. I believe the real advantage is in is simplicity. Anyway, here it is... Let's recall that to achieve our goal we have to: 1) Pass our expression to a function template, like: template<class T> SOMETHING foo(const T&); 2) inside foo() encode our type into a compile-time list of integers; 3) somehow manage to pass this list through the function boundaries; 4) decode the type. The most chalanging is 3. Let's define the following template: template<class N> struct sizer { char_[N::value]; }; The whole purpose of this is to create classes with a given sizeof (to be completely accurate we have to then divide this by sizeof(char)). Next template is what it is all about: template<class IntList> struct multi_int { typedef IntList int_list; template<class T> sizer<typename mpl::apply_if< typename mpl::less<T, typename mpl::size<int_list>::type>, mpl::at<IntList, T>, mpl::identity<mpl::int_<1> > >::type> get(const T&); }; So, if we have an object of this class, x, then sizeof(x.get(mpl::int_<n>())) defines the nth element of the list, and out-of-range values produce 1. The list can be reproduced like, say: #define BOOST_RTL_TYPEITEM(Expr, N)\ mpl::int_<sizeof(Expr.get(mpl::int_<N>()))> mpl::vector<\ BOOST_RTL_TYPEITEM(x, 0) , BOOST_RTL_TYPEITEM(x, 1) ... , BOOST_RTL_TYPEITEM(x, N) > Where it can be generated by the preprocessor for a fairly large N. The reproduced list is larger than the original one, and is 1-padded. The encoding scheme I use does not require to know where the list ends, so this doesn't matter. This is basically it. The return type of the function foo above (sorry for such name) is going to be multi_int<encode<T>::type>, where T is the original type, and encode template works accordingly to some encoding scheme. The encoding scheme to choose is a separate issue. In my example I encode templates by adding the encodings of its parameters to the code of template itself. So, if int is 1, std::vector is 2, and mpl::vector2 is 3, the above example: mpl::vector2<std::vector<int>, mpl::vector2<int, int> > becomes 3 2 1 3 1 1 Also note that all templates with one parameter behave similarly, so only one registration macro is required. Another macro is required to register templates with two parameters, etc. > For what it's worth, I'm pretty sure I know how to solve the problem > that most typeof() implementations strip top-level references. See > boost/iterator/is_lvalue_iterator.hpp for a demonstration. Cool. I imagine pointers are pretty easy, but references surely represent a big problem... I will follow up with the working sketch... Regards, Arkadiy

4 8

thread API
by Christophe Meessen 22 Apr '04

22 Apr '04

Hello, I have axamined the thread_dev header file. Unfortunately the cpp file doesn't seem to correspond. I must admit that the proposed change is a great improvement and removes many objections I had regarding boost thread. Changing the thread object into a handle allows now to copy it. It is then possible to add a thread member variable to a class. A start method can then assign the started thread instance to it. So the gap between boost threads and start&run model gets narrow. The source is one year old. What is the time plan to release it ? -- Bien cordialement, Ch. Meessen

2 1

boost on HPUX
by Toon Knapen 22 Apr '04

22 Apr '04

I'm trying to get the regression tests on HPUX up to date again. However, the 'random_test' loops indefinitly (in the kreutzler1986 test) when compiled with gcc 3.2 (20020329). Additionally I can't debug it since there are no precompiled gdb's available from HP and gdb 6.1 is AFAICT not supported on HPUXi 11.22. So before starting commenting parts out of the random_test to find the line where it hangs, anybody (who's familiar with the implementation of this test) any idea where I should start looking ? toon

1 0

Re:[boost] Re:Formal review: serialization
by Robert Ramey 22 Apr '04

22 Apr '04

Vladimir Prus wrote: > Robert Ramey wrote: > > >> -- (critical) The primary issue with the library is lack of reference > >> documentation > ... OK I don't see a problem with this - Thanks to Dave for the hint on how to handle this. > For those stubs, requirements docs that Dave mentioned would be nice. > However, there's code that user calls, and I'd like to see docs for that, > too. > > For example: > > binary_object make_binary_object(void* ptr, unsigned size); > Returns: binary_object(ptr, size); > > binary_object::save(Archive& ar, unsigned version) > Effects: Calls ar.save_binary(m_ptr, m_size); > > binary_object::load(Archive& ar, unsigned version) > Effects: Calls ar.load_binary(m_ptr, m_size); > Aside - I wouldn't expect load/save/load_binary/save_binary to ever be invoked by a library user. > It would be nice to avoid asking the user to do BOOST_CLASS_EXPORT for all > possible argument types. What's desirable is: > > template<class T> > void register_rpc_function(const char* name, void (*f)(const T&)) > { > functions[name] = ... ; > boost::serialization::export_class< function_call_1<T> > >::instantiate(); > } > > I can't put BOOST_CLASS_EXPORT in register_rpc function now. This situation is discussed in the documentation under the heading "Template Serialization Traits". There is an example that uses assignation of traits to the nvp<T> template. BOOST_CLASS_EXPORT is just a syntactic short hand to for the specialization above. Uh-oh - I just looked at the definition of BOOST_CLASS_EXPORT and I see it's not that obvious as it is in the other traits. I'll take a look at this. > I'm afraid the no matter how smart XML reader is, it still would have to > scan the entire file. > So what's wrong with that? I would guess that such an XML reader already exists somewhere and you cat get everything thing for free. Assuming this doesn't address your need, and you want to do some programming, one can create another XML archive version. This would create two output files. One exactly as it is now will another "index". When I was considering the options regarding XML output I briefly considered the possibility of creating two files - one like we have the one now - along with an optional parallel file containing the corresponding XML schema describing the XML archive. I decided to keep things simpler. But I think you see the idea. > > I can expand the doc a bit. binary_object is just a wrapper around a > size > > and pointer to permit them to be handled as pair. It presumes the > pointer > > already points to allocated storage. > > This last sentence is exactly what I'd like added to docs. > OK that's easy. Sorry for the confusion. > > It also presumes that the the size > > of thing its pointing to is the same on save and load. Its very > > lightweight. > > > > I don't see a need for the others, but of course any user can make the > > wrappers he needs. > > The reason why I think the other is important, it that's it's actually > saving/loading support for plain C++ array -- which is rather basic thing. > Hmmm - the library already implements serialization of plane C++ arrays by serializing each element. This is the more general solution as it calls serialization for each element. The only time one might want to do save/load for a whole array is for a non-portable binary file. Re: save/load asymmetry for polymorphic pointers. > As I've said previously, this is a bug which is easy to make and very hard > to debug. I think we can only wait for others to express an opinion, as we > fail to convince each other. Well, THAT we can agree on. > > BTW, one usage of XML archives did occur to me. By checking the name > tag > > on input, we can implement a crude check that save and load operations > are > > synchronized. This would effectively a debug mode for archives and > might > > be useful. > > But you won't catch a case where you save one type and load another. True, but I think it would help a lot - and practically free to implement. > So, the get zero overhead I need to tweak base class an disable tracking > of > pointers. Let me try that... yea, the results are nice. One one extra > element (class id) per saved item. If your not serializing pointers, the class_id isn't written to the archive even once. Object id is required for tracking, class id is required for pointers. If versioning is used, class-id is used once. I do not believe that there is any information stored in an archive which is not used. > > BTW, how to I set tracking level and implementation level for a template > class. I think I can partially specialize 'tracking_level', but it should > be mentioned in the docs. See docs section "Template Serialization Traits" > > >> - The documentation should really state the minimal set of > 'load'/'save' > >> overloads which will make archive usable. For example, it's probably > not > >> necessary to provide separate overload for 'bool', right? > > > > The document states: > > > > " However, we're not quite done. The above code addresses serialization > of > > all non-primitive types. To be complete, each primitive type must either > > be covered by a definition of template<typename T> void load(T & t); or > an > > overload of the >> operator" > > It also necessary to provide overload for char*. Does not count as > primitive > type? Default implementation for char * will work as it does for other pointers. Which is probably not what one has in mind. I have code in there for handling it as a c string (Its commented out). I tested it and it worked but I came to conclude it presented a big security risk. The problem is the following: char * str = "abc" ar << str; // no problem the (text) archive looks like 3 abc later: char str[MAX_STRING_SIZE] ar >> static_cast<char *>(str); // to avoid str being treated as an array suppose the text archive gets corrupted to: 3000 abc............ The archive will load with a buffer overrun - a security risk. So then one should dynamically allocate the storage according to the size - that is one should be using the std::string . So I decided to comment out the code that handles char *. > > > " If all primitive types have been accounted for, any program with > > serialization defined should work with the new archive." > > > > Maybe I can expand upon that a little to something like: > > > > "Any program with serialization defined should work with the new archive > > as long as every primitive type has a matching save/load function > > prototype or template." > > Can I define only one 'load' for unsigned int? As oppose to ? They way I implemented the included archives I specified load for those requiring special treatment and used a template as a fall back for the rest. BTW this provided a huge benefit. In the original version of last year I got into a never-ending battle to specify virtual functions which was dependent on the compiler - long long, etc. It was hopeless - moving to templates solved that. > > > > I've concluded this myself. Its pretty easy given the bjam setup. > Maybe > > it can be made even easier with a bjam argument or environmental > variable. > > It > > just needs to be explained. > > Right. BTW as a bjam expert, you might want to suggest how to do this in cool way. I would love to have a shell script which lets me do test_archive <toolset> <archive> But I don't see how to fix up the bjam files to support this. As a bjam expert, maybe you could look into this. > Do you mean you plan to always serialize char* as arrays and remove > 'load'/'save' overloads for char*? Again, I'm not sure I understand the > motivation. See above Robert Ramey

2 1

Serialization - access control
by Matthew Vogt 22 Apr '04

22 Apr '04

Previously, I posted that I was unhappy with the way access to an archive's save methods could be controlled. This was because the class the eventually invokes the 'save' method of an oarchive is a library class, and has to be given friend access. I have now realised that this was trying to control access the wrong way; instead of making the type-specific 'save' method private, the type-specific overload of 'operator<<' should made private to prevent general access for saving a given type. Here is a basic test that shows what I had been trying to achieve, now working correctly: //--------------------------------------------------------------------------- #include <boost/serialization/access.hpp> #include <boost/archive/common_oarchive.hpp> class float_storer { friend class boost::serialization::access; private: float f; template<class Archive> void serialize(Archive& archive, const unsigned int version) { archive & f; } }; namespace archive = boost::archive; class simple_oarchive : public archive::common_oarchive<simple_oarchive> { friend class archive::common_oarchive<simple_oarchive>; friend class archive::save_access; // Do nothing with library internal types simple_oarchive& operator<< (const archive::class_id_type&) { return *this; } simple_oarchive& operator<< (const archive::class_id_optional_type&) { return *this; } simple_oarchive& operator<< (const archive::class_id_reference_type&) { return *this; } simple_oarchive& operator<< (const archive::class_name_type&) { return *this; } simple_oarchive& operator<< (const archive::version_type&) { return *this; } simple_oarchive& operator<< (const archive::object_id_type&) { return *this; } simple_oarchive& operator<< (const archive::object_reference_type&) { return *this; } // Save any type that gets here template<typename T> void save(const T& t) {} // Only allow 'float_storer' to store floats friend class float_storer; simple_oarchive& operator<< (const float& t) { archive::save(*This(), t); return *This(); } public: // Allow anyone to store ints simple_oarchive& operator<< (const int& t) { archive::save(*This(), t); return *This(); } simple_oarchive& operator<< (const float_storer& t) { archive::save(*This(), t); return *This(); } }; int main(int, char**) { simple_oarchive oa; int i; oa << i; float f; oa << f; // I want this to fail float_storer fs; oa << fs; // I want this to succeed return 0; }

1 1

Re: Re: Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404211327.i3LDRov09314(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404202049.i3KKnwe25029(a)lawrencewelk.systems.susq.com>... > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > > > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > > > > > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > > > > char schar_value = 0; > > > > > > > > > > > > try { > > > > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > > > > } > > > > > > catch ( boost::bad_numeric_cast ) > > > > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > > > > > > > When I execute this sample, I don't get the exception. What's > > > > > > the background on this behavior? I'm using gcc 3.3.1. > > > > > > > > > > Your char is unsigned. > > > > > > > > I'd like to know why conceptually the exception isn't thrown. > > > > > > As I said, in too few words, is that your "char" is unsigned, so > > > "char" and "unsigned char" are essentially the same type. > > > Technically, they are distinct types (for overloading purposes, > > > for example), but they are both unsigned and the same size, so: > > > > > > assert(std::numeric_limits<char>::max() > > > == std::numeric_limits<unsigned char>::max()); > > > > > > on your system. > > > > Actually that is not the case. The max defined for unsigned > > char is 255, while for char is 127. Actually, char is > > supposedly equivalent to signed char, not to unsigned char. > > Based upon the evidence you presented, I concluded that your char > is equivalent to unsigned char. On what basis do you conclude > that your char is equivalent to signed char? Did you check > std::numeric_limits<char>::is_signed? Yes. Both char and signed char have identical is_signed and max, min. Unsigned char min, max and is_signed is different. Does the standard say that char can be either signed char or unsigned char, or is that just an implementation issue? Best, John

3 2

Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Fernando Cacciola" <fernando_cacciola(a)hotmail.com> wrote in message news:<c64iag$bes$1(a)sea.gmane.org>... > > "David Abrahams" <dave(a)boost-consulting.com> escribió en el mensaje > news:u3c6ywa5w.fsf@boost-consulting.com... > > "Dill, John" <john-dill(a)uiowa.edu> writes: > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > char schar_value = 0; > > > > > > try { > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > } > > > catch ( boost::bad_numeric_cast ) > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > When I execute this sample, I don't get the exception. What's the > > > background on this behavior? I'm using gcc 3.3.1. > > > > FWIW, there are known problems with numeric_cast, but a numeric > > conversion library that replaces the existing implementation has been > > accepted into Boost. We are just waiting for Fernando Cacciola to > > check it in. Fernando? > > > Indeed. The accepted numeric conversions library handles this case properly > (throwing). > Right now I'm technically on vacation until next Monday. I'll start working > with the review comments right next week. I'll check it in on CVS after I > made the neccesary changes. > > Anyway, users can download the review version from here: > > http://personales.ciudad.com.ar/fernando_cacciola/numeric_conversions.zip > > or > > http://groups.yahoo.com/group/boost/files/numeric_conversions.zip > > > Fernando Cacciola Thanks. Well, I didn't know this was out there so I wrote my own numeric_cast which works for those cases I described. It's not boost oriented, but all of the concepts should be convertible to mpl. Maybe it will be useful to someone. Best, John /*! * \file numeric_cast.hpp * \brief A cast which protects against silent underflow or overflow casts. */ #include <uiro/type/ct_if.hpp> #include <uiro/type/typelist.hpp> #include <uiro/utility/limits.hpp> namespace uiro { //! Exception used to indicate underflow in a numeric cast. class bad_numeric_cast : public std::bad_cast { public: virtual const char* what() const throw() { return "bad numeric cast"; } }; //! Exception used to indicate underflow in a numeric cast. class numeric_cast_underflow : public bad_numeric_cast { public: virtual const char* what() const throw() { return "underflow in numeric_cast"; } }; //! Exception used to indicate overflow in a numeric cast. class numeric_cast_overflow : public bad_numeric_cast { public: virtual const char* what() const throw() { return "overflow in numeric_cast"; } }; namespace internal { //! Selects the type with the largest minimum value. template <typename T1, typename T2> struct promote_min_traits { typedef TYPELIST_10(unsigned char, unsigned short, unsigned int, unsigned long, char, short, int, long, float, double) promote_order_typelist; enum { index1 = uiro::type::index_of<promote_order_typelist, T1>::value }; enum { index2 = uiro::type::index_of<promote_order_typelist, T2>::value }; typedef typename uiro::type::ct_if< uiro::type::greater_than_equal<index1,index2>::result, T1, T2>::result result; }; //! Selects the type with the largest maximum value. template <typename T1, typename T2> struct promote_max_traits { // May run into issues if sizeof(int) != sizeof(long) typedef TYPELIST_10(char, unsigned char, short, unsigned short, int, long, unsigned int, unsigned long, float, double) promote_order_typelist; enum { index1 = uiro::type::index_of<promote_order_typelist, T1>::value }; enum { index2 = uiro::type::index_of<promote_order_typelist, T2>::value }; typedef typename uiro::type::ct_if< uiro::type::greater_than_equal<index1,index2>::result, T1, T2>::result result; }; struct unsigned_tag {}; struct signed_tag {}; //! A numeric cast helper which handles the an unsigned source type //! without generating compiler warnings. template <typename Target, typename Source> inline Target numeric_cast_helper( Source arg, unsigned_tag ) { // An overflow condition. if ( static_cast<typename promote_max_traits<Source, Target>::result>( arg ) > static_cast<typename promote_max_traits<Source, Target>::result>( std::numeric_limits<Target>::max() ) ) { throw numeric_cast_overflow(); } return static_cast<Target>(arg); } //! A numeric cast helper which handles the an signed source type. template <typename Target, typename Source> inline Target numeric_cast_helper( Source arg, signed_tag ) { // A loss of negative range, or more generally an underflow. if ( ( arg < 0 && !std::numeric_limits<Target>::is_signed ) || ( static_cast<typename promote_min_traits<Source, Target>::result>( arg ) < static_cast<typename promote_min_traits<Source, Target>::result>( std::numeric_limits<Target>::min() ) ) ) { throw numeric_cast_underflow(); } // A loss of positive range. if ( static_cast<typename promote_max_traits<Source, Target>::result>( arg ) > static_cast<typename promote_max_traits<Source, Target>::result>( std::numeric_limits<Target>::max() ) ) { throw numeric_cast_overflow(); } return static_cast<Target>(arg); } } // end of namespace internal //! A numeric cast which throws on overflow or underflow. template <typename Target, typename Source> inline Target numeric_cast( Source arg ) { typedef typename uiro::type::ct_if<std::numeric_limits<Source>::is_signed, typename internal::signed_tag, typename internal::unsigned_tag>::result tag; return internal::numeric_cast_helper<Target>( arg, tag() ); } } // end of namespace uiro

1 0

Re: Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404202049.i3KKnwe25029(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > > char schar_value = 0; > > > > > > > > try { > > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > > } > > > > catch ( boost::bad_numeric_cast ) > > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > > > When I execute this sample, I don't get the exception. What's > > > > the background on this behavior? I'm using gcc 3.3.1. > > > > > > Your char is unsigned. > > > > I'd like to know why conceptually the exception isn't thrown. > > As I said, in too few words, is that your "char" is unsigned, so > "char" and "unsigned char" are essentially the same type. > Technically, they are distinct types (for overloading purposes, > for example), but they are both unsigned and the same size, so: > > assert(std::numeric_limits<char>::max() > == std::numeric_limits<unsigned char>::max()); > > on your system. Actually that is not the case. The max defined for unsigned char is 255, while for char is 127. Actually, char is supposedly equivalent to signed char, not to unsigned char. > > Why is it beneficial to have unsigned T to signed T overflows > > not be detected? It is not just char, but short, int, and long > > as well. > > Now that's another story. Changing "unsigned char" to > "unsigned" and "char" to "int" should cause an exception. If > that's not happening, I don't understand since > std::numeric_limits<unsigned>::max() is greater than > std::numeric_limits<int>::max(). Actually, I think those type conversions shouldn't cause an exception. Converting char to int for example should be no problem since the range of char is within the range of int. Should be similar for unsigned char and unsigned. > > If this was the intended behavior, then what is the reasoning > > behind it? > > What you describe isn't the intended behavior other than the char > problem. I think it is a problem when you have an unsigned char, range 0 to 255, put into a char, range -128 to 127, when you are converting an unsigned char value of 255 (the numeric_limits::max()) into a [signed] char. It is an overflow problem, and it doesn't generate an exception. From what you seem to say, this should be a bug. Best, John

2 1

Re:[boost] Formal review: serialization
by Robert Ramey 21 Apr '04

21 Apr '04

Vladimir Prus wrote: > Detailed comments are below. Some of them are marked as "critical" -- it > means I believe they should be addressed before the library is added to > official distribution. > > ** General issues ** > > -- (critical) The primary issue with the library is lack of reference > documentation -- exact description of semantics for every method > (preferrable in C++ std style) and overview for all important classes. The > library is non-trivial, and without such documentation user will have to > experiment to find out that exact semantic. > > Better internal docs (comments) are also needed. For example, I'm looking > at > save_access::end_preamble and don't know what it does. Comment for > basic_oarchive::end_preamble says what this method is for, but does not > say > when this method is called, which makes it hard to do anything. Again, > implementation is non-trivial. Lack of comments make it somewhat dangerous > to > use the library -- if I hit a bug while Robert is on vacation, I'm not > sure > I'll be able to quickly fix it locally. > > As an illustraction, I've already had a couple of bugs each costing > several hours to debug. > I think this is a little harsh. I've had lots of things I had spend several hours on - including iterator_adaptors, spirit, and mpl. I'm not against adding things to the documentation but in general I think it as good as or better than any other boost documentation. Having said that, I do incrementally clarify bits of documentation as people ask me questions. There's another point that has me a little bit stumped. Most of the boost libraries are code that one invokes with a documented signature. The list of invocations, syntax and semantics is what I think Vladimir is referring to here with "reference documentation". However, the serialization library is more "upside down" in that using it consists almost entirely of filling in stubs called by the serialization algorithm. So its not clear to me how the "reference documentation" would look compared to the current documents. > -- (critical) While BOOST_CLASS_EXPORT is a big step forward, I think it > can > be further improved. Now, if I export a class I need to include some > archive > headers before invoking BOOST_CLASS_EXPORT. The class can be only > serialized > to archives which were included. This means that to really export a class, > I > need to include *all* archive headers. That's not good. What I suggest is > > - create new class 'polymorphic_archive', which will have virtual > functions for saving/loading and create templated > 'polymorphic_wrapper', which can be used to add this polymorphic > interface to existing archive. > - always register all exported classes with polymorphic archive. When > serializing in a specific archive, check if class is registered > with > that archive. If not, serialize it via polymprphic wrapper. > > In fact, I'd be willing to help with polymorphic archive implementation, > but > some changes inside serialization library will be required. > There was much objection to the previous version which was based on virtual functions. The usage of templates has addressed those concerns but raised others related to instanticatiation. In the previous system the virtual function interface was fixed across all archives (even those not invented yet !) in the current system serialization code is generated from the archive and serialization templates a new every time. So as it stands one can't make a "library for type X" for all future archives. This can be addressed in two ways. For current archives one can follow the demo_pimpl example, and generate a library that has pre instantiated code for all know archives. This will be satisfactory in many cases. For those cases not addressed by the above solution - i.e. those a virtual interface will be required. This can be addressed by creating of a "polymorphic_archive" without requiring changes to the internals to the library. This is not difficult if done carefully, but it hasn't been done yet. It entails definition of an interface class. The concrete archive class would inherit and from both this interface as well as one of the current implementations. Its exactly the way the Microsoft COM is implemented. I have yet to do this. > -- (critical) I suspect BOOST_CLASS_EXPORT does not play nice with > templates. > Say I'm implementing RPC system: > > class function_call_base { virtual ~function_call_base() {} } ; > template<class Arg> > class function_call1 : public function_call_base {}; > > // in some code > rpc_server s; > s.register("foo", &foo); > > function_call_base* c; > while(archive >> c) > (*c)(); > > The idea is the caller will serialize instances of function_call1 and the > callee will deserialize it and call the proper function. To make this > work, > we have to BOOST_CLASS_EXPORT all used instantinations of function_call1. > We > can assume that all functions (and therefore all argument types) are > passed > to the 'register' function and can function can invoke BOOST_CLASS_EXPORT. > > Now the problem: BOOST_CLASS_EXPORT can be used only at top-level of a > translation unit. There's not way 'register' and automatically export a > class. > > The solution I'd like is: > > template<class T> > class export_class { > public: > static void instantiate(); > }; > > So that the object of this type can be created anywhere. > Doesn't including BOOST_CLASS_EXPORT in the header fill corresponding to the exported data type perform the equivalent function? It was certainly my intention that that was how it would be used. In this way the "export" would be addressed once and for all. That way all types used - and only those types would be instantiated. > -- One usage of the serialization library I have in mind is taking "debug > dumps" for an application. After the run, a separate tool can be used to > look > at those dumps. The size of data can potentially be rather large (e.g. > 100*640*480 or maybe more), so I'd rather not to load all data, but build > some index. So the question is: how is it possible to access specific part > of > archive without reading it all. I understand it's not possible in general, > but in some cases (e.g. BOOST_CLASS_EXPORT for everything) it should work. > I think the could fairly easily be addressed by making a derivation from the desired archive type and making an index on class_id and object_id or something like that. I wonder if there isn't an XML reader that opens just the toplevel and only opens the file as one "drills down". Then just serialize to XML and use that reader. > -- The documentation of 'make_binary_object' is very incomplete and does > not > tell the exact semantic. As far as I can tell, the function can be only > used > to load/store objects which have fixed size and will crash when > saving/loading new[]-d array -- which seemed an obvious use-case for me. > > I would suggest that we have two functions: > > make_pod_wrapper -- which is templated, has one parameter -- object, > and > stores sizeof(T) bytes. Another name -- make_static_array_wrapper. > > make_dynarray_wrapper -- which can be used to store/load arrays > allocated > by new[] > I can expand the doc a bit. binary_object is just a wrapper around a size and pointer to permit them to be handled as pair. It presumes the pointer already points to allocated storage. It also presumes that the the size of thing its pointing to is the same on save and load. Its very lightweight. I don't see a need for the others, but of course any user can make the wrappers he needs. > -- The library requires exact match between static types for saving and > loading. For example: > > D* d = new D; > ia << d; > B* b = new B; > ia >> b; > ( presume you mean don't mean "new B" as the library creates a new B) > does not work. Moreover, it does not work even if 'D' is > BOOST_CLASS_EXPORT-ed. I'd suggest that this case should work, since it's > very easy to save derived classes using pointer to derived class, without > casting to base class. It doesn't work. Generally saving to one type and loading to another is not supported. In this particular case it could be made to work but it would significantly complicate the library. Also, supporting a practice such as the above, would lead to serialization which is much harder to debug. I don't believe that there is a situation in which doing the above is necessary. The appropriate coding of the above would be: B* b = new D; ia << d; B* b2; ia >> b2; I don't think that's an unreasonable burden. > -- It appears that XML archive require member/variable names in all cases. > I'm > not sure that's reasonable -- given that the library requires exact > correspondence between loading and saving order even for XML archives. It > would load archive back even if I change all the names manually in XML > file > right? Then why requiring names? > > -- I have some concerns about XML archives. The point of XML, in general > is > that it's somewhat readable by humans, and readable by other applications > written using different libraries or in different languages. However, when > I > look at: > > <c2 class_id_reference="1" object_id="_2"> > 10 > <j>4</j> > <base object_id="_3"></base> > </c2> > > it's not clear if any of those benefits are there. This actually > corresponds > to a class "C". To find out this, one has to find "class_id" attribute > with > value of "1" somewhere above. If the above was: > > <C name="c" ...> > > finding all "C" elements would be trivial with XPath, or even with more > simple > methods. As it stands now, even finding all instances of "C" is hard. > There > may be a number of similiar issues. If the goal is to produce XML which > can > be processed by other programs, then at least the class name should become > element name. > Correct, the names aren't used on input. The real question here is what XML is to be used for. Personally I have no use for it. I did it to satisfy boost members who thought it was indispensable. After studying the options in more detail and learning more about it, I'm even more convinced its utility is way over hyped. The question is what should be included in the attribute list. I made my choices and no one has complained. I didn't put anything in there that wasn't necessary for de-serialiation except the name. (Do you think those requiring XML would be satisified if it didn't have the name?). The export class name is included if its necessary. The XML attribute list could be tweaked a little without too much trouble. But it really comes down to what is XML serialization going to be used for besides de-serialization. Until that's answered, I think this will have to remain an open question. As its stands, I looked at, made my choices and hardly anyone has complained. I guess that its probably has limited utility. I think that everyone has assumed that someone else will find it indispensable. BTW, one usage of XML archives did occur to me. By checking the name tag on input, we can implement a crude check that save and load operations are synchronized. This would effectively a debug mode for archives and might be useful. > -- I believe that library should not change codecvt facet of the stream. > There > are two reasons. First, if user has already imbued some facet (say utf-8), > he > might have good reasons to do so (say, he believes utf-8 is the most > space-efficient for his data). So the serializaton library should not > silently change codecvt to ucs-2. Second, the whole locale stuff is > complex, > and it's not even clear if it's possible to change codecvt facet on the > fly, > and when the change will take effect, and so on. I believe requiring user > to > 'imbue' proper facet himself is better than some unexpected internal > effects. > I've wrestled with that. My current thinking is that the system should not be changed. The reason I did this was that I found that the default codecvt on wchar_t files was to narrow the character and throw away the high order bits. Also UTF-8 is need for wchar_t XML. I included the ability to override this by specifying no_codecvt flag upon opening the archive which leaves the codecvt unchanged. So I'm happy with the current method which is to reflects the most common user intention and permits one to suppress this default behavior. I've come to conclude that that the only situation where the codecvt can't be changed on the fly is with the old dinkumware library. I'm still checking for this though. > -- I've tried to play with "implementation level" and created the example > at > > http://zigzag.cs.msu.su:7813/tracking.cpp > > It stores a pointer to a single class with two data members and a single > base > class. I get the following archive content. > > 1 > 1 C > 0 10 4 1 0 > 1 > > Is seems too much for a class with implementation level of "object > serializable". 10 and 4 is the data itself. "1 C" is probably class name, > but > what other data is? The easiest way to verify this is to use an XML archive which labels all the items. Current archives contain no extraneous data (except the name in the XML archive). <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <c class_id="1" class_name="C" object_id="_0"> 10 <j>4</j> <base class_id="0" tracking_level="1" object_id="_1"></base> </c> </boost_serialization> > > ** Implementation issues ** > > -- I suggest that all MPL expressions in the library are refactored for > better > readability. For example, the expression in save_non_pointer_type::invoke > is > 28 lines long. I think it should be possible to extract some of the > subexressions and create a typedef with good name -- looks like I think the indentation is better than creating new names. > instantination of those expression in all cases should not cause compile > errors. Hmm - please expand on this. > > ** Custom archive creation ** > > I've tried to create a custom archive class (in fact, > polymorphic_oarchive), > and got some comments. > > - Documentation says the derived class must provide operator<< and method > 'load'. It also says there common_iarchive::operator<<. I wonder why the > derived class should provide operator<<. Can't base operator call 'load' > directly? > > - Even if not, why derived operator<< should have > > return * This(); > > not plain "return *this"? After all, we're in most derived object > > - It's needed to add > > friend class boost::serialization::load_access; > > to class declaration. However, it's not stated where this type is > declared, > and in fact in declared in *internal* header I wasn't aware that such a friend class had to be declared. Recently one compiler has flagged with a warning which is annoying. So, we'll look at this if only to suppress a benign warning. > > boost/archive/detail/iserializer.hpp > > And, finally, the right syntax seems to be: > > friend class boost::archive::load_access; > > (Note the namespace!) > Hmm - I don't see that this is required given that its be called from within boost::archive::detail. Does any compiler complain? > - The example uses: > > boost::serialization::load(* This(), t); > > Again, what header is this function in? The answer is that it's in the > same > header as above, and the line should be: > > boost::archive::load(* This(), t); > Correct thanks. > - The documentation should really state the minimal set of 'load'/'save' > overloads which will make archive usable. For example, it's probably not > necessary to provide separate overload for 'bool', right? The document states: " However, we're not quite done. The above code addresses serialization of all non-primitive types. To be complete, each primitive type must either be covered by a definition of template<typename T> void load(T & t); or an overload of the >> operator" And " If all primitive types have been accounted for, any program with serialization defined should work with the new archive." Maybe I can expand upon that a little to something like: "Any program with serialization defined should work with the new archive as long as every primitive type has a matching save/load function prototype or template." The trivial_?archive include the "fall-through" template that matches any primitive type - including bool. For example, the "fall-through" for text_oarchive is Void load(T &t){ os >> t; } Which covers all primitive types. > - (critical) It should be explained how the newly-created class can be > tested. > As it stands, one should either do superficial tests or try to integrate > the > new archive into existing tests. As for latter -- I don't know how to do > that, and also, I think it's not necessary to run all the tests with the > new > archive. For example, serialization of vector and map is not likely to be > broken with the new type. What I'm looking for is a test which saves/loads > all possible types and verifies results. > I've concluded this myself. Its pretty easy given the bjam setup. Maybe it can be made even easier with a bjam argument or environmental variable. It just needs to be explained. The easiest is to just run all the tests - for one archive it probably takes less than 30 minutes and its fairly exhaustive. So its not worth trying to figure out a way to abbreviate the test. (Not to mention the fact that the test I skip is always the one that catches me). In some situations the brain-dead way is really the best way. > ** Various comments ** > > -- The BOOST_CLASS_EXPORT macros defines an explicit instantiation of a > function. gcc rejests this when BOOST_CLASS_EXPORT is used inside some > namespace. I've asked on comp.std.c++: > > http://groups.google.com/groups?q=Explicit+instantiation&hl=en&lr=&ie=UTF- > 8&safe=off&selm=u5boi1-7te.ln1% > 40zigzag.lvk.cs.msu.su&rnum=3 > > and got a reply directing me to: > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#275 > > Which means gcc is mostly right. So, the macro should either be changed > somehow, or at least the restriction should bes documented -- using > BOOST_CLASS_EXPORT outside of any namespaces is OK. > I'll add language reminding users that ALL these macros have to be invoked outside of any name space. Hmmm > -- Docs and code use "const unsigned long int version" everywhere. Is that > really necessary, as opposed to "unsigned version"? That's been fixed. I'm not sure you have version # 18. > > -- The library saves char* as arrays of integers. The rationale section > says: > > input of char * and wchar_t * could be altered to create a buffer > overrun > and potential security problem. > > I don't understand this point at all. How storing the elements as integer > values helps with the buffer overrun? Moreover, library stores char* > internally (e.g. for archive signature). What if that string is modified? > Will that cause buffer overrun? The manual is wrong. I'll fix it. I commented out the code that serializaed (char *) and (wchar_t *) as strings. I was concerned about buffer overrun security problems. I don't remember my reasoning for this right now but I don't think implemention char * serialization as a primitive type is a good idea. > > -- The following program (yes, of two lines), causes a compile error: > > #include <boost/archive/text_oarchive.hpp> > #include <boost/serialization/export.hpp> Not on my machine. So I guess I fixed it. Whoops, fails on gcc - so I've fixed with a forward template declaration. Robert Ramey

3 3

program_options suggestion
by Neal D. Becker 21 Apr '04

21 Apr '04

I really like program_options from Vladimir Prus. Thanks for adding bool_switch! One suggestion. We now have bool_switch, so a variable can default to off, and turn on with --option (without having to say --option=true). How about begin able to say --no-option to turn it off? This would make the interface consistent with gnu standards. If it's not too difficult it would make a good addition.

2 1

Re: Re:[boost] Formal review: serialization
by Robert Ramey 21 Apr '04

21 Apr '04

I just realized I skipped something Vladimir Prus wrote: > > ** Custom archive creation ** > > I've tried to create a custom archive class (in fact, > polymorphic_oarchive), > and got some comments. > > - Documentation says the derived class must provide operator<< and method > 'load'. It also says there common_iarchive::operator<<. I wonder why the > derived class should provide operator<<. Can't base operator call 'load' > directly? > common_iarchive has no operator<< 'load' is called by the library to load primitives - its generally not called by the << operator unless one wants to bypass the serialization system entirely. Perhaps, my usage of load_override was confusion. I use load_override in order to work around the lack of partial template function ordering. Were it not for this, load_override would not exist. This is an implementation artifact. Load on the other hand is the function used to load primitives. > - Even if not, why derived operator<< should have > > return * This(); > > not plain "return *this"? After all, we're in most derived object > No we are not. The class hierarchy is common_iarchive base_text_oarchive text_oarchive_impl text_oarchive in my archives, the operator<< is a member of base_text_oarchive. If I want the << operator to return a reference to a text_oarchive NOT basae_text_oarchive. The archives included are models of the trivial_archive. However, the desire to factor things out in a convenient way makes them less transparent than I would prefer. Robert Ramey

1 0

Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 21 Apr '04

21 Apr '04

Matthew Vogt wrote: >Robert Ramey <ramey <at> rrsd.com> writes: >> Correct. That's exactly what the current implementations of STL classes >> do. So my question is why override vector for you xdr/cdr archives? > Primarily, because the implementation you have chosen for default > serialization of STL containers is just an implementation detail from your > point of view; you could quite reasonably change it in the next version, > if someone with alternate requirements requested that, and it didn't > conflict with your own purposes. OTOH, XDR and CDR mandate how sequences > should appear in a stream, so it is necessary to ensure that the default > implementation is not relied upon for conformance. OK, but then why not just delay the effort until the underlying implementation actually changes? > Another reason, is that other formats will vary the implementation in > minor ways - by using a preceding length field in 8-bit signed format, for > example. I believe this could be addressed without too much trouble - perhaps by making a special type (a strong type) to hold collection count and tweaking collection implementation to use it. So it could then be implemented to taste on each kind of archive. >> I would like to see your xdr/cdr archives finished off at the same >> level of generality as the other archives. Any special purpose >> marshalling would leverage off that. > I don' think this is possible, since these formats do not specify > Sufficient types to do so. The library maps an arbitrary C++ data structure to a sequence of C++ primitives and back again. Any format that can handle all C++ primitives can therefore be used to serialize any C++ data structure. I'm sure that XDR/CDR can represent any C++ primitive data type. Hence, XDR/CDR can be used to serialize any C++ data structures with this library. > It would be possible to allow type promotion > to cover some missing types - for example, in XDR, it would be possible to > allow all C++ integral types less than 32-bits to be promoted to 32-bits > during serialization, but I think this would be misleading. Misleading? > More problematically, there is no concept of objects in this situation. Of course at the archive level you only see a string of numbers. It's the serialization that recovers C++ objects from all of this. > It wouldn't make sense to transmit objects via pointers, since 'the other > side' will never reconstitute objects. Perhaps this is a source of confusion. It never occurred to me that the other side wouldn't have the mirror serialization code. That is of you're using xdr_oarchive to make the stream I assumed you would use xdr_iarchive on the other side to recover the data. Even if you don't anticipate the need for doing this yourself, other users will and they will want the universal coverage that the current system provides. I wager that if you tell users on this this list - "Oh the XDR archive is special, it's just for marshalling, you can't do objects with XDR" you'll get an earful. And its not necessary to subject oneself to this kind of grief. It's much less work to provide for every C++ primitive data type and know that any serialization is always going to work than it is to try to anticipate ahead of time for just those combinations of features users are going to actually use. If you want a "restricted" or special purpose xdr archive that prohibits pointers or something else in order to conform to some other program not built with this library, you can just derive from the simple general one and overload the prohibited operations with compile-time assertions. Robert Ramey

3 2

a question about "typeof"
by Arkadiy Vertleyb 21 Apr '04

21 Apr '04

Hi all, A couple of questions regarding typeof: 1) Is it going to be in the next C++ standard? 2) Is there any estimate when it is going to happen? I assume that quite a few Boost libraries could largely benefit from this operator. Spirit documentation even contains a section on typeof and how the syntax could be improved with it. I recently had a need to determine a type of a Lambda functor (but got away with Boost.Function with some performance expences). Also Joaquin recently raised a similar question. Our RTL syntax would also benefit a lot if this facility was available. About one and a half year ago Steve Dewhurst published three articles on this subject in CUJ. The idea was to encode the type as an integer using bitwise operations. This integer could be than "returned" from the function, this crossing the boundaries between a type and a value, and then decoded into the original type. I wonder if this or any other technique is currently being considered by anyone to be added to Boost or we are just waiting until the real typeof is available? I have been experimenting with this, and came up with a very simple trick that allows to use a static list of integers, like mpl::vector_c, instead of bitwise operations, to encode the type, and pass this list across the function boundaries. I think, if nothing else, this is much simpler than bitwise operations. Everything else is pretty much like in Steve's approach. Based on this it seems to be pretty simple to encode/decode types to implement typeof-like facilities for some specific (or maybe not so specific) cases. Has anybody already done something similar, and/or is this of any interest? If there is an interest I am ready to provide explanation, code, etc. Regards, Arkadiy

5 5

gcc-3.4 release imminent
by Neal D. Becker 21 Apr '04

21 Apr '04

gcc-3.4 is now frozen. I wonder if anyone is testing boost compat? I have tried compiling some of my code using gcc version 3.4.0 20040327 (Red Hat Linux 3.4.0-0.9). There are usually a LOT of errors. gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda. Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available

5 7

Re: [boost] Re: serialization: review
by Robert Ramey 21 Apr '04

21 Apr '04

Thorsten Ottosen wrote: > Robert Ramey wrote:(> |) > | I don't understand the need for this. Given that mammal is an abstract > | base class with no state variables of its own, it needs no serialization > | at all. > Ok, but could I have implemented it by having just one function in the > abstract base class which seriaized by calling virtual functions, eg, > name() and age()? I believe you could. In fact I believe that in some cases not yet encountered ( runtime plug-ins ) it will be necessary. This is still an unresolved area > | Just declare it as abstract using BOOST_IS_ABSTRACT(mammal). Only the > | serialization of the derived classes need be specified. > Can BOOST_IS_ABSTRACT be avoided? Maybe some type-traits can figure this > out? Is_abstract is in the new type traits. It fails on lots of compilers. Also it was in a state of flux at the time of the release of 1.31. I expect that a) is_abstract get fixed up best it can b) and have an implementation that is benign for compilers that don't support it c) and that we'll continue to specialize it for serialization code that needs to be compiled on less-conforming compilers. (this is all BOOST_IS_ABSTRACT does.) In > struct whale : public mammal > { > friend class boost::serialization::access; > whale(); > whale( const std::string& name, unsigned age ); > virtual const std::string& name() const; > virtual unsigned age() const; > private: > template<class Archive> > void serialize(Archive &ar, const unsigned int version){ > ar & boost::serialization::base_object<mammal>(*this); > ar & name_ & age_ ; > } > std::string name_; > unsigned age_; > }; > can the line "ar & boost::serialization::base_object<mammal>( *this )" > be put in a base-class like this > mammal::serialize( Archive& ar, unsigned version ) { > ar & boost::serialization::base_object<mammal>(*this); > do_serialize( ar, version ); > // virtual function that does the rest > } > to remove some redundancy? The intention of base_object is really to cast to the base class (and register the base/derived relationship). So it its out of place here. The real issue is do_serialize. Is that supposed to be a virtual function? With a templated argument? Maybe you want to consider this question a little bit more. > | I would love to hear more about this. I would hope that it would easy > | to be totally successful. > it is now given you showed me how :-) In effect, once the container > supports serialization, a class can be supported in four lines. If you > have not got an example of class hierarchies, then maybe it should be > added. The tutorial contains an example essentially identical to your mammals, whales and apes example. Under case studies there's a discussion of the implementation of serialization for shared_ptr which is almost exactly analogous to your vector_ptr case. Also, there some discussion in the documentation regarding serializaition of templates. > | > I would like to see the focus shift from vector<T*> towards vector< > | > shared_ptr<T> > and ptr_vector<T>. using T* array[sz] or vector<T*> > | > is inherently unsafe if the pointers are heap-allocated. > | > | I believe that enforcing this is outside my role as a library creator. > ok, but I think you at least should point out very clearly the problems in > it. Some non-experienced programmer might do what he sees in > documentation; therefore examples should encourage good style. Well, here is one programmer that needs to be better sold on this. Honestly, I don't think the serialization tutorial is the place to do it. > | 3. const members uses a const-cast to re-init them. AFAICT, this is > | undefined behavior (cmp 7.1.5.1). I guess the need for serialization > | is just another reason for not having const members. Hmmm - what does re-init mean in this context? > | > this has come up from time to time. I've tried to promote the view > | > that const members shouldn't be serialized but I couldn't convince > | > everyone. > | > I consider it outside my role as a library developer to try to > | > enforce this. > my point was that the examples given give undefined behavior so that > solution cannot be used. Which example gives undefined behavior? > no, but maybe with this > | stl::archive_input_seq<Archive, std::vector>, > | stl::reserve_imp<std::vector> > by arranging the order of the template parameters. > | Isn't a little bit of redundancy OK giving the alternative of having > | to keep the details of deducibility in one's brain? > but you already know the types that will be deduced from the outer > function. OK, could we agree to disagree on this and forget about it? > | > 18. implementation of save_collection(). you cannot use unsigned int > | > count portably. > | > | I don't see this. > | > | > Instead you should use the new collection traits (reviewed after > | > this review) as follows: > | > | > typename boost::size_type_of< Collection >::type count = size( s ); > | > | > then the code will also work for iterator views and arrays. Similar > | > comments apply to load_collection_impl.hpp > | > | I wanted to make the library buildable under 1.31 . > ok, then do > typename Collection::size_type count = s.size(); > but don't assume Collection::size_type will be unsigned int. I'm not assuming that. I'm assuming that it will be convertible to an unsigned int and that an unsigned int will be large enough to hold any number of elements in an collection. Of course THAT might be rash assumption. BTW where is the namespace Collection defined in 1.31 ? Robert Ramey

2 1

RE: [boost] Re: date-generators (was Date-Time)
by Hurd, Matthew 20 Apr '04

20 Apr '04

> Jeff Garland > > > Cyrille Dupuydauby wrote > > Totally agree with that, business related apps need > holidays and business > > days. But holidays determination should be easily localizable. > > It isn't just by locale, the application needs to determine > holidays. For > example, while there are some holidays in the US that > everyone agrees on, but > lots of companies use a couple floating holidays every year. > They typically > will tack one say a Friday after a July 4th on a Thursday to > give employees a > 4 day weekend. So any calculation of business days needs to > be capable of > handling these application specific cases. Yep. And just to emphasise the point you just made... Some jurisdications might have a business day with respect to some activity but not others. For example, an exchange might have a trading day but not a settlement day. A foreign exchange contract might be written in NY effective on a Sydney holiday but the settlement date might depend on the union of holidays between Sydney and NY. All this indicates is that a calendar can be completely arbitrary and that different calendars can apply to the same business at the same point in time for the same jurisdiction for different parts of the same transaction. Like me, the world has warts ;-) Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] Re: Date-Time
by Powell, Gary 20 Apr '04

20 Apr '04

>Ummm, OK, you made it work, but why? Why would you want to be >able to call add_month() on a date and have it always represent >the day before the last day of the month? date d = August 30; // add six months. add_month(d); // September 30; add_month(d); // October 31? add_month(d); // November 30 add_month(d); // December 31? add_month(d); // January 30 add_month(d); // February 28/29 add_month(d); // March 28? 29? 30? 31? Just looking this there is no way to predict which day of the month the last call is going to be. I'd find it surprising that (d + year) != (12 * months) + d; I think you are looking for a simplistic function for a complex problem. IMO its a trap for the unwary and should be called out as such. I can see the need for LAST, but my contention is that its not enough information to do the least surprising thing. The easiest way to resolve this is to either write a FAQ, and or have a dumb rounding month adding function that can screw up the dates for those times when "meet you next month" is the right answer. Yours, -Gary-

4 9

Re: numeric_cast
by Dill, John 20 Apr '04

20 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > char schar_value = 0; > > > > try { > > schar_value = boost::numeric_cast<char>( uchar_max ); > > } > > catch ( boost::bad_numeric_cast ) > > { std::cout << "Overflow occurred..." << std::endl; } > > > > When I execute this sample, I don't get the exception. What's > > the background on this behavior? I'm using gcc 3.3.1. > > Your char is unsigned. I'd like to know why conceptually the exception isn't thrown. Why is it beneficial to have unsigned T to signed T overflows not be detected? It is not just char, but short, int, and long as well. If this was the intended behavior, then what is the reasoning behind it? Thanks, John

2 1

Re:Re: Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 20 Apr '04

20 Apr '04

Ralf W. Grosse-Kunstleve wrote: > FWIW: For the serialization of C++ arrays wrapped as Python objects (via > Python's pickle) I implemented a small "library" (it really is just one > header file) for converting integers and floating-point numbers to a > pseudo text format. In principle it works just like the conversion to > base-10 numbers, but uses base-256 instead. I.e. the result looks like a > binary format, but it is as machine-independent as a text format. The > serialized strings are smaller than regular text format, but larger than > raw binary format. > Integers are serialized like this: > NXX...X ... This is interesting. I made an example as part of the library called:demo_portable_binary or which attempted to handle issues such as endianness and size. I bailed at floating point because of the concern for handling things like conversion between 80 bit IEEE float and 64 proprietary floats. And then I was just making as sketch to inspire someone to implement XDR which I presumed had some sort of way of handling this. (I still don't know how other formats handle this) I like your method. I may steal it yet. Robert Ramey

1 0

Re: Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 20 Apr '04

20 Apr '04

> Ralf W. Grosse-Kunstleve wrote: > Interesting. If I serialize and deserialize std::vector<double> as a text > archive but on the same machine, will I always get back exactly the same > bit patterns for the double values? The text archive uses a stream manipulator to set the precision of the output to capture all the precision in the double. It uses the numeric<limits> to determine this. So I can't say it will be exactly the same bit stream but it will be close to the original number. If you want to guarantee the exact representation you can either use the included native binary archive or serialize the data element (double) as a (non-portable) binary object. Robert Ramey

2 1

Re:Re: [boost] Re: Re: Serialization Formal Review #2
by Robert Ramey 20 Apr '04

20 Apr '04

Matthias Troyer >On Apr 17, 2004, at 8:13 AM, Robert Ramey wrote: >> Matthias Troyer wrote: >>> 2. which functions do I need to implement in my archive class to skip >>> writing the standard preamble that your archives write? Is it just >>> the init function or are there more functions? >> >> Depending on the implementation traits for each class, there may be a >> preamble written by the serialization library. This contains >> information such as version number, class id info, perhaps export key, >> etc required by the s library to reconstruct a faithful reproduction >> of the original data. >> If there is a preamble, there is no information in that can be >> discarded and still reproduce the original data. >I was wondering about the preamble written at the start of the archive, not >the per-class information. An archive preamble is entirely optional. The common_?archive base class includes the init function which all the included archives call in their constructor. There is no requirement to call this function however in the constructors of your own archives. Robert Ramey

1 0

Formal review: serialization
by Vladimir Prus 20 Apr '04

20 Apr '04

Here's my review of the library. It's based on reading docs and source for several hours, as well as using almost every previous version of the library on my project. I think the library should be accepted. I voted "no" the previous time, but I think library was considerably improved. I'd also like to thank Robert for pushing this effort forward! Detailed comments are below. Some of them are marked as "critical" -- it means I believe they should be addressed before the library is added to official distribution. ** General issues ** -- (critical) The primary issue with the library is lack of reference documentation -- exact description of semantics for every method (preferrable in C++ std style) and overview for all important classes. The library is non-trivial, and without such documentation user will have to experiment to find out that exact semantic. Better internal docs (comments) are also needed. For example, I'm looking at save_access::end_preamble and don't know what it does. Comment for basic_oarchive::end_preamble says what this method is for, but does not say when this method is called, which makes it hard to do anything. Again, implementation is non-trivial. Lack of comments make it somewhat dangerous to use the library -- if I hit a bug while Robert is on vacation, I'm not sure I'll be able to quickly fix it locally. As an illustraction, I've already had a couple of bugs each costing several hours to debug. -- (critical) While BOOST_CLASS_EXPORT is a big step forward, I think it can be further improved. Now, if I export a class I need to include some archive headers before invoking BOOST_CLASS_EXPORT. The class can be only serialized to archives which were included. This means that to really export a class, I need to include *all* archive headers. That's not good. What I suggest is - create new class 'polymorphic_archive', which will have virtual functions for saving/loading and create templated 'polymorphic_wrapper', which can be used to add this polymorphic interface to existing archive. - always register all exported classes with polymorphic archive. When serializing in a specific archive, check if class is registered with that archive. If not, serialize it via polymprphic wrapper. In fact, I'd be willing to help with polymorphic archive implementation, but some changes inside serialization library will be required. -- (critical) I suspect BOOST_CLASS_EXPORT does not play nice with templates. Say I'm implementing RPC system: class function_call_base { virtual ~function_call_base() {} } ; template<class Arg> class function_call1 : public function_call_base {}; // in some code rpc_server s; s.register("foo", &foo); function_call_base* c; while(archive >> c) (*c)(); The idea is the caller will serialize instances of function_call1 and the callee will deserialize it and call the proper function. To make this work, we have to BOOST_CLASS_EXPORT all used instantinations of function_call1. We can assume that all functions (and therefore all argument types) are passed to the 'register' function and can function can invoke BOOST_CLASS_EXPORT. Now the problem: BOOST_CLASS_EXPORT can be used only at top-level of a translation unit. There's not way 'register' and automatically export a class. The solution I'd like is: template<class T> class export_class { public: static void instantiate(); }; So that the object of this type can be created anywhere. -- One usage of the serialization library I have in mind is taking "debug dumps" for an application. After the run, a separate tool can be used to look at those dumps. The size of data can potentially be rather large (e.g. 100*640*480 or maybe more), so I'd rather not to load all data, but build some index. So the question is: how is it possible to access specific part of archive without reading it all. I understand it's not possible in general, but in some cases (e.g. BOOST_CLASS_EXPORT for everything) it should work. -- The documentation of 'make_binary_object' is very incomplete and does not tell the exact semantic. As far as I can tell, the function can be only used to load/store objects which have fixed size and will crash when saving/loading new[]-d array -- which seemed an obvious use-case for me. I would suggest that we have two functions: make_pod_wrapper -- which is templated, has one parameter -- object, and stores sizeof(T) bytes. Another name -- make_static_array_wrapper. make_dynarray_wrapper -- which can be used to store/load arrays allocated by new[] -- The library requires exact match between static types for saving and loading. For example: D* d = new D; ia << d; B* b = new B; ia >> b; does not work. Moreover, it does not work even if 'D' is BOOST_CLASS_EXPORT-ed. I'd suggest that this case should work, since it's very easy to save derived classes using pointer to derived class, without casting to base class. -- It appears that XML archive require member/variable names in all cases. I'm not sure that's reasonable -- given that the library requires exact correspondence between loading and saving order even for XML archives. It would load archive back even if I change all the names manually in XML file right? Then why requiring names? -- I have some concerns about XML archives. The point of XML, in general is that it's somewhat readable by humans, and readable by other applications written using different libraries or in different languages. However, when I look at: <c2 class_id_reference="1" object_id="_2"> 10 <j>4</j> <base object_id="_3"></base> </c2> it's not clear if any of those benefits are there. This actually corresponds to a class "C". To find out this, one has to find "class_id" attribute with value of "1" somewhere above. If the above was: <C name="c" ...> finding all "C" elements would be trivial with XPath, or even with more simple methods. As it stands now, even finding all instances of "C" is hard. There may be a number of similiar issues. If the goal is to produce XML which can be processed by other programs, then at least the class name should become element name. -- I believe that library should not change codecvt facet of the stream. There are two reasons. First, if user has already imbued some facet (say utf-8), he might have good reasons to do so (say, he believes utf-8 is the most space-efficient for his data). So the serializaton library should not silently change codecvt to ucs-2. Second, the whole locale stuff is complex, and it's not even clear if it's possible to change codecvt facet on the fly, and when the change will take effect, and so on. I believe requiring user to 'imbue' proper facet himself is better than some unexpected internal effects. -- I've tried to play with "implementation level" and created the example at http://zigzag.cs.msu.su:7813/tracking.cpp It stores a pointer to a single class with two data members and a single base class. I get the following archive content. 1 1 C 0 10 4 1 0 1 Is seems too much for a class with implementation level of "object serializable". 10 and 4 is the data itself. "1 C" is probably class name, but what other data is? ** Implementation issues ** -- I suggest that all MPL expressions in the library are refactored for better readability. For example, the expression in save_non_pointer_type::invoke is 28 lines long. I think it should be possible to extract some of the subexressions and create a typedef with good name -- looks like instantination of those expression in all cases should not cause compile errors. ** Custom archive creation ** I've tried to create a custom archive class (in fact, polymorphic_oarchive), and got some comments. - Documentation says the derived class must provide operator<< and method 'load'. It also says there common_iarchive::operator<<. I wonder why the derived class should provide operator<<. Can't base operator call 'load' directly? - Even if not, why derived operator<< should have return * This(); not plain "return *this"? After all, we're in most derived object - It's needed to add friend class boost::serialization::load_access; to class declaration. However, it's not stated where this type is declared, and in fact in declared in *internal* header boost/archive/detail/iserializer.hpp And, finally, the right syntax seems to be: friend class boost::archive::load_access; (Note the namespace!) - The example uses: boost::serialization::load(* This(), t); Again, what header is this function in? The answer is that it's in the same header as above, and the line should be: boost::archive::load(* This(), t); - The documentation should really state the minimal set of 'load'/'save' overloads which will make archive usable. For example, it's probably not necessary to provide separate overload for 'bool', right? - (critical) It should be explained how the newly-created class can be tested. As it stands, one should either do superficial tests or try to integrate the new archive into existing tests. As for latter -- I don't know how to do that, and also, I think it's not necessary to run all the tests with the new archive. For example, serialization of vector and map is not likely to be broken with the new type. What I'm looking for is a test which saves/loads all possible types and verifies results. ** Various comments ** -- The BOOST_CLASS_EXPORT macros defines an explicit instantiation of a function. gcc rejests this when BOOST_CLASS_EXPORT is used inside some namespace. I've asked on comp.std.c++: http://groups.google.com/groups?q=Explicit+instantiation&hl=en&lr=&ie=UTF-8… 40zigzag.lvk.cs.msu.su&rnum=3 and got a reply directing me to: http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#275 Which means gcc is mostly right. So, the macro should either be changed somehow, or at least the restriction should bes documented -- using BOOST_CLASS_EXPORT outside of any namespaces is OK. -- Docs and code use "const unsigned long int version" everywhere. Is that really necessary, as opposed to "unsigned version"? -- The library saves char* as arrays of integers. The rationale section says: input of char * and wchar_t * could be altered to create a buffer overrun and potential security problem. I don't understand this point at all. How storing the elements as integer values helps with the buffer overrun? Moreover, library stores char* internally (e.g. for archive signature). What if that string is modified? Will that cause buffer overrun? -- The following program (yes, of two lines), causes a compile error: #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/export.hpp> It's because export.hpp uses 'instantiate_pointer_iserializer' but does not include the header where that class is defined. 'text_oarchive.hpp' does not include it either. The error goes away if I include #include <boost/archive/text_iarchive.hpp> but a better diagnostic is desirable. - Volodya

1 0