- Boost-users - lists.boost.org

Re: [Boost-users] boost::mpl::set and boost::mpl::sort -- does not compile -- any help appreciated
by peter_foelsche＠agilent.com 17 Oct '08

17 Oct '08

I found the answer meanwhile. Peter #include <boost/mpl/set.hpp> #include <boost/mpl/sort.hpp> #include <boost/mpl/inserter.hpp> #include <boost/mpl/insert.hpp> #include <boost/mpl/placeholders.hpp> #include <boost/mpl/front.hpp> #include <boost/mpl/deref.hpp> #include <boost/mpl/for_each.hpp> #include <iostream> typedef boost::mpl::set< boost::mpl::int_<1>, boost::mpl::int_<5>, boost::mpl::int_<3>, boost::mpl::int_<0> > CSet; typedef boost::mpl::inserter< boost::mpl::set<>, boost::mpl::insert<boost::mpl::_1, boost::mpl::_2> > CInserter; typedef boost::mpl::sort< CSet, boost::mpl::less< boost::mpl::_1, boost::mpl::_2 >, CInserter >::type COrderedSet;

1 0

boost::mpl::set and boost::mpl::sort -- does not compile -- any help appreciated
by peter_foelsche＠agilent.com 17 Oct '08

17 Oct '08

Somehow I need an ordered set. How to do this? Any help appreciated. Peter #include <boost/mpl/set.hpp> #include <boost/mpl/sort.hpp> typedef boost::mpl::sort< boost::mpl::set< boost::mpl::int_<1>, boost::mpl::int_<5>, boost::mpl::int_<3> > >::type CFirstSet; int main(int argc, char **argv) { CFirstSet s; } "The first point (using an init() function in preference to a constructor) is bogus. Using constructors and exception handling is a more general and systematic way of dealing with resource acquisition and initialization errors. This style is a relic of pre-exception C++." -- Stroustrup

1 0

[Thread] Bug in 1.35.0 and 1.36.0 timed wait code.
by Ross Wightman 17 Oct '08

17 Oct '08

I posted this shortly after the 1.36.0 release but I neglected to put the [thread] tag in the subject. Since I noticed 1.37 is already being finalized I figured I'd post again. There is a bug in the get_due_time(...) function in lib/src/win32/thread.cpp line 343 when boost::date_time is setup to have nanosecond resolution. The integer division always results in a due_time of 0 so the timed waits never wait. I fixed my local copy by changing the order of operations but I haven't investigated to see if this could cause an overflow in situations where nanosecond time resolution has not been configured. In general I question whether it was a good idea to have the threading library depend on date_time? There is a lot of functionality and code in date_time that the thread library doesn't need. The C++0x standard suggests a much simpler system_time class. While there is overlap between such a system_time class and the date_time class, the smaller compile time / code size costs and lower chance of bugs when only using the threading library seems worth it. Regards, Ross

1 0

Difficulty compiling - ASIO/BIND
by David 17 Oct '08

17 Oct '08

Hi, I'm trying to use asio, and I run into a compiler error when using async_connect. I don't think this is an asio issue, perhaps a compiler or bind issue. Errors and code snippet below. I'm perplexed by the error, as apparently the compiler can't if 'this' should be passed as a pointer, or by reference. I also tried alternate syntax using bind and mem_fn as mentioned in the bind docs, but that gave exactly the same error. What's causing this error, and what can I do to fix it? using gcc 4.2.3: .../boost_1_36_0/boost/bind.hpp:292: error: no match for call to ‘(boost::_mfi::mf1<void, Connection, boost::system::error_code&>) (Connection*&, boost::asio::error::basic_errors&)’ .../boost_1_36_0/boost/bind/mem_fn_template.hpp:160: note: candidates are: R boost::_mfi::mf1<R, T, A1>::operator()(T*, A1) const [with R = void, T = Connection, A1 = boost::system::error_code&] .../boost_1_36_0/boost/bind/mem_fn_template.hpp:179: note: R boost::_mfi::mf1<R, T, A1>::operator()(T&, A1) const [with R = void, T = Connection, A1 = boost::system::error_code&] //code class Connection { public: //... void onConnected(boost::system::error_code&); //... }; _socket.lowest_layer().async_connect(*_epit, boost::bind(&Connection::onConnected, this, placeholders::error));

