- Boost - lists.preview.boost.org

[Progress]
by Pierre 16 Jul '09

16 Jul '09

Hello, I have a suggestion over boost/progress.hpp. The class is very good. But I have a critic to announce. If we want to use the class to just keep an eye of the evolution of the process (we do not can just say we don't want a stream output (i'm right??)). I.E : to send the progress pourcentage to a graphical progress bar. So I purpose something like the following : A basic class to manage the evolution of a process. A class to display the evolution of the process that use the precedent one. It's possible I misunderstanding the progress_display class to tell it that we don't want stream output (example to feed a graphical progress bar). The body of the functions and classes will be something like : #include <iostream> #include <string> using namespace std; // CProgress --------------------------------------------------------// // CProgress manage the appropriate count_step of progress // Usage : // CProgress progress( COUNT ); // for(int i=0; i < COUNT; ++i, ++progress) //{ // ... //do something //} //-- you can access to internal data : // //cout<< "Count : " << my_progress_bar.count() << " pourcent " << my_progress_bar.count()/(float)my_progress_bar.expected_count()*100; class CProgress { public: explicit CProgress ( unsigned long expected_count=1 ) { restart ( expected_count ); } virtual void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { _count = _next_tic_count = _tic = 0; _expected_count = expected_count; if ( !_expected_count ) _expected_count = 1; // prevent divide by zero } // restart unsigned long operator+= ( unsigned long increment ) // Effects: Increment appropriate progress tic if needed. // Postconditions: count()== original count() + increment // Returns: count(). { if ( ( _count += increment ) >= _next_tic_count ) { inc_tic(); } return _count; } unsigned long operator++() { return operator+= ( 1 ); } //-- Accessor unsigned long count() const { return _count; } unsigned long expected_count() const { return _expected_count; } protected: unsigned long _count, _expected_count, _next_tic_count; unsigned int _tic; private: virtual void inc_tic() { _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); } // inc_tic }; // CProgress_display --------------------------------------------------------// // CProgress_display displays an appropriate indication of // progress at an appropriate place in an appropriate form. // Usage : // CProgress_display my_progress_bar( fileList.size() ); // for (list<string>::const_iterator it = fileList.begin(); it != fileList.end(); ++it, ++my_progress_bar) // the CProgress_display::operator++ take in charge the display of the progression (***) // { // const string & filename = *it; // ... // do something // } // //0% 10 20 30 40 50 60 70 80 90 100% //|----|----|----|----|----|----|----|----|----|----| //************************** ... class CProgress_display : public CProgress { public: explicit CProgress_display ( unsigned long expected_count, std::ostream & os = std::cout, const std::string & s1 = "\n", //leading strings const std::string & s2 = "", const std::string & s3 = "" ) // os is hint; implementation may ignore, particularly in embedded systems : m_os ( os ), m_s1 ( s1 ), m_s2 ( s2 ), m_s3 ( s3 ) { restart ( expected_count ); } void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { CLTU_Progress::restart ( expected_count ); //-- Initialize the base class m_os << m_s1 << "0% 10 20 30 40 50 60 70 80 90 100%\n" << m_s2 << "|----|----|----|----|----|----|----|----|----|----|" << std::endl // endl implies flush, which ensures display << m_s3; } // restart private: std::ostream & m_os; // may not be present in all imps // string is more general, safer than const char *, and efficiency or size are not issues const std::string m_s1, m_s2, m_s3; // formatting display void inc_tic() { // use of floating point ensures that both large and small counts // work correctly. static_cast<>() is also used several places // to suppress spurious compiler warnings. unsigned int tics_needed = static_cast<unsigned int> ( ( static_cast<double> ( _count ) /_expected_count ) *50.0 ); do { m_os << '*' << std::flush; } while ( ++_tic < tics_needed ); _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); if ( _count == _expected_count ) { if ( _tic < 51 ) m_os << '*'; m_os << std::endl; } } // display_tic }; _________ I'm sure the community will be open to discuss about it. Talk to you, Best, Pierre

2 2

boost.uuid is_pod failure
by Tim Blechmann 16 Jul '09

16 Jul '09

hi all, using boost.uuid from uuid_alt_v13_pod.zip, i get some static assertion failures of is_pod<boost::uuid> --- test_uuid.cpp~ 2008-12-06 02:27:38.000000000 +0100 +++ test_uuid.cpp 2009-07-15 10:59:01.016387917 +0200 @@ -22,6 +22,8 @@ #include <string> #include <vector> + +BOOST_STATIC_ASSERT(boost::is_pod<boost::uuid>::value); int test_main(int, char*[]) { i am not sure, whether it is a problem of is_pod or uuid, though ... best, tim -- tim(a)klingt.org http://tim.klingt.org Lesser artists borrow, great artists steal. Igor Stravinsky

3 3

Bug sprint aftermath questions.
by Marshall Clow 16 Jul '09

16 Jul '09

