April 2006 - Boost - lists.preview.boost.org

Re: [boost] [statechart] - BOOST_ASSERTION in state_machine::send_eventif used by multiple threads
by Oliver.Kowalke＠infineon.com 19 Apr '06

19 Apr '06

Same happens if I install a exception_translator in the enclosing state: /opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: void boost::statechart::state_machine<MostDerived, InitialState, Allocator, ExceptionTranslator>::send_event(const boost::statechart::event_base&) [with MostDerived = iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = std::allocator<void>, ExceptionTranslator = boost::statechart::exception_translator<boost::statechart::exception_thr own>]: Assertion `get_pointer( pOutermostUnstableState_ ) == 0' failed. >Hello, >I've several threads running. Each thread has its own state_machine. >Sometime (not reproducible) I get following assertion: > >/opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: >void boost::statechart::state_machine<MostDerived, InitialState, >Allocator, ExceptionTranslator>::send_event(const >boost::statechart::event_base&) [with MostDerived = >iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = >iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = >std::allocator<void>, ExceptionTranslator = >boost::statechart::null_exception_translator]: Assertion `get_pointer( >pOutermostUnstableState_ ) == 0' failed.

1 0

[statechart] - BOOST_ASSERTION in state_machine::send_event if used by multiple threads
by Oliver.Kowalke＠infineon.com 19 Apr '06

19 Apr '06

Hello, I've several threads running. Each thread has its own state_machine. Sometime (not reproducible) I get following assertion: /opt/boost/include/boost-1_33_1/boost/statechart/state_machine.hpp:833: void boost::statechart::state_machine<MostDerived, InitialState, Allocator, ExceptionTranslator>::send_event(const boost::statechart::event_base&) [with MostDerived = iris::proto::svc::sm<ogx::net::ipv4::stream>, InitialState = iris::proto::svc::proto<ogx::net::ipv4::stream>, Allocator = std::allocator<void>, ExceptionTranslator = boost::statechart::null_exception_translator]: Assertion `get_pointer( pOutermostUnstableState_ ) == 0' failed. What does get_pointer( pOutermostUnstableState_ ) != 0' indicate? Regards, Oliver

1 0

Re: [boost] Compile tests for headers
by João Abecasis 19 Apr '06

19 Apr '06

Emil Dotchevski wrote: > I need to test each header in my libs, to make sure that it compiles without > errors when included as the first header in a CPP. What is the easiest way > to accomplish this? > > I was thinking of writing a simple tool which takes the command line for the > complier, generates a CPP file which includes the specified header and then > runs the compiler, however this would have to interface somehow with > boost-build, to get the command line (depending on the toolset used, and the > configuration), and I don't know how to do that. > > Any suggestions? Incidentally, just yesterday I finally ported to bjam+BBv2 a shell script I've been using for the same purpose. See attached. You should put headers.jam file in the same directory as your Jamfile[.v2] or somewhere where Boost.Build can find it (e.g., in BOOST_BUILD_PATH). For example, to test the compilation of Boost.Spirit headers, in (boost-root)/libs/spirit/test/Jamfile.v2 one could have: import headers ; import testing ; test-suite "spirit.headers" : [ headers ../../../boost/spirit ] ; At this point the code is the documentation, but I added some comments explaining each function's purpose. Perhaps this, or something along the lines of it, could be added to the regression tests, to ensure that all headers compile independently. FWIW, my former bash script used to report lots of non-compilable files inside boost. What do others think about this? I'd like to hear your comments on the approach and implementation, as well as bug reports ;-) Best regards, João

1 0

Boost::any operator==
by Jorge Lodos 18 Apr '06

18 Apr '06

