- Boost - lists.boost.org

Re: Re: Serialization Formal Review #2
by Robert Ramey 19 Apr '04

19 Apr '04

Matthias Troyer wrote: > I have two more questions regarding the serialization library which I > need to have answered before I can see if I can read my old archives > with your library: > 1. when overloading the save/load functions in an archive, do I bypass > writing preambles and other class information or do I need to overload > operator <<? What is the difference between implementing operator<< and > save? > 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. In general it can't be guaranteed that one can read an arbitrary file format created independently of the serialization library. With the serialization library, it's the class/instance structure that drives the file format rather than the other way around. To transition to use the serialization library the strategy would be: a) add serialization to the classes desired. b) write a program which reads the "old" data files using the "old" method - whatever that might be. c) invoke serialization to save in the desired new format. The old data files should no longer be necessary. Best regards Matthias

2 1

Re: [boost] a note on serialization docs
by Robert Ramey 19 Apr '04

19 Apr '04

David Abrahams wrote: > When viewing [boost] a note on serialization docs > http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, > the right ends of some of the words are tucked underneath the > scrollbar at the right of the window. The HTML or stylesheet should > have some kind of margin to prevent this effect. This annoys me also. Even worse is thie fact that some lines don't break. I've toyed around with this but haven't found the fix. Its especially odd to me given that it imports the style.css from the boost directory but other pages don't show this behavior. I believe its some MSIE quirk. If anyone knows how to address this I'm all ears. Robert Ramey

1 0

static sized strings
by Reece Dunn 19 Apr '04

19 Apr '04

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: nstring< 20 > s; s.copy( "Hello World!" ) if( s == "Hello" ) ... // note: this will succeed! This is useful for things like processing file format headers, as it allows things like: struct tar_header { nstring< 100 > name; ... nstring< 8 > magic; ... }; if( hdr.magic == "ustar\x20\x20\0" ) // GNU TAR archive ... else if( hdr.magic == "ustar\0" ) // POSIX TAR archive ... else // invalid format I also have a formatter class that provides buffer-safe printf-like operations on the constructor and as a functor, e.g.: formatter< 512 > fmt( "%s: %s", type, msg ); std::cout << fmt << '\n'; std::cout << fmt( "error: %s", msg ) << '\n'; This can be useful when you need to format a string without making use of a string buffer, e.g.: std::ostringstream fmt; fmt << type << ": " << msg; std::cout << fmt.str() << '\n'; fmt.str( std::string()); // clear string buffer fmt << "error: " << msg; std::cout << fmt.str() << '\n'; Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

[thread] again ;)
by John Torjo 19 Apr '04

19 Apr '04

