- Boost - lists.boost.org

[serialization] Proposal to add support for lexical_cast
by Martin Wille 13 Jul '05

13 Jul '05

Hi, I propose the addition of a lexical_cast wrapper to Boost.Serialization. Motivating example: Suppose you have several UDTs for which you already have defined insertion/extraction operators, and you want to use Boost.Serialization to read/write values of these UDTs, preferably in a non-intrusive way. Problem: Boost.Serialization doesn't make use of existing insertion/extraction operators for the UDTs. Proposed addition: A Serialization Wrapper (similar to those described in http://tinyurl.com/e46v5 [1]) that performs on-the-fly conversion of an UDT value to some serializable type, usually a std::string. Code is attached. The proposed wrapper allows to specify a conversion that will be used during serialization/deserialization operations. During serialization, a value will get converted to a different type; the converted value is written to the archive. During deserialization, the value is converted back to the original type. The proposed wrapper uses boost::lexical cast for the conversion. Usage example: // udt.hpp struct udt { }; std::ostream &operator<<(std::ostream &, udt const &); std::istream &operator>>(std::istream &, udt const &); // someclass.hpp #include "udt.hpp" #include <boost/serialization.hpp> struct someclass { template<typename Archive> void serialize(Archive &ar, const unsigned int version) { ar & boost::serialization::lexical_cast<std::string>(my_udt); } private: udt my_udt; }; Pros: - very easy to use - non-intrusive Cons: - not very fast Questions: - Would you consider this a useful addition? - Would the name boost::serialization::lexical_cast be acceptable? - Do you see a use case for using an "external" type other than std::string with this wrapper, e.g ar & boost::serialization::lexical_cast<int>(my_udt); // ? (The code could be simplified, otherwise) - Similar wrappers could be written for the C++ cast operations, too. Would such wrappers be useful? - Would it be desirable to extend this to a general conversion-on-the-fly framework? - Assuming there are some positive responses about the usefulness of the lexical_cast wrapper, would this addition be suitable for a fast-track review (it is very tiny)? (I'd say no if this evolves into a general conversion-on-the-fly framework) - other comments? Thanks to Robert who helped me to understand my own code better. Regards, m [1] http://boost.org/libs/serialization/doc/wrappers.html // (C) Copyright Martin Wille 2005. Distributed under the Boost // Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt) #ifndef BOOST_SERIALIZATION_LEXICAL_CAST_HPP #define BOOST_SERIALIZATION_LEXICAL_CAST_HPP #include <boost/lexical_cast.hpp> #include <boost/serialization/traits.hpp> #include <boost/serialization/split_member.hpp> namespace boost { namespace serialization { template <class T, class Intermediate = std::string> struct lexical_cast_wrapper : traits <lexical_cast_wrapper<T, Intermediate> ,object_serializable , track_never > { explicit lexical_cast_wrapper(T &t) : value(t) {} template <class Archive> void save(Archive &ar, unsigned int) const { Intermediate tmp((boost::lexical_cast<Intermediate>(value))); ar << tmp; } template <class Archive> void load(Archive &ar, unsigned int) const { Intermediate tmp; ar >> tmp; value = boost::lexical_cast<T>(tmp); } BOOST_SERIALIZATION_SPLIT_MEMBER(); private: T &value; }; template <class Intermediate, class T> lexical_cast_wrapper<T, Intermediate> lexical_cast(T &value) { return lexical_cast_wrapper<T, Intermediate>(value); } template <class T> lexical_cast_wrapper<T> lexical_cast(T &value) { return lexical_cast_wrapper<T>(value); } }} #endif

2 2

Filesystem i18n mini-review
by Martin 13 Jul '05

13 Jul '05

Been on vacation for a couple of weeks and missed the filesystem mini-review deadline. Here are som quick comments anyway: - What is your evaluation of the design? I think that the general design is very nice but I have a few issues: 1. The basic_path template parameter "String" defines the type used to store the path internally but at the same time it also defines the type used for construction and operator/. Consider the following example: I want to store the path in shared memory and therefore use a flex_string type with a 200 character internal buffer. Problem here is that now the path can only be created from this 200 character flex_string and not from std::string. One solution might be to let the constructor and operator/ work with ranges but it might create problems with copy constructor. template <typename RangeT> explicit basic_path(const RangeT& str) { append(begin(str), end(str)) } 2. All operations work with std::(w)string. When the internal string type is not std::string a conversion is necessary. In most cases the charcater conversion should be trivial but since a std::string is required a copy can't be avoided. In the example I used above, the flex_string must be copied into a std::string for each operation even if the character string is identical. Why not base operations on null terminated strings (const char*) or a pair of iterators instead. 3. Comparison between paths doesn't use locale. The paths are not treated as plain characters since a lexicographical compare is made. But the individual elements are treated as plain characters and the internal string type's operator< is used. This is a bit contradicting. I think the comparison operators should compare the elements in a locale dependent way. - What is your evaluation of the implementation no comment - What is your evaluation of the documentation? Very good. - Did you try to use the library? With what compiler? Did you have any problems? Haven't tried the i18n version yet. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have used the original filesystem library for approx 1 year and I have followed the i18n development closly. - Are you knowledgeable about the problem domain? yes, but I have only used the windows part (i.e. no portability). - Do you think the library should be accepted as a Boost library? yes.

2 2

VC8 type traits documentation
by Carl Daniel 13 Jul '05

13 Jul '05

Peter Dimov asked, and I don't recall seeing an answer posted (back on May 5): "Where is the instrinsic support documented, BTW?" Here: http://msdn2.microsoft.com/library/ms177194(en-us,vs.80).aspx -cd