Hi It would be nice if operator== could be added to boost::any. A partial solution would be the following: template<typename ValueType> bool operator==(const ValueType & rhs) const { return content ? content->equal(any(rhs).content) : content == any(rhs).content; } bool operator==(const any &rhs) const { return content && rhs.content ? content->equal(rhs.content) : content == rhs.content; } equal is a pure virtual member of placeholder declared as: virtual bool equal(const placeholder *rhs) const = 0; and implemented as (in holder): virtual bool equal(const placeholder *rhs) const { return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } However, this will break existing code when the holded object class does no have operator== defined. Kevlin Henney proposed: namespace equality { template<typename Type> bool operator==(const Type &lhs, const Type &rhs) { return &lhs == &rhs; } } virtual bool equal(const placeholder *rhs) const { using namespace equality; return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } Thus providing a default operator== for everyone not having its own, which returns true if the object addresses are the same. This will prevent compiler errors when the operator== really needed to be there. What I think is needed is: 1. If operator== is not used there should be no need for holded classes to implement it. 2. If operator== is used, and the holded class does not define it, the code must not compile. Do you think this is possible to implement? Thanks in advance Jorge Lodos

5 7

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 18 Apr '06

18 Apr '06

Doug Gregor wrote: > On Apr 10, 2006, at 3:58 AM, Reece Dunn wrote: > > In terms of C++0x features, what is the current state of lambda > > support as I have > > seen several papers from Bjarne, et. al.? > > I don't think being the fourth of five authors on one lambda proposal > counts as "Bjarne et. al." :) I could only remember Bjarne as being one of the people involved with a wg21 paper on Lambda from www.open-std.org. Maybe I should have said Doug et. al. :) > The driving forces behind lambdas for C++0x are Jeremiah Willcock, > Jaakko Jarvi, and Valentin Samko. I'll keep an eye out for papers from them. > The lambda proposals are still in > an early state of development and will take a couple months to > mature. There are many unanswered questions about the scope of > lambdas (how much can/should they express?), various design features > (polymorphic vs. monomorphic, how to handle references to local > variables), etc. I have no doubt the authors will spiral in on the > right solution, but they could certainly use more feedback. Sure. I am interested in Lambda functions and have knowledge of Haskell (and more recently Python :)) and the Boost.Phoenix/Lambda libraries. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

19 43

Re: [boost] [intrusive_ptr] atomic ref counting?
by David Maisonave 18 Apr '06

18 Apr '06

"Eric Niebler" <eric(a)boost-consulting.com> wrote in message news:<443FF065.9020809(a)boost-consulting.com>... > > I'm thinking about replacing some uses of shared_ptr with > intrusive_ptr, > but I've got questions. One of the nice things about shared_ptr is the > lock-free thread-safe ref counting. I want my intrusive_ptr to have the > same safety and efficiency, but I don't see how to get it. I see > $boost_root/detail/atomic_count.hpp, but shared_ptr doesn't use it. Why > not? And why is it in detail/? Should I not consider using it? > > Taking in the bigger picture, intrusive_ptr requires people to write > their own add_ref and release functions, most of which will probably end > up using ++ and -- on a plain integer. This is totally broken in > multi-threaded applications, right? Isn't it dangerous to not provide > complementary utilities for correctly managing reference counts? It > seems to me intrusive_ptr is impossible to use safely and portably. What > have I missed? Check out the policy base smart pointer class in the following link: http://axter.com/smartptr/ This smart pointer uses an intrusive_lock_policy to synchronize both intrusive and non-intrusive smart pointers. Although intrusive_lock_policy uses intrusive logic, it still can work with any type by using the mutex_wrapper class. http://axter.com/smartptr/classmutex__wrapper.htm http://axter.com/smartptr/structintrusive__lock__policy.htm The mutex_wrapper class adds intrusive logic to any type. I believe the same can be done to the boost::intrusive_ptr class. It shouldn't be that hard to add a wrapper-class to boost that would give intrusive logic to any type. Example usage: boost::intrusive_ptr<intrusive_wrapper<vector<int> > > spVect = new boost::intrusive_wrapper<vector<int> >(); See following link for mutex_wrapper implementation: http://axter.com/smartptr/sync__wrapper_8hpp-source.htm

1 0