2 1

Collections versus std::map
by Benson Margulies 17 Oct '08

17 Oct '08

I'm looking for a fast sparse array that permits ordered traversal of the occupied slots. std::map is much too slow. boost multi-index with a sequenced index on an unsigned int is significantly slower even that the std::map, which isn't too surprising given the writeup. Is there something else in boost that fills this space?

2 3

serialize a template class working with MSVC2005 but not gcc
by professor rumsdiegeige 17 Oct '08

17 Oct '08

Hello, I've got the following class definition: template< class T > class ProxyClass { boost::ptr_vector<T> &e_; ProxyClass( boost::ptr_vector<T> &f ) : e_(f) {;}; template<class Archive> void save(Archive & ar, const unsigned int version) const { size_t o=0; boost::ptr_vector< T >::iterator it = e_.begin(); /*for ( ; it != e_.end(); ++it, ++o ) { const T &t = *( it ); ar & t; }*/ } }; Where it says "boost::ptr_vector< T >::iterator it", the gcc compiler on Linux complains "error: expected ';' before 'it'", while Visual Studio 2005 compiles it fine without any errors. What can I do here? Thanks in advance for your help! S. Lorentz __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

cpp code and Boost.Interprocess compile error
by hamsinv 17 Oct '08

17 Oct '08