Now the bug sprint is over - I have a few questions..... * Was the bug sprint worth doing? * If so, is it worth doing again? How soon? Regularly? How often? * What worked really well? * What didn't work well? I'm also looking for general comments.... Facts: * We went from 797 open tickets to 706. (that's a change of 12%) * A lot of very old tickets were dealt with; the oldest Trac ticket is now from 2005 (instead of 2001). * There's still several tickets that have patches waiting to be applied. * The Trac system had a few problems ("locked database") and is still having spam problems, but worked reasonably well. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

10 13

Behavior change in path operator /
by Gérald Fauvelle 16 Jul '09

16 Jul '09

Hi all, I'm updating my boost version from 1.33 to 1.38... That's a big step, and I've found a difference in operator / of filesystem::path. In 1.33, when I was doing : path a = path("d:/toto/titi"); path b = path("d:/tata/tutu"); path c = a/b; I had c == "d:/tata/tutu" So if b was a complete (or absolute) path, the result was b, whatever value has "a". I don't know if this behavior was correct or not, but we were using it this way, it was fine. Now with 1.38, I have : c == "d:/toto/titi/d:/tata/tutu" That is at first different from previous behavior, and also obviously wrong for a path syntax on Windows at least. It seems also that in 1.33 a path like this would raise an exception. I've tried to find when, in what version, this change occured, but couldn't find it in release notes. Was this change made intentionanly, if yes, what is the reason for that? And if I want previous behavior, I have 2 solutions. Fix my code, of fix boost code. I'm afraid that if I fix boost code I could break some boost functionnalities, or can I do it with no problem ? Thanks, Gérald

2 2

[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

intrusive_ptr design question
by Zachary Turner 13 Jul '09

13 Jul '09

I was wondering from a design perspective, why was it decided that intrusive_ptr should rely on user-defined free functions intrusive_ptr_add_ref and intrusive_ptr_release to handle the reference counting? This makes it somewhat inconvenient, for some constant type T, to support having two different instances of intrusive_ptr<T>, each of which use a different reference counting strategy. If there's a clever way to allow this that I'm missing please advise.

9 20

type_traits/call_traits and function_traits : Why are they separate
by joel 12 Jul '09

12 Jul '09

Is there anything that prevent those three libraries (type_traits,call_traits and function_traits) to be merged in a single traits library ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

1 0

Re: [boost] [serialization][trunk] Latest patch for void_cast.cpp causes segfaults
by Hartmut Kaiser 11 Jul '09

11 Jul '09

> apparently the latest patch to > boost/libs/serialization/src/void_cast.cpp > (rev.53078, svn:date: 2009-05-18T06:25:56.023190Z, svn:author: ramey, > svn:log: fix errors in extended_type_info management) causes an > existing application to segfault during cleanup. The application was > working properly before. The attached patch fixes the issue. > > Ok to commit? Ping? Regards Hartmut

3 8

Debug Assertion Failed while trying to use read_graphviz
by Anna Kazeykina 11 Jul '09

11 Jul '09

Hello, I tried to compile and run in VS 2008 the following example illustrating how to use read_graphviz() function: #include <boost/graph/graphviz.hpp> #include <boost/graph/adjacency_list.hpp> #include <string> #include <sstream> using namespace boost; using namespace std; int main() { // Vertex properties typedef property < vertex_name_t, std::string, property < vertex_color_t, float > > vertex_p; // Edge properties typedef property < edge_weight_t, double > edge_p; // Graph properties typedef property < graph_name_t, std::string > graph_p; // adjacency_list-based type typedef adjacency_list < vecS, vecS, directedS, vertex_p, edge_p, graph_p > graph_t; // Construct an empty graph and prepare the dynamic_property_maps. graph_t graph(0); dynamic_properties dp; property_map<graph_t, vertex_name_t>::type name = get(vertex_name, graph); dp.property("node_id",name); property_map<graph_t, vertex_color_t>::type mass = get(vertex_color, graph); dp.property("mass",mass); property_map<graph_t, edge_weight_t>::type weight = get(edge_weight, graph); dp.property("weight",weight); // Use ref_property_map to turn a graph property into a property map boost::ref_property_map<graph_t*,std::string> gname(get_property(graph,graph_name)); dp.property("name",gname); // Sample graph as an std::istream; std::istringstream gvgraph("digraph { graph [name=\"graphname\"] a c e [mass = 6.66] }"); bool status = read_graphviz(gvgraph,graph,dp,"node_id"); return 0; } When I run the program I get the Debug Assertion Failed message (when I delete the line with read_graphviz everything is OK). Could you please help me with this problem? Thank you, Anna.

2 1

Build changes for 1.40
by Vladimir Prus 11 Jul '09

11 Jul '09

FYI, I've merged Boost.Build from trunk to release branch. The most important change is that now, on Unix, default build with act as if --layout=system is specified, creating libraries with no decoration that can be conveniently used. Other changes are documented at: http://beta.boost.org/users/news/version_1_40_0 Let me know if this causes any problems. - Volodya

1 0

Boost.Range too focused on iterators?
by j j 11 Jul '09

11 Jul '09

The boost range library makes ranges similar to the to the STL Container<http://www.sgi.com/Technology/STL/Container.html>concept. A Range provides *iterators* for accessing a half-open range [first,one_past_last) of elements and provides information about the number of elements in the Range. Wouldn't it be better if it could use *values* and iterators? eg template<class access> ostream& operator<<(ostream& out,const range<access>& in){ for(x temp=in.a;temp!=in.b;temp++)cout<<access()(temp); return out; } //Later on in code //prints a range of numbers cout<<Range<no_deref >(0,8); //no_deref is a function object that returns a reference to its argument. //prints the contents of a range of iterators. string a="Hello World!"; cout<<Range(a.begin(),a.end()) //defaults to deref which is a function object that derefences its argument with *

2 1

[sandbox.move] coexistence issues with boost.interprocess + small suggestion
by Jeffrey Hellrung 09 Jul '09

09 Jul '09

Hi, I suppose this is mostly addressed to Ion. It appears that containers in the move library in the boost sandbox can't coexist with containers from the boost.interprocess library. This isn't a problem for me currently (I can just use the containers from the move library), but it may be an indication of a larger problem with either or both libraries, so I figured it'd be worth sharing. I wasn't sure if this would be an appropriate trac ticket to file under boost.interprocess, as it involves technically non-boost code, but I can certainly do that if desired. So to be specific, the following program fails to compile (MSVC 2009, boost 1.39, include paths are boost root and $(BOOST_SVN)/boost-sandbox/move): -------- #include <boost/interprocess/containers/vector.hpp> #include <boost/container/vector.hpp> int main(int argc, char* argv[]) { boost::interprocess::vector< int > v1; // line 6 boost::container::vector< int > v2; // line 7 return 0; } -------- The compiler output is: -------- 1>.\main.cpp(7) : error C3083: 'container': the symbol to the left of a '::' must be a type 1>.\main.cpp(7) : error C2039: 'vector' : is not a member of 'boost' 1>.\main.cpp(7) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(7) : error C2062: type 'int' unexpected -------- Removing either the interprocess vector (include directive, variable declaration) pair or the move vector (include directive, variable declaration) pair produces a compilable program. Reversing the order of the include directives gives a different compiler error: -------- 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C3083: 'interprocess_container': the symbol to the left of a '::' must be a type 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2039: 'vector' : is not a member of 'boost' 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2873: 'vector' : symbol cannot be used in a using-declaration 1>.\main.cpp(6) : error C2039: 'vector' : is not a member of 'boost::interprocess' 1>.\main.cpp(6) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(6) : error C2062: type 'int' unexpected -------- Any idea what's going on here? Am I just doing something really boneheaded, e.g., with the include paths? Additionally, I have a small suggestion for the move library. It would be somewhat more convenient if boost::is_movable<T> had a nested type typedef, e.g., if it inherited from mpl::bool_<...> or integral_constant< bool, ...>. As it stands, I don't think it can be used directly in MPL expressions such as mpl::and_. Thanks in advance, - Jeff

2 1

[Tuple] Addressing by named tag?
by Robert Jones 09 Jul '09

09 Jul '09

Am I correct in believing that tuples have to be accessed by element index, as in tuple.get<0>() Multi-Index container has a really nice facility to use named (well typed really) tags in these kind of expressions, but it seems tuples do not. Anyone fancy adding it to tuple? - Rob.

2 1

[convert] coversion between strings with different locales
by vicente.botet 09 Jul '09

09 Jul '09

Hi, I wanted to see how we can convert a double from a locale to another locale? Should I write double d =convert<string>::from(convert<double>::from(str)(_locale=f))(_locale=t); or I need double d = convert<double>::from(str)(_locale=f); convert<string>::from(d)(_locale=d); Or it si a better way? Best, _____________________ Vicente Juan Botet Escribá

2 3

[multi_array] Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro
by John Reid 08 Jul '09

08 Jul '09

Defining BOOST_DISABLE_ASSERTS disables boost asserts over the entire compilation. It would be nice to have finer grained control over the range checking in multi_array via a boost.multi_array specific macro.

1 1

[Graph] component_index crash on big graph
by Sandeep Gupta 08 Jul '09

08 Jul '09

Hi, I am using the incremental connected component + component_index to find connected components in an undirected graph. However the program works fine on small small dataset but segfaults on large input. I tried to do some debugging and the best I could come up was that it fails on array_push_front cal at the boost/graph/detail/incremental_component.hpp:78. I have attached the source code and the accompanying small files that contain edgelist. The TrivialEdges.txt works fine but on ManyEdges.txt* the program segfaults. To the best of my understanding the input is sane. Would appreciate any help. * ManyEdges.txt is 320K so please download it from (* http://tinyurl.com/m9blyy) * THis is the dataset I stumbled upon. I apologies for not being able to trim down to smaller size. thanks sandeep

3 7