July 2009 - Boost - lists.boost.org

[convert] Now with Boost.Parameter interface.
by Vladimir.Batov＠wrsa.com.au 16 Jul '09

16 Jul '09

I've incorporated, uploaded to the Vault and started playing with the Boost.Parameter-based interface that Andrey Semashev was insisting from the set-go. And it is definitely growing on me and I like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); instead of the original int i = convert<int>::from(str, 0) >> new_locale >> dothrow; I think people generally did not like locales and dothrow behaving like manipulators. The more I use the Boost.Parameter-based interface the more I am inclined to push it further and apply it to manipulators as well. I.e. int i = convert<int>::from(str)(radix_ = 16); instead of the original direct handling of std manipulators. int i = convert<int>::from(str) >> std::hex; Something, again, Andrey was advocating from the start. Now it feels like allowing io-stream manipulators exposes too much implementation detail and raises some unwarranted expectations. That raises a few questions that I am hoping people could help me with: 1. Both interfaces (for locale and dothrow) are currently supported: #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow; Should I remove #1? 2. Both interfaces #1 int i = convert<int>::from(str, 0) >> std::hex; #2 int i = convert<int>::from(str, 0)(radix_ = 16); are currently supported. Should I move away from direct manipulator support and remove #1? 3. I only managed to figure out how to supply only one Boost.Parameter at a time like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); I understand how to achieve int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true)); (with double quotes) but do not want to go there as it looks somewhat unorthodox. I cannot figure out how to achieve the following int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true); (a list inside single quotes). I remember Andrey mentioning I could do that with a Boost.Parameter macro but I admit of not being bright enough to figure it out by myself. Any help would be greatly appreciated. Thanks, Vladimir.

15 49

Re: [boost] gcc-4.4.0 and boost::optional is giving (spurious?) strict-aliasing warnings
by Giovanni Piero Deretta 15 Jul '09

15 Jul '09