Dear boosters, As far as I've heard a while back, the only reason [thread] library cannot be built as a static library was because of TSS. That to me (and to others as I've seen) seems quite a show-stopper - in a lot of apps I don't use the [thread] lib just because of this. Most of my multi-threaded applications (around 95%) and as I know a lot of other multi-threaded apps. don't need TSS. Even if they do, usually they don't need advanced clean-up code (reason for why [thread] was required to be a DLL). ***Most*** of the time, any allocated TSS objects can be let to leak resources (which they hardly have - mostly IMHO some small amount of allocated memory). The above make me think that we really should enable [thread] to be a static library again ;). It should be documented in the docs that the static version of the [thread] runtime will leak TSS objects, and users can choose whether they will use [thread] as a DLL or as a runtime static lib. What do others think? As a side-note, allowing the [thread] lib to be a static lib is quite simple (please you gurus out there, correct me if I'm wrong). In fact, here's the patch. (note: config.hpp = boost/thread/detail/config.hpp, and I did not modify the jamfile.V2, since I can't test it) Best, John // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP #define BOOST_THREAD_CONFIG_WEK01032003_HPP #include <boost/config.hpp> // insist on threading support being available: #include <boost/config/requires_threads.hpp> #if defined(BOOST_HAS_WINTHREADS) # if defined(BOOST_THREAD_BUILD_DLL) # define BOOST_THREAD_DECL __declspec(dllexport) # elif defined(BOOST_DYN_LINK) // john.torjo # define BOOST_THREAD_DECL __declspec(dllimport) # else # define BOOST_THREAD_DECL // linking to library # endif #else # define BOOST_THREAD_DECL #endif // BOOST_HAS_WINTHREADS // john.torjo /* // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_thread // // If we're importing code from a dll, then tell auto_link.hpp about it: // # define BOOST_DYN_LINK // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled */ #endif // BOOST_THREAD_CONFIG_WEK1032003_HPP # Copyright (C) 2001-2003 # William E. Kempf # # Permission to use, copy, modify, distribute and sell this software # and its documentation for any purpose is hereby granted without fee, # provided that the above copyright notice appear in all copies and # that both that copyright notice and this permission notice appear # in supporting documentation. William E. Kempf makes no representations # about the suitability of this software for any purpose. # It is provided "as is" without express or implied warranty. # # Boost.Threads build Jamfile # # Additional configuration variables used: # 1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32 # library should be used instead of "native" threads. This feature is # mostly used for testing and it's generally recommended you use the # native threading libraries instead. PTW32 should be set to be a list # of two strings, the first specifying the installation path of the # pthreads-win32 library and the second specifying which library # variant to link against (see the pthreads-win32 documentation). # Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib" # Declare the location of this subproject relative to the root. subproject libs/thread/build ; # Include threads.jam for Boost.Threads global build information. # This greatly simplifies the Jam code needed to configure the build # for the various Win32 build types. import ./threads ; { template thread_libs ## sources ## : <template>thread_base ## requirements ## : <sysinclude>$(BOOST_ROOT) ## default build ## : ; # Base names of the source files for libboost_thread. CPP_SOURCES = condition mutex recursive_mutex thread tss xtime once exceptions barrier threadmon ; lib boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <runtime-link>static # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; dll boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <define>BOOST_THREAD_BUILD_DLL=1 <runtime-link>dynamic # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; stage bin-stage : <dll>boost_thread <lib>boost_thread #: <tag><debug>"d" : debug release ; install thread lib : <dll>boost_thread <lib>boost_thread ; }

3 6

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

19 Apr '04

Jeff Garland wrote: > I believe that Matthew has now demonstrated that archive extension is > possible, which I believe is one of the major changes from the first > review. That said, any documentation of this process would clearly be a > plus. In a typical proprietary archives writing of the version and type > numbers will need to be shut off. So I can imagine documenting these > sorts of issues. As it turns out, type id, and object id are really required only for pointers and version is in fact optional. It would be possible to make an archive which: a) trapped (BOOST_STATIC_ASSERT) attempts to serialize a pointer b) trapped attempt to save/load object id and class id c) implemented null serialization of version numbers and trapped attempts to use version number != 0 This would work only on serializations that had implementation attributes of no versioning, and no object tracking. If used on other types, it would trap at compiler time. I believe that you would have what you wanted. In general, the part of the library which saves/loads the preamble is invoked only for pointers. An easy way to check this is to generate XML archive and find that there are not attributes for this types. Robert Ramey

2 1

a note on serialization docs
by David Abrahams 19 Apr '04

19 Apr '04

When viewing http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, the right ends of some of the words are tucked underneath the scrollbar at the right of the window. The HTML or stylesheet should have some kind of margin to prevent this effect. Cheers, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 1

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

19 Apr '04

> Jeff Garland writes: > Yes, for 'random access' archives (think relational database buffer here) > it's possible the archive process will need additional meta-data not > provided in the base library setup (think mapping of classes to tables and > attributes to columns). And yes, I've implemented this one before as well > -- it's a very handy bit of infrastructure. > but in fact I believe given the current library it could now > be done by writing and archive and perhaps some enhancements to the > registration. I faced the same problem with XML meta-data. I resolved with the NVP wrapper which kept XML out of the library core - really a big thing for me as I have had to continually refactor to keep things from growing totally out of control. I'm sure this idea of making a wrapper which includes meta-data along with the data itself is going to be useful in cases like this. > I think in the past Robert has considered this "out of scope", Well, yes. I have fought a continuing battle to limit scope. > BTW, I think the references should include a reference to this paper which > discusses many of these variations and design issues. > http://www.ubilab.org/publications/print_versions/pdf/plop-96-serializer.pdf I've seen this paper, and at this suggestion was made before. I think I included a reference to it but the link moved. There's another whole field to plow regarding web references as opposed to published ones. Robert Ramey

