October 2007 - Boost-users - lists.preview.boost.org

Boost cookbook site (alpha)
by Kirit Sælensminde 03 Oct '07

03 Oct '07

I've spent the weekend putting together a cookbook site. I hope nobody minds. People can explore and play with it at http://www.boostcookbook.com/ Any problems, issues or suggestions can be reported at http://www.boostcookbook.com/Site:/Issues Apart from a couple of ASP pages using JavaScript the site is in C++ and makes heavy use of Boost :) Kirit

10 19

Reproducible access violation on win64 with signals (example code)
by Nicholas Bastin 02 Oct '07

02 Oct '07

I've managed to get my signals access violation to happen in a relatively simple test program on win64. I'm attaching my example source code to this email. If anyone needs anything else to reproduce the problem, please let me know. This program works when statically linked, but not when dynamically linked, so if someone can spot a bad compiler/linker flag, that would help too. I built boost with: bjam --toolset=intel address-model=64 link=shared runtime-link=shared --with-signals stage Also, I had to edit intel-win.jam to change icc.exe to icl.exe so that the compiler would run properly. I built my test application with: icl /EHsc /MD /I. test.cpp /link /subsystem:console /LIBPATH:stage\lib /NODEFAULTLIB /ENTRY:mainCRTStartup /FORCE:multiple boost_signals-iw-mt-1_34.lib msvcprt.lib msvcrt.lib libirc.lib libmmd.lib If you build with static linkage (obviously, rebuild boost without the shared link settings), the executable works fine (with libboost_signals-iw-mt-1_34.lib). -- Nick

1 0

statechart - time event...implementation ?
by Raja Cherukuri 02 Oct '07

02 Oct '07

It seems the current implementation of statechart library does not have timed event. It is possible to extend or specialize the current event<> class to achieve this ? Has anyone done this yet ? Looks like a common requirement for this type of event. Any reason why it is not part of this library offering ? Is it expected that users of this library do it themselves ? Thanks in advance. - Raja

2 3

Using boost (maybe mpl?) to generalize a switch statement to call different template functions
by Peng Yu 02 Oct '07

02 Oct '07