On Thu, May 7, 2009 at 3:37 AM, Kim Barrett <kab.conundrums(a)verizon.net> wrote: > At 7:17 PM -0300 5/5/09, Brad Spencer wrote: >> > > In boost/aligned_storage.hpp, the class template > boost::aligned_storage defines its address member function thusly: > > void* address() { return this; } > const void* address() const { return this; } > I'm not 100% sure, but this could be very wrong as, IIRC, there is no guarantee that for non PODS the address of the first element (i.e. aligned_storage.data_) is the same as 'this'. but why doesn't aligned storage implements address() as: void * address { return this.data_.data_.buf; } BTW, I see that boost optional actually uses its own implementation of aligned storage, whose address member function returns a pointer to a char buffer, so it shouldn't be a problem. > There is code in boost/optional/optional.hpp (and probably the other > libs you mention) which looks like: > > internal_type* get_object() { > return static_cast<internal_type*>(m_storage.address()); > } > > What this leads, after some expansion, to something roughly equivalent > to > > static_cast<internal_type*>( > static_cast<void*>( > <a pointer to an instance of aligned_storage> )) > > which I believe is not strict aliasing safe. It is effectively a cast > from aligned_storage* to internal_type*, with a trip through void* > along the way. That trip through void* does not make the conversion > satisfy the strict aliasing rules. > IIRC aliasing rules talk about dynamic types of objects: roughly, you can access a memory location only with a type which is the same as the *dynamic type* of that location or as a char array. Boost optional does an explicit placement new of the stored type on the buffer which changes the dynamic type of the buffer so it should be safe from a standard point of view. Before reusing the buffer It invokes the destructor of the type, which ends the object lifetime. That said, gcc has been known to miscompile placement new from time to time (but it should be more or less fixed on recent versions: it pretty much acts as a compiler optimization barrier). In the end, IMHO the warning is spurious and could be safely ignored (modulo compiler bugs). > [Note that it is not the cast itself that violates the strict aliasing > rules, it is the later dereference of the pointer resulting from the > cast.] > > [Note that I'm pretty sure that switching from static_cast to > reinterpret_cast doesn't help.] > > One of the escape hatches provided by the strict aliasing rules > involves ensuring that there is a union type in scope at the point of > the conversion which contains both of the involved types. [The > "visible union" rule of 6.5.2.3#5.] I do not think this rule actually help you: you can't still read from a field different from the last written to (except for some exceptions like structures with common initial sequences.) Most compilers give additional guarantees, though. > Another escape hatch offered by the strict aliasing rules involves > memcpy and memmove. [6.5#6] I think that the following implementation of > aligned_storage::address will satisfy the strict aliasing rules: > > void* address() { > void* data = data_.data_.buf; > return memmove(data, data, sizeof(*data)); > } > > And I think gcc will optimize away the memmove, at least at sufficient > optimization levels. But note that I have not tested this at all. > > [Hm, using a size of 0 or 1 or some similar small value might be > sufficient to quiet the compiler; I'm not certain whether it is > sufficient to satisfy the letter of the C standard.] I do not see how this helps, first of all sizeof(*data) is illegal (sizeof(void) doesn't make any sense, gcc defines it as 1 as an extension), then how copying one byte will fix aliasing problems? > > The idea is that memmove (and memcpy, but that requres non-overlapping > source and destination, which we don't have here) is defined by the > aliasing rules to strip away the type of the destination, in a way > that a simple cast does not. I do not think it really strips away the type of the destination: in fact it is often unsed to bit cast from integers to float and back: if a memcpy(&some_float, &some_integer, sizeof(int32_t)) really did change the type of some_float, it would break a lot of code (you could no longer threat some_float as a float). What is guarateed is that some_float will contain the same bit pattern of some_integer, while still maintaining the float type. It assumes that the bit pattern of the source is a valid pattern for the destination type, otherwise it is UB. > > [And yes, I agree that this is rather grotesque.] > Aliasing rules really are a mess. -- gpd

3 3

Boost::Serialization Combined XML- and Binary-Serialization
by Daniel Kunz 15 Jul '09

15 Jul '09

Hello, I try to write an function, which can convert data via the serialization interface XML --> class --> binary AND binary --> class --> XML I read the documentation and in the mailing lists but I could not finish my functions. I have 2 problems: 1) the xml function delivers no xml data in my testfile output 2) I cannot add the binary structure to the existing xml-working classes With the binary serialization I didn't find many informations, but that informations I found I can't use with the classes I prepared for xml serialization Is it possible to combine that 2 serializations Here is my testing code I worked with so far. The finish coding is similar with that class structure. The class structure: -------------------------------------------------------- goal.cpp -------------------------------------------------------- #include <string> #include <iostream> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/binary_object.hpp> namespace serialization { class Goal { public: enum Scored{home=0, visitors=1}; Goal(){}; Goal(const string _name, int &_minute, bool &_shootout, Scored &_scored, bool &_penality); ~Goal(){}; friend ostream & operator<<(ostream &os, const Goal &_goal); private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Name", name); ar & make_nvp("Minute", minute); ar & make_nvp("Shootout", shootout); ar & make_nvp("Scored", scored); ar & make_nvp("Penality", penality); boost::serialization::binary_object bo = boost::serialization::make_binary_object(minute, sizeof(minute)); ar & bo; } string name; int minute; bool shootout; Scored scored; bool penality; }; } -------------------------------------------------------- stadium.h -------------------------------------------------------- #include <string> #include <iostream> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> namespace serialization { class Stadium { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Name", name); ar & make_nvp("City", city); ar & make_nvp("Spectators", spectators); } string name; string city; int spectators; public: Stadium(){}; Stadium(const string _name, const string _city, int &_spectators); friend ostream & operator<<(ostream &os, Stadium &_stadium); }; } -------------------------------------------------------- match.h -------------------------------------------------------- #include <list> #include <time.h> #include <string> #include <iostream> #include <cstdio> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/serialization.hpp> #include "goal.h" #include "stadium.h" namespace serialization { class Match { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Home", home); ar & make_nvp("Visitors", visitors); ar & make_nvp("Kickoff", kickoff); ar & make_nvp("Goals", goals); ar & make_nvp("Stadium", stadium); } string home; string visitors; time_t kickoff; typedef list<Goal> lGoals; lGoals goals; Stadium stadium; public: Match(){}; Match(const string _home, const string _visitors, time_t &_kickoff, Goal *_goals, int size, Stadium &_stadium); Match& operator = (Match &_match); friend ostream & operator<<(ostream &out, Match &_match); }; } -------------------------------------------------------- xml.cpp -------------------------------------------------------- #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <iomanip> #include <iostream> #include <fstream> #include <string> #include "goal.h" #include "stadium.h" #include "match.h" #include <boost/serialization/base_object.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> using namespace std; void save_xml(const serialization::Match &m, const string &filename) { try { ofstream ofs(filename.c_str()); assert(ofs.good()); boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp("Match", m); } catch(exception &e) { cout << e.what() << endl; } } void restore_xml(serialization::Match &m, const string &filename) { try { ifstream ifs(filename.c_str()); boost::archive::xml_iarchive ia(ifs); ia >> boost::serialization::make_nvp("Match", m); } catch(exception &e) { cout << e.what() << endl; } } -------------------------------------------------------- binary.cpp -------------------------------------------------------- void save_bin(const serialization::Match &m, const string &filename) { try { std::ofstream ofs(filename.c_str()); boost::archive::binary_oarchive oa(ofs); //oa << m; } catch(exception &e) { cout << e.what() << endl; } } void restore_bin(serialization::Match &m, const string &filename) { try { std::ifstream ifs(filename.c_str()); boost::archive::binary_iarchive ia(ifs); //ia >> m; } catch(exception &e) { cout << e.what() << endl; } } I hope somone can help me. I don't know what I can do to complete that functions. Best regards Daniel