1 0

move semantics
by Andrea Torsello 19 Apr '04

19 Apr '04

Hi, I have been investigating move semantics and think that I came up with a solution that is strongly influenced by both David Abrahams' move approach and Andrei Alexandrescu's mojo, but solves some of the problems I have encountered with them. The basic idea is to use the explicit keyword to force the compiler to use the X(X const &) constructor only in two cases. 1) When explicitly copying a const object i.e. X const x; X y(x); //use explicit copy constructor 2) When passing by const ref void f(X const &); X makeX(); void foo() { f(makeX()); //use explicit copy constructor } In all other cases the other constructor take precedence. Note that the template trick David Abrahams uses in his move approach would lead to an error on a conforming compiler when confronted with case #2 (unless more recent versions corrected this). I chose to keep the temporary and constant subtypes from mojo because they allow me to discriminate between const values, non-const rvalues and non-const rvalues. The lack of this capability was the major problem I had with David Abrahams' move. My use-case was a vector-like container that increases but never decreases the size of its backing store. In order to provide the never decreasing backing-store semantic, operator = moves the backing store from a temporary only if the new data does not fit in the existing space. Hence, operator = must be able to discriminate between temporaries and non-temporaries. My solution fullfills almost all the requirements I had: 1) passing by value moves non-const rvalues and copies everithing else. 2) its is transparent to the user of the class. Alexandrescu's Mojo fails this because of the special return type, while Abrahams' move fails it because of the pass-by-const-ref problem described above. 3) it allows to discriminate between constants, non-const lvalues, and non-const rvalues. Alexandrescu's Mojo allows it, while Abrahams' move does not. 4) Provides move semantics to templated classes with (almost) no odd side-effect. The only side-effect is that template type deduction does not work with temporary discrimination. Hence in the sample code the template type of the "discriminate" function must be specified explicitly. please find attached a sample file illustrating my move approach. I tested the code with gcc 3.3.1 and successfully compiled it with comeau online. What do you think? Andrea Torsello P.S. please cc me as I am not subscribed and I check the mailinglist archives sporadically begin 666 move_test.cc M(VEN8VQU9&4\:6]S=')E86T^#0H-"@T*=7-I;F<@<W1D.CIC;W5T.PT*=7-I M;F<@<W1D.CIE;F1L.PT*#0IN86UE<W!A8V4@;6]V90T*>PT*"71E;7!L871E M(#QC;&%S<R!4/B!S=')U8W0@96YA8FQE9 T*"7L-"@D)8VQA<W,@8V]N<W1A M;G0@+R\@='EP92!S=6=A<B!F;W(@8V]N<W1A;G1S#0H)"7L-"@D)8V]N<W0@ M5"H@9&%T85\[#0H)"7!U8FQI8SH-"@D)97AP;&EC:70@8V]N<W1A;G0H8V]N M<W0@5"8@;V)J*2 Z(&1A=&%?*"9O8FHI('M]#0H)"6-O;G-T(%0F(&=E="@I M(&-O;G-T('L@<F5T=7)N("ID871A7SL@?0T*"0E].PT*#0H)"6-L87-S('1E M;7!O<F%R>2 Z('!R:79A=&4@8V]N<W1A;G0@+R\@='EP92!S=6=A<B!F;W(@ M=&5M<&]R87)I97,-"@D)>PT*"0EP=6)L:6,Z#0H)"65X<&QI8VET('1E;7!O M<F%R>2A4)B!O8FHI(#H@8V]N<W1A;G0H;V)J*2![?0T*"0E4)B!G970H*2!C M;VYS="![(')E='5R;B!C;VYS=%]C87-T/%0F/BAC;VYS=&%N=#HZ9V5T*"DI M.R!]#0H)"7T[#0H-"@EO<&5R871O<B!T96UP;W)A<GDH*0T*"7L-"@D@(" @ M<F5T=7)N('1E;7!O<F%R>2AS=&%T:6-?8V%S=#Q4)CXH*G1H:7,I*3L-"@E] M#0H);W!E<F%T;W(@8V]N<W1A;G0H*2!C;VYS= T*"7L-"@D@(" @<F5T=7)N M(&-O;G-T86YT*'-T871I8U]C87-T/&-O;G-T(%0F/B@J=&AI<RDI.PT*"7T- M"@T*#0H)<')O=&5C=&5D.@T*"0EE;F%B;&5D*"D@>WT@+R\@:6YT96YD960@ M=&\@8F4@9&5R:79E9"!F<F]M#0H)"7YE;F%B;&5D*"D@>WT@+R\@:6YT96YD M960@=&\@8F4@9&5R:79E9"!F<F]M#0H)?3L-"GT-"@T*=&5M<&QA=&4\='EP M96YA;64@5#X-"F-L87-S(%D@.B!P=6)L:6,@;6]V93HZ96YA8FQE9#Q9/%0^ M(#X-"GL-"G!U8FQI8SH-"G1Y<&5D968@='EP96YA;64@;6]V93HZ96YA8FQE M9#Q9/%0^(#XZ.G1E;7!O<F%R>2!T96UP;W)A<GD[#0IT>7!E9&5F('1Y<&5N M86UE(&UO=F4Z.F5N86)L960\63Q4/B ^.CIC;VYS=&%N="!C;VYS=&%N=#L- M"@T*62@I('M]#0H-"F5X<&QI8VET(%DH63Q4/B!C;VYS=" F*2![(&-O=70@ M/#P@(F5X<&QI8VET(&-O<'D@8V]N<W1R=6-T;W)<;B([('T-"EDH63Q4/B8I M('L@8V]U=" \/" B;F]N+6-O;G-T(&QV86QU92!C;W!Y(&-O;G1R=6-T;W)< M;B([('T-"EDH8V]N<W1A;G0I('L@8V]U=" \/" B8V]N<W0@8V]P>2!C;VYS M=')U8W1O<EQN(CL@?0T*62AT96UP;W)A<GDI('L@8V]U=#P\(")N;VXM8V]N M<W0@<G9A;'5E(&UO=F4@8V]N<W1R=6-T;W)<;B([('T-"GT[#0H-"@T*=&5M M<&QA=&4\='EP96YA;64@5#X-"ED\5#X@;6%K95DH*2![<F5T=7)N(%D\5#XH M*3M]#0H-"G1E;7!L871E/'1Y<&5N86UE(%0^#0I9/%0^(&-O;G-T(&UA:V59 M8V]N<W0H*2![<F5T=7)N(%D\5#XH*3M]#0H-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9V5T62A9/%0^*2![?0T*#0IT96UP;&%T93QT>7!E;F%M M92!4/@T*=F]I9"!G9719<F5F*%D\5#XF*2![?0T*#0IT96UP;&%T93QT>7!E M;F%M92!4/@T*=F]I9"!G97198V]N<W1?<F5F*%D\5#X@8V]N<W0@)BD@>WT- M"@T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM:6YA=&4H M63Q4/B8I('MC;W5T(#P\(")D:7-C<FEM:6YA=&4Z(&YO;BUC;VYS="!L=F%L M=65<;B([?0T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM M:6YA=&4H='EP96YA;64@63Q4/CHZ8V]N<W1A;G0I('MC;W5T(#P\(")D:7-C M<FEM:6YA=&4Z(&-O;G-T('9A;'5E7&XB.WT-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9&ES8W)I;6EN871E*'1Y<&5N86UE(%D\5#XZ.G1E;7!O M<F%R>2D@>V-O=70@/#P@(F1I<V-R:6UI;F%T93H@;F]N+6-O;G-T(')V86QU M95QN(CM]#0H-"FEN="!M86EN*"D-"GL-"ED\:6YT/B!Y,3L-"ED\:6YT/B!C M;VYS="!Y,CL-"@T*63QI;G0^('0Q*'DQ*3L@+R]C;W!Y(&YO;BUC;VYS="!L M=F%L=64-"ED\:6YT/B!T,BAY,BD[("\O8V]P>2!C;VYS="!L=F%L=64-"ED\ M:6YT/B!T,RAM86ME63QI;G0^*"DI.R O+V-O<'D@=&5M<&]R87)Y#0I9/&EN M=#X@=#0H;6%K95EC;VYS=#QI;G0^*"DI.R O+V-O<'D@8V]N<W0@=&5M<&]R M87)Y#0H-"F=E=%EC;VYS=%]R968H>3$I.R O+W!A<W,M8GDM8V]N<W0M<F5F M(&YO;BUC;VYS="!L=F%L=64-"F=E=%EC;VYS=%]R968H>3(I.R O+W!A<W,M M8GDM8V]N<W0M<F5F(&-O;G-T(&QV86QU90T*9V5T66-O;G-T7W)E9BAM86ME M63QI;G0^*"DI.R O+W!A<W,M8GDM8V]N<W0M<F5F(&YO;BUC;VYS="!T96UP M;W)A<GD-"F=E=%EC;VYS=%]R968H;6%K95EC;VYS=#QI;G0^*"DI.R\O<&%S M<RUB>2UC;VYS="UR968@8V]N<W0@=&5M<&]R87)Y#0H-"F=E=%DH>3$I.R O M+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T(&QV86QU90T*9V5T62AY,BD[("\O M<&%S<RUB>2UV86QU92!C;VYS="!L=F%L=64-"F=E=%DH;6%K95D\:6YT/B@I M*3L@+R]P87-S+6)Y+79A;'5E(&YO;BUC;VYS="!T96UP;W)A<GD-"F=E=%DH M;6%K95EC;VYS=#QI;G0^*"DI.R O+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T M('1E;7!O<F%R>0T*#0ID:7-C<FEM:6YA=&4\:6YT/BAY,2D[("\O;F]N+6-O M;G-T(&QV86QU90T*9&ES8W)I;6EN871E/&EN=#XH>3(I.R O+V-O;G-T(&QV M86QU90T*9&ES8W)I;6EN871E/&EN=#XH;6%K95D\:6YT/B@I*3L@+R]N;VXM M8V]N<W0@=&5M<&]R87)Y#0ID:7-C<FEM:6YA=&4\:6YT/BAM86ME66-O;G-T M/&EN=#XH*2D[("\O8V]N<W0@=&5M<&]R87)Y#0H-"@T*<F5T=7)N(# [#0I] ` end