Property tree rev.5
by Marcin Kalicinski 18 Apr '06

18 Apr '06

Property tree library revision 5 (review version) is now in the boost vault. Documentation can be viewed online at http://kaalus.atspace.com/ptree Major changes since revision 4: - basic_ptree no longer templated on character type, now templated on key type instead - get_b functions removed - get_o functions renamed get_optional - get_d functions renamed get, (resolution with throwing get through overloading) - enhancements to cmdline_parser - added more regression tests - updated docs and examples Marcin

8 8

Program Options: Allow long options without -- prefix?
by Olaf van der Spek 18 Apr '06

18 Apr '06

Hi, Is it possible to allow long options without -- prefix? The code doesn't seem to support it, but I think it's handy in cases where positional options aren't used.

1 0

[multi_index] Problems with chained pointers in multi index from 1.34 RC
by Alexei Alexandrov 18 Apr '06

18 Apr '06

Hi, my multi_index use case: * The container contains not objects themselves, but pointers (shared_ptr-s). * The objects are noncopyable - they are created by a factory and only smart pointers are copied between clients. * The container has 2 indexes. Indexes are built on const_mem_fn extractor. One of the indexes uses a function from a base class. It seems that in 1.34 problem with using member function from a base class is supposed to be solved, but it causes a regression that you cannot have pointers to noncopyable objects in the container. Is this a known issue? My compiler is MSVC 7.1/Intel Compiler 9.0. Here is a code snippet to demonstrate the problem. This code compiles well with boost 1.33.1, but fails to compile with RC 1.34. If you uncomment the second index, it won't compile neither with 1.33 nor with 1.34. #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/shared_ptr.hpp> #include <boost/noncopyable.hpp> #include <iostream> #include <string> using namespace boost::multi_index; /* A name record consists of the given name (e.g. "Charlie") * and the family name (e.g. "Brown"). The full name, calculated * by name_record::name() is laid out in the "phonebook order" * family name + given_name. */ class base_record : boost::noncopyable { public: int get_id() const { return id_; } protected: base_record() : id_(0) {} private: int id_; }; class name_record : public base_record { public: typedef boost::shared_ptr<name_record> Ptr; static Ptr create() { return Ptr(new name_record()); } const std::string & name() const { return name_; } protected: name_record() : name_("") {} private: std::string name_; }; typedef multi_index_container< name_record::Ptr, indexed_by< ordered_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(name_record, const std::string &, name) /**/> // , // ordered_unique< // BOOST_MULTI_INDEX_CONST_MEM_FUN(base_record, int, get_id) // > /**/> /**/> name_record_set; int main() { name_record_set ns; ns.insert(name_record::create()); return 0; }

2 4

[program_options] PATCH: fix VC8 runtime assertion error in options_description.cpp
by Trent Nelson 18 Apr '06

18 Apr '06

Hi, With regards to the following lines in the latest version (1.16) of program_options's options_description.cpp: 395: line_end = line_begin + line_length; 396: if (line_end > par_end) 397: { 398: line_end = par_end; 399: } Line 395 causes VC8 to throw a runtime assertion error when processing the last line of a multiline option description. This is because 'line_begin + line_length' will exceed the actual length of the string, and it seems VC8 is pretty intent on not letting that happen, despite the fact we correct it in following line. Following patch did the trick for me: --- options_description-1.16.cpp 2006-04-18 02:39:51.401147200 +0100 +++ options_description.cpp 2006-04-18 03:04:05.722358400 +0100 @@ -390,13 +390,13 @@ } } - string::const_iterator line_end; + string::const_iterator line_end = line_begin; + unsigned remaining = unsigned(distance(line_begin, par_end)); - line_end = line_begin + line_length; - if (line_end > par_end) - { - line_end = par_end; - } + // line_end will be determined by either the end of the + // current paragraph (remaining), or the current line + // length, which ever is less. + line_end += ((remaining < line_length) ? remaining : line_length); // prevent chopped words // Is line_end between two non-space characters?

2 1