Hello All, I was looking for using stl maps in shared memory, when i came across Boost library. I have downloaded boost_1_36_0 version. In the examples directory, there is a cpp file for sharing stl maps named doc_map.cpp. When i compile the same with the following command: c++ -I $BOOST_ROOT doc_map.cpp -o shmmap I got the following errors: /tmp/ccEYJnov.o: In function `boost::interprocess::shared_memory_object::priv_open_or_create(boost::interprocess::detail::create_enum_t, char const*, boost::interprocess::mode_t)': doc_map.cpp:(.text._ZN5boost12interprocess20shared_memory_object19priv_open_or_createENS0_6detail13create_enum_tEPKcNS0_6mode_tE[boost::interprocess::shared_memory_object::priv_open_or_create(boost::interprocess::detail::create_enum_t, char const*, boost::interprocess::mode_t)]+0x163): undefined reference to `shm_open' /tmp/ccEYJnov.o: In function `boost::interprocess::detail::mutexattr_wrapper::mutexattr_wrapper(bool)': doc_map.cpp:(.text._ZN5boost12interprocess6detail17mutexattr_wrapperC1Eb[boost::interprocess::detail::mutexattr_wrapper::mutexattr_wrapper(bool)]+0x14): undefined reference to `pthread_mutexattr_init' doc_map.cpp:(.text._ZN5boost12interprocess6detail17mutexattr_wrapperC1Eb[boost::interprocess::detail::mutexattr_wrapper::mutexattr_wrapper(bool)]+0x2b): undefined reference to `pthread_mutexattr_setpshared' doc_map.cpp:(.text._ZN5boost12interprocess6detail17mutexattr_wrapperC1Eb[boost::interprocess::detail::mutexattr_wrapper::mutexattr_wrapper(bool)]+0x4d): undefined reference to `pthread_mutexattr_settype' /tmp/ccEYJnov.o: In function `boost::interprocess::detail::mutexattr_wrapper::~mutexattr_wrapper()': doc_map.cpp:(.text._ZN5boost12interprocess6detail17mutexattr_wrapperD1Ev[boost::interprocess::detail::mutexattr_wrapper::~mutexattr_wrapper()]+0xd): undefined reference to `pthread_mutexattr_destroy' /tmp/ccEYJnov.o: In function `boost::interprocess::shared_memory_object::remove(char const*)': doc_map.cpp:(.text._ZN5boost12interprocess20shared_memory_object6removeEPKc[boost::interprocess::shared_memory_object::remove(char const*)]+0x33): undefined reference to `shm_unlink' collect2: ld returned 1 exit status Can anyone please tell me what i'm missing in the compilation. Thank you. -- View this message in context: http://www.nabble.com/cpp-code-and-Boost.Interprocess-compile-error-tp20012… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3

boost::numeric::interval - what are interval_holder and number_holder for?
by Stephan Puchegger 17 Oct '08

17 Oct '08

Dear boost members! Perhaps the main boost developer mailing list would be the better place to ask this question, but I'll try it here first: I cannot find any references to interval_holder and number_holder, which are defined in boost/numerics/interval/interval.hpp in any other files of the boost library. Are those two structures deprecated remains of a previous boost release? (The last time I checked they were still in trunk of the svn repository.) regards Stephan

1 0

[format] crash on windows / inquiry
by Tore Halvorsen 17 Oct '08

17 Oct '08

Hi, I just wondering about two things with the format library. 1) The following program crashes on windows - is this intentional? #include <boost/format.hpp> int main(int argc, char* argv[]) { boost::format f("%s %s"); f.exceptions(boost::io::no_error_bits); // not needed, but just in case char const* null_cstr = 0; char const* empty_cstr = ""; f % empty_cstr; // triggers debug assertion failure f % null_cstr; // triggers access violation return EXIT_SUCCESS; } The debug assertion failure only happens on a debug build, of course. I can understand the access violation on a null string, but that feature makes it unsuitable for a sprintf replacement. 2) Is there a way to determine the number of expected arguments in a format object? Looks like the basic_format::num_args_ is exactly what I'm looking for, but I can't find this exposed anywhere. Going through a loop and catching exceptions is one way of getting the number of expected arguments, but it feels wrong. -- Eld på åren og sol på eng gjer mannen fegen og fjåg. [Jøtul] <demo> 2008 Tore Halvorsen || +052 0553034554

1 0

shared_ptr singleton
by Alessandro Re 17 Oct '08

17 Oct '08

Hello, I'm getting some troubles with shared_ptr when trying to implement a singleton pattern. Actually, it's not the singleton itself (which seems to work, in a separate program), but in the context I need it, doesn't work. I tried to figure out why (and actually I found an alternative implementation which works), but still I'm trying to understand what goes wrong. I'm trying to do this: having a hierarchy of classes where there is one Base class and a number of derived ones, each class is in a different cpp file. All these classes must be registered in a Register class, which is itself derived from Object. Register is the singleton, implemented like this: class Register; typedef shared_ptr<Register> RegisterP; class Register: public Object { public: Register(); void add(string name) { // Stuff with name } static RegisterP global() { if (!_global) _global = RegisterP(new Register); // * return _global; } private: static RegisterP _global; }; To register the various classes, does exist a special class, not in hierarchy, like this: class ClassRegisterer { public: ClassRegisterer::ClassRegisterer(string name) { Register::global()->register(name); // ** } } #define REGISTER(C) ClassRegisterer _registerClass_ ## C ( #C) In each file of the of the project, this macro is used when a class is created: Foo.cpp class Foo: public Object {...}; REGISTER(Foo); Bar.cpp class Bar: public Object {...}; REGISTER(Bar); This is also used for the Register class itself: Register.cpp class Register: public Object {...}; REGISTER(Register); The problem is that global() is called N times, but the new Register (*) is executed twice, instead of once. Investigating with some couts, I found out that - dunno why - the pointer _global is set to 0 after the first execution, in fact at the time of second execution it's created another object, which isn't deleted and is kept. Trying quickly with a debugger, it seems that at (**) a destructor for shared_ptr is called, and I think that it may be the cause of the issue, but I'm having an hard time figuring this out and *why* a destructor is called (maybe it's just for a temporary object). Looking at boost docs, i found out this: http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/sp_techniques.html#stat… so I tried to use that null deleter, like this: struct nullDeleter { void operator()(void const *p) const { cout << "Trying to delete " << p << endl; } }; and used like: if (!_global) _global = RegisterP(new Register, nullDeleter()); The problem is that this is never called! The object is never destroyed by this, but somehow the static _global is set to 0 (only once), and thus allocated twice. I temporary solved this using a static raw pointer, which is allocated once and a shared_ptr is built with it: class Register { ... static RegisterP global() { if (!_global) _global = new Register; return RegisterP(_global, nullDeleter()); } ... static Register *_global; }; Which works. Any suggestion is welcome :) Thanks -- ~Ale

4 6