- Boost - lists.boost.org

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