5 38

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

19 Apr '04

Jeff Garland wrote: >> Robert Ramey wrote: >> So I'm skeptical of trying to adjust to "old" proprietary formats >> with the serialization library. > Well, I believe you are taking too narrow a view here. OK, I'll expand my horizon a bit. I can see how one might want to make special purpose archive which only handles a subset of all possible C++ structures. So it really comes down to evaluating the specific situation. There is nothing in the serialization library which conflicts with such usage so I'm happy to remain agnostic ( though still perhaps wary ) on this case. I wonder what happens when we need "special" information in the archive. I faced the same problem with XML where we need the name of the instance variable. I solved it by making the NVP wrapper which has worked well. However it does introduce a coupling between the archive and the serialization which I had strived to avoid. The best I could do was to make it optional and transparent to those archives which didn't use it. In order to do this I had to make all archive classes aware of it. Well, for XML this might be justified but in general I would find it objectionable. When one makes the archive dependent upon the serialization (E.G. by addressing only a subset of all C++), he won't be able to run the torture test suite. Personally, I consider this a significant liability. So anyway, if it works for a specific problem, then of course I've got no concerns. If its proposed as addition to the library, I would like to see it be universal as the current ones are - if only for the reason that a new archive can be subjected to the torture test with very little effort. So to summarize, if one wants/needs to make special purpose archive which handles a subset of all types - no problem. But it probably would not be of interest outside of the particular application. Robert Ramey

1 0

Re: [boost] Re: Serialization compile errors on CW9
by Robert Ramey 19 Apr '04

19 Apr '04

Message: 1 Date: Sun, 18 Apr 2004 13:54:08 -0400 From: Miro Jurisic <macdev(a)meeroh.org> Subject: To: Message-ID: <macdev-C68DBE.13540818042004(a)sea.gmane.org> In article <20040418160047.656883147E(a)acme.west.net>, "Robert Ramey" <ramey(a)rrsd.com> wrote: > Miro Jurisic wrote: > namespace detail { > #if BOOST_WORKAROUND... > typedef ::mbstate_t mbstate_t; > #else > typedef std::mbstate_t mbstate_t; > #endif > } OK - thanks, done, Robert Ramey

1 0