2 1

Re: [boost] [log] Review-ready version in the Vault
by Michael C. Stricklin 15 Jul '09

15 Jul '09

The latest version of boost.log (from the repository) fails to compile under gcc 4.1.0 (although it does fine under 4.1.2). I see the same errors compiling against both 1.38 and 1.39. The problems appears to lie with inherits from mpl. I can provide error logs if requested. Many Thanks, Mike Stricklin

5 5

[interprocess] flat_multiset/flat_multimap missing?
by Thorsten Ottosen 15 Jul '09

15 Jul '09

Hi Ion, It would be nice if these containers were also avaiable. Thanks -Thorsten

1 0

[mpl] possible regression compiling with Visual C++
by Edd Dawson 15 Jul '09

15 Jul '09

Hi folks, The following code compiles fine against Boost 1.34.1 and 1.35.0, but apparently not anything later. I've tried 1.36.0 and 1.39.0. I'm compiling with Microsoft's Visual C++ 2005 and 2009 compilers (the express editions if it matters). #include <boost/mpl/remove.hpp> #include <boost/mpl/vector.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> #include <boost/preprocessor/repetition/enum_params_with_a_default.hpp> template<BOOST_PP_ENUM_PARAMS_WITH_A_DEFAULT(BOOST_MPL_LIMIT_VECTOR_SIZE, typename T, void)> struct X { typedef typename boost::mpl::vector<BOOST_PP_ENUM_PARAMS(BOOST_MPL_LIMIT_VECTOR_SIZE, T)>::type template_parameters; // mpl::vector of template parameters typedef typename boost::mpl::remove < template_parameters, void > ::type template_parameters_no_voids; // voids removed }; int main() { X<int> x; return 0; } The error messages using Boost 1.39.0 and Visual C++ 2005: mpl_regression.cpp M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(45) : error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************(__thiscall boost::mpl::push_back_impl<Tag>::apply<Sequence,T>::REQUESTED_PUSH_BACK_SPECIALIZATION_FOR_SEQUENCE_DOES_NOT_EXIST::* ***********)(Sequence)' to 'boost::mpl::assert<false>::type' with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] No constructor could take the source type, or constructor overload resolution was ambiguous M:\libs\boost\1.39.0\boost/mpl/push_back.hpp(32) : see reference to class template instantiation 'boost::mpl::push_back_impl<Tag>::apply<Sequence,T>' being compiled with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] M:\libs\boost\1.39.0\boost/mpl/aux_/has_type.hpp(20) : see reference to class template instantiation 'boost::mpl::push_back<Sequence,T>' being compiled with [ Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(55) : see reference to class template instantiation 'boost::mpl::aux::has_type<T>' being compiled with [ T=boost::mpl::push_back<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>>> ] M:\libs\boost\1.39.0\boost/mpl/push_back.hpp(43) : see reference to class template instantiation 'boost::mpl::has_push_back_impl<Tag>::apply<Seq>' being compiled with [ Tag=boost::mpl::aux::vector_tag<20>, Seq=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void> ] M:\libs\boost\1.39.0\boost/mpl/if.hpp(63) : see reference to class template instantiation 'boost::mpl::has_push_back<Sequence>' being compiled with [ Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void> ] M:\libs\boost\1.39.0\boost/mpl/remove.hpp(48) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled with [ T1=boost::mpl::has_push_back<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>, T2=boost::mpl::aux::remove_impl<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,void,boost::mpl::back_inserter<boost::mpl::clear_impl<boost::mpl::aux::vector_tag<20>>::apply<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>::type>>, T3=boost::mpl::aux::reverse_remove_impl<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,void,boost::mpl::front_inserter<boost::mpl::clear_impl<boost::mpl::aux::vector_tag<20>>::apply<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>::type>> ] mpl_regression.cpp(18) : see reference to class template instantiation 'boost::mpl::remove<P1,P2>' being compiled with [ P1=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, P2=void ] mpl_regression.cpp(23) : see reference to class template instantiation 'X<T0>' being compiled with [ T0=int ] M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(45) : error C2866: 'boost::mpl::push_back_impl<Tag>::apply<Sequence,T>::mpl_assertion_in_line_6' : a const static data member of a managed type must be initialized at the point of declaration with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] Is this a problem with more recent versions of Boost, or am I doing something wrong? It looks like it's complaining because an mpl::vector of maximal static size doesn't implement push_back, but it surely shouldn't need to for a remove operation? Kind regards, Edd

4 6