3 3

Interest in a binary_int template for binary literals?
by Scott Schurr 13 Jul '05

13 Jul '05

Greetings, Prompted by some discussion on comp.sdt.c++.moderated, I have a small template that allows the user to declare an integer literal in binary. Usage looks like: #include "binary_int.hpp" unsigned int binary = binary_int<1001,0011,1011,0000>::b; The template is written to support up to 64 bits, although my compiler only allows me test up to 32 bits. I intend to use it for programming hardware registers in the language of the hardware folk at my company. The template is only about 150 lines and doesn't really deserve a library, but it could potentially be tucked into another library if it is deemed useful. Thanks. Scott Schurr

6 6

BOOST_NO_RESULT_OF
by David Abrahams 13 Jul '05

13 Jul '05

I want this macro for the parameters library. Currently, result_of uses #if !defined(BOOST_NO_SFINAE) && !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) And otherwise, gives an #error That makes it hard to use portably, because the criteria under which result_of will be supported are not encapsulated, and I couldn't even define it in that file usefully (I'd still get an #error when it isn't supported). Shouldn't there be a generalized way to handle this sort of situation? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 5

Re: [boost] Bug in boost::thread
by Gili 13 Jul '05

13 Jul '05

> I don't understand. What about the quite explicit message in > http://www.boost.org/doc/html/threads/implementation_notes.html#threads.impl > ementation_notes.win32 ? > > /David Well, I never read that. I highly recommend you copy that note over to the documentation for the Thread constructor. The limitations should be attached to the method in question, not in some arbitrary chapter later on (no one reads manuals cover to cover). Just my 2 cents. Gili

1 0

Mysterious Cygwin GCC 3.4.4 link problems
by David Abrahams 13 Jul '05

13 Jul '05

Does anyone have a clue about this? Other toolsets, including gcc-2.95.3, gcc-3.3.3, and gcc-4.0.0 all work fine. "/usr/local/gcc-3.4.4/bin/g++.exe" -Wall -ftemplate-depth-100 -O0 -fno-inline -g -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -c -o "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.o" "sfinae.cpp" "/usr/local/gcc-3.4.4/bin/g++.exe" -o "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.exe" "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.o" -g /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_throw.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_throw.o):: undefined reference to `___w32_sharedptr_terminate' collect2: ld returned 1 exit status -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Bug in boost::thread
by Gili 13 Jul '05

13 Jul '05

If one creates a new boost::thread within DLLMain or a function it invokes, CreateThread (invoked by Boost) creates a new thread but does not start it. Boost's code then waits on the native thread to start before returning from the constructor but because this never occurs it blocks forever. You should either document this limitation (i.e. one may not create a boost::thread within DLLMain or a function invoked by it) or change the implementation to handle this limitation. Thank you, Gili -- http://www.desktopbeautifier.com/

4 3

Problem with Boost 1.32.0 and the Borland free compiler
by Sean Childs 13 Jul '05

13 Jul '05

I get this message when using boost/regex (it may or may not occur with other boost libraries, I havn't checked): Warning W8097 H:\Libraries\boost_1_32_0\boost/config/auto_link.hpp 240: Not all options can be restored at this time "Fatal F1004 test.cpp 15: Internal compiler error at 0x40638d with base 0x400000 in function main(int,char * *)". On line 240 (or thereabouts) of boost/config/auto_link.hpp (Boost version 1.32.0). This: "#pragma defineonoption BOOST_BORLAND_DEBUG -v" causes an ICE with Borland's free compiler if the option -v is not already being used. I don't know if this is common or not, though I did find one other message stating the same problem: http://lists.boost.org/boost/2005/04/25188.php.

2 3

[Boost.build v2 (1.32.0)] Writing an extension for LEIF (XSD to C++ Class Generator)...
by Sylvain, Gregory M 13 Jul '05

13 Jul '05

Hello all, We are currently using boost_1_32_0 and I'm trying to write a toolset file to enable us to use Roguewave's LEIF xsd2cpp C++ class generator from within bjam. (The xsd2cpp command is just a C++ class generator that generates C++ class from a respective W3C XSD Schema). I'm not having much luck, I've been through the boost build manual, samples, etc. and I'm still having problems. In the end, I would like to be able to write a library rule such as : lib libclientxml : schemas.xsd ; And have boost run RW's xsd2cpp tool run on the file schemas.xsd and all of the resulting cpp files that are generated would be compiled and archived in libclientxml. I have a toolset file in my boost-build/tools directory as follows: ---- begin file boost-build/tools/xsd2cpp.jam ---- import type ; type.register XSD : xsd ; import generators ; class cpp-generator : generator { rule __init__ ( * : * ) { generator.__init__ $(1) : $(2) : $(3) : $(4) : $(5) : $(6) : $(7) : $(8) : $(9) ; } # after the actions is executed, get a list of the generated targets that # results from this action rule generated-targets ( sources * : property-set : project name ?) { local leafs ; local temp = [ virtual-targets.traverse $(sources[1]) : : include-sources ] ; for local f in $(temp) { leafs += $(f) ; } return [ generator.generated-targets $(sources) $(leafs) : $(property-set) : $(project) $(name) ] ; } } generators.register [ new cpp-generator xsd2cpp.xsd2cpp : XSD : CPP ] ; actions xsd2cpp { # run RW's xsd2cpp command over the source and produce a lot of C++ code. xsd2cpp -STL "$(>)" } ---- end file boost-build/tools/xsd2cpp.jam ---- If anyone has a clue how to do this, please let me know. Or if I've going about this the wrong way, I would like to here that as well. Thanks for any assistance with this, greg

2 1