- Boost - lists.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