gcc4.3 warning for multiple scope_exits
by Kim Barrett 14 Jul '09

14 Jul '09

Boost.ScopeExit uses a tricky bit of code (from Steven Watanabe) to allow a macro expansion to contain code which will declare a variable exactly once, regardless of how many times the macro is used in a given scope. Unfortunately, gcc4.3 -Wall generates a warning for this code in the second and later uses of the macro in the same scope. The warning is comparisons like X<=Y<=Z do not have their mathematical meaning It is complaining about a statement that gets parsed as identifier < 0 > variable; Valid code, and correct in this particular case, but the warning is there never the less. I realize that boost doesn't have a no-warnings policy (dealing with compiler variations that lead to actual errors is hard enough), but since my team has a general policy of using -Werror and I've been proselytizing the use of scope_exit within our group, I was motivated to find a way to kill this warning. After studying Steven's trick (ouch! my brain hurts) I've come up with an extension of the same technique which avoids the warning, using the time honored approach of adding another level of indirection. Here's my patch: ---------- --- scope_exit.hpp.orig 2009-07-09 13:19:36.000000000 -0400 +++ scope_exit.hpp.new 2009-07-09 13:20:04.000000000 -0400 @@ -36,14 +36,21 @@ typedef void* declared; struct undeclared { declared dummy[2]; }; + template<int> + struct holder + { + declared value; + static const int apply_value = 0; + friend void operator>(int, const holder&) {} + }; + template<> struct declare<sizeof(undeclared)> { template<int> struct apply { - declared value; - friend void operator>(bool, const apply&) {} + static const int apply_value = 0; }; }; @@ -214,8 +221,9 @@ BOOST_PP_SEQ_FOR_EACH_I(BOOST_SCOPE_EXIT_AUX_MEMBER, id, seq) \ BOOST_SCOPE_EXIT_AUX_PARAMS_T_CTOR(id, seq) \ } BOOST_SCOPE_EXIT_AUX_PARAMS(id) BOOST_SCOPE_EXIT_AUX_PARAMS_INIT(id, seq)\ - boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ - ::apply<0> boost_scope_exit_args; \ + boost::scope_exit::aux::holder< \ + boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ + ::apply<0>::apply_value> boost_scope_exit_args; \ boost_scope_exit_args.value = &BOOST_SCOPE_EXIT_AUX_PARAMS(id); \ struct BOOST_SCOPE_EXIT_AUX_GUARD_T(id) { \ BOOST_SCOPE_EXIT_AUX_PARAMS_T(id)* boost_se_params_; \

2 4

[task] new version 0.2.2
by k-oli＠gmx.de 13 Jul '09

13 Jul '09

Hello, I've added boost.task-0.2.2 to boost.vault: - allow user-defined execution policies - private inheritance from noncopyable removed from task< R > and static_pool< R > copy-ctor and assignment-op private and unimplemented allowing correct move-semantics - worker_group removes all worker-threads in join_all() static_pool< R > does contain zero worker-threads after shutdown() or shutdown_now() - reintroduction of make_task() - internal refactoring/rework - documentation updated - tests updated - examples updated best regards, Oliver

1 0

MS VC 2010 Beta 1
by Dennis Yurichev 13 Jul '09

13 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Somebody already had a success on building Boost with new MS VC 2010 Beta 1? - -- My PGP public key: http://yurichev.com/dennis.yurichev.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXG0UACgkQ1YPmFmJG++N68gCg2YD+xA03lNt4AKnKBd435h/C JP8AnRXr+MRktAzGLIFTWRUQJMHmySGl =ctCu -----END PGP SIGNATURE-----

2 1

program_options custom validators
by Zachary Turner 13 Jul '09

13 Jul '09

Hello, recently I was faced with a situation of writing a custom validator for a certain command line option I wanted to handle. The validator was supposed to check whether the value on the command line was in a certain range. After some head scratching, I realized there's no elegant way to do this with the current validation overload function. In the end I just ended up doing the validation after the options had been parsed. I was thinking about a good way to support this, and I thought that maybe the best way is to add an additional value semantic so that the validate function could instead be: template<class T, class validation_data> void validate(boost::any& v, const std::vector<std::string>& values, const validation_data& data, T* target_type, int); and we could write add_options() ("test", value<int>()->validate(boost::interval<int>(1, 10)) ); this would require the user to provide the following overload: void validate(boost::any& v, std::vector<std::string>& values, const boost::interval<int>& data, int* target_type, int); the default implementation of validate would all use some dummy type for validation_data, this way compilation would fail if user calls validate but does not provide the appropriate overload. And if the user does not want to provide additional validation data he can simply use the current syntax, but instead would provide the following validate() overload void validate(boost::any& v, const std::vector<std::string>& values, const no_validation_data& data, T* target_type, int); Thoughts? Zach

2 3