Hi, I have the following program, which uses a switch statement to call different template functions. The example is simple, but as the number of shapes increase, the switch statement might be very hard to maintain. I'm looking for a more general solution (maybe using mpl, not sure), such that the switch statement can be automatically generated, therefore, more maintainable. Thanks, Peng #include <iostream> enum shape { circle, square // there might be many cases }; template <shape, shape> struct A { void doit() const; }; //doit functions are defined for a majority number of shape combinations (maybe not all, but could be defined for all---the bodies of the functions not need can be empty). // 3 case. There should be 4 doit's if we consider all combinations. template <> void A<circle, circle>::doit() const { std::cout << "circle circle" << std::endl; } template <> void A<circle, square>::doit() const { std::cout << "circle square" << std::endl; } template <> void A<square, circle>::doit() const { std::cout << "square circle" << std::endl; } void f(shape s1, shape s2) { // each defined shape-combination corresponds to one case // I want to generalize the code by using boost::mpl // (or some other packages if applicable) switch(s1 << 8 | s2) { case circle << 8 | circle: A<circle, circle>().doit(); break; case circle << 8 | square: A<circle, square>().doit(); break; case square << 8 | circle: A<square, circle>().doit(); break; default: std::cout << "not defined" << std::endl; } } int main() { f(circle, circle); f(circle, square); f(square, circle); f(square, square); }

3 3

[signals] call a slot only once
by Christian Holmquist 02 Oct '07

02 Oct '07

Hello, Is there a way to automatically have a slot disconnected after it has been called once, without managing the connection manually? void f() { } signal<void()> sig; sig.connect(&f); sig(); // f gets called sig(); // f shouldn't get called

2 4

Usage of iterator_facade and iterator_adaptor
by Peng Yu 02 Oct '07

02 Oct '07

Hi, I'm trying to use Boost.Iterator library. I understand that iterator_adaptor specialize some part of iterator_facade. However, I can not tell for what application I should use iterator_facade or iterator_adaptor. I think the manual should summarize this for the user. Can somebody give me some hint on which to use them and under what condition, if you have the experience? Thanks, Peng

2 1

[boost::enable_shared_from_this] in inheritance tree throws bad_weak_ptr exception
by dariomt＠gmail.com 02 Oct '07

02 Oct '07

I need to create a class hierarchy where every level inherits from boost::enable_shared_from_this. I am having problems caused, I believe, by having more than one copy of enable_shared_from_this. I am using boost 1.34.1 with VS2003 and VS2005, with and without ICL9.1, always getting the same result: a boost::bad_weak_ptr exception. #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> using namespace boost; struct A : enable_shared_from_this<A> { shared_ptr<A> getA() {return enable_shared_from_this<A>::shared_from_this();} }; struct B : A, enable_shared_from_this<B> { shared_ptr<B> getB() {return enable_shared_from_this<B>::shared_from_this();} }; int main() { shared_ptr<A> pA (new A); pA->getA(); // this works OK shared_ptr<B> pB (new B); pB->getB(); // throws boost::bad_weak_ptr() !? return 0; } question 1: Is this expected or am I doing something wrong? question 2: If it is expected: is it possible to have it explained in the documentation? question 3: Is there a way to accomplish this (inheritance with shared_from_this in all levels) using enable_shared_from_this? Thanks in advance

3 3

[Process] getcwd memory leak in context.hpp
by Chris Fairles 02 Oct '07

02 Oct '07

Valgrinding the single_process_tutorial example, it seems getcwd in context.hpp is called with a NULL buffer and 0 size meaning that space is automagically malloc'd (according to POSIX.1-2001). ==10383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==10383== malloc/free: in use at exit: 64 bytes in 1 blocks. ==10383== malloc/free: 32 allocs, 31 frees, 22,225 bytes allocated. ==10383== For counts of detected errors, rerun with: -v ==10383== searching for pointers to 1 not-freed blocks. ==10383== checked 162,760 bytes. ==10383== ==10383== 64 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==10383== at 0x4A0590B: realloc (vg_replace_malloc.c:306) ==10383== by 0x39848C03FC: getcwd (in /lib64/libc-2.5.so) ==10383== by 0x407894: boost::process::basic_work_directory_context<std::string>::basic_work_directory_context() (context.hpp:85) ==10383== by 0x407A19: boost::process::basic_context<std::string>::basic_context() (context.hpp:142) ==10383== by 0x403730: main (single_process_tutorial.cpp:44) ==10383== ==10383== LEAK SUMMARY: ==10383== definitely lost: 64 bytes in 1 blocks. I think the memory should be free()'d if the returned buf isnt NULL (or create a buffer isntead of passing NULL,0). Chris

1 0

identical boost expression used in different parts of the code - looking for an alias
by e r 02 Oct '07

02 Oct '07

hi for example, i use boost::bind( &A::f, _1 ) in different parts of my code. how can i define an alias for this expression? i'm thinking of using something like some_type* fo = new boost::bind(&A::f,_1); and use *fo in place of boost::bind(...). is this crazy? what should some_type be?

3 3

boost::shared_ptr and "this"-pointer: how to use shared_from_this?
by Taneli R. 02 Oct '07

02 Oct '07

I'm converting pipes and filters architecture made with raw pointers to use shared_ptrs. My Pipe class has a static counter, which gives unique pipeID to every pipe. Since Pipe class has pure virtual functions, the pipes in my architecture are instances of derived classes. Pipe class looks like this: class Pipe { public: Pipe() : pipeID(++pipeCount) {} virtual bool lay(boost::shared_ptr<Pipeable>& source, string& sourceTag, boost::shared_ptr<Pipeable>& destination, string& destTag) = 0; /*...other pure virtual functions here...*/ protected: int pipeID; static int pipeCount; } My problem is that when I try to make a new pipe between source and destination, the pipe is made twice (with different pipeID-numbers), which is a problem because there should be only one pipe connecting my components. I believe it is a result from using "this"-pointer directly without enabling "shared_from_this". I know that I should use it somehow but the same time I should maintain the unique pipeID. If I create a new shared_ptr with "shared_from_this" enabled inside SimplePipe, it has a different pipeID than the one I should be using. I have to use shared_ptr because I'm storing pointers into containers. And finally I cannot instantiate Pipe directly from its base class with using "shared_from_this" because it has pure virtual functions. Any help for solving this problem or a decent tutorial on using shared_ptrs and enable_shared_from_this would be appreciated. The following code snippets illustrate the problem: // //Main // boost::shared_ptr<Pipe> pipe; pipe = inputPipes[tag]; //find a matching pipe from the map if (pipe.get() == 0) //if not found, create a new pipe { boost::shared_ptr<Pipeable> source; // no source boost::shared_ptr<Pipeable> destination (boost::dynamic_pointer_cast<Pipeable>(comp)); pipe = boost::shared_ptr<Pipe>(new SimplePipe(source, srcTag, destination, destTag)); //creating new pipe inputPipes[tag] = pipe; //put the pipe into a map } // //SimplePipe, derived from Pipe // SimplePipe::SimplePipe(boost::shared_ptr<Pipeable>& source, string& sourceTag, boost::shared_ptr<Pipeable>& destination, string& destTag) { lay(source, sourceTag, destination, destTag); } bool SimplePipe::lay(boost::shared_ptr<Pipeable>& source, string& sourceTag, boost::shared_ptr<Pipeable>& destination, string& destTag) { if (source.get() != 0 && destination.get() != 0 && !sourceTag.empty() && !destTag.empty()) //Both ends attached { if (source->makeSource(pipeID, sourceTag)) { this->source = source; //problem? if (destination->makeDestination(pipeID, destTag)) { this->destination = destination; //problem? return true; } else { source->detachPipe(pipeID); } } } else if (source.get() == 0 && destination.get() != 0 && !destTag.empty()) //only destination attached { if (destination->makeDestination(pipeID, destTag)) { this->destination = destination; //problem? return true; } } else if (source.get() != 0 && destination.get() == 0 && !sourceTag.empty()) { /*etc etc...*/ } return false; } -- View this message in context: http://www.nabble.com/boost%3A%3Ashared_ptr-and-%22this%22-pointer%3A-how-t… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1