September 2002 - Boost-users - lists.preview.boost.org

boost.python overloading to_python
by dkottowk 04 Sep '02

04 Sep '02

hi, please consider the following example class A { public: A() {} A(const A& a) {} }; class A2 : public A { public: A2() : A() {} A2(const A2& a2) : A(a2) {} }; class B { public: const A& getA(); //returns refs to A or A2 }; now, when exposing this in boost, i would always get A's when calling B::getA() from python, which i understand, since AFAIK the copy Ctors are used to instantiate the python object. to overcome this i wrote: PyObject *to_python(const A &a) { if (dynamic_cast<A2*>(&a)) { return to_python::((const A2 &)a);//done by class_builder<A2> } else { //HOW DO I CALL THE IMPL DONE BY class_builder<A> ? return 0; } } which works fine, except that i dont know how to resort to the automatic implementation for PyObject *to_python(const A& a) provided by the class builder for A. any help is greatly appreciated. greetings, daniel

1 0

thread link problem with STLport
by Sam Partington 04 Sep '02

04 Sep '02

Hi, I'm trying to link an app using boost threads and stlport on gcc 2.95(linux), and its coming back with an undefined reference: Debug/threadex.o: In function `threadex::go(void)': .../threadex.cpp:37: undefined reference to `boost::thread::thread(boost::function0<void, boost::empty_function_policy, boost::empty_function_mixin, allocator<boost::function_base> > const &)' and the offending code is new boost::thread(threadex_caller(this)); where theadex_caller looks like this struct threadex_caller { threadex_caller(threadex*); void operator()(); }; I think the problem is the allocator template parameter of boost::function0, a clue is given if I don't link against the pthread library, I get the following undefined reference (amongst others) Debug/libboost_thread.a(thread.o): In function `boost::thread::thread(boost::function0<void, boost::empty_function_policy, boost::empty_function_mixin, _STL::allocator<boost::function_base> > const &)': .../src/thread.cpp:112: undefined reference to `pthread_create' where you can see that the thread::thread function expects a function0 with an _STL::allocator<>, not a plain allocator<> I also think that the problem is that the thread.hpp isn't getting the namespace mapping function, but why? TIA Sam

1 0

boost::function map with different return types
by Julia Donawald 04 Sep '02

04 Sep '02

Hi, I have the following code: --------------- #include <boost/bind.hpp> #include <boost/function.hpp> #include <map> #include <string> class Foo { public: void Function3() const { int i =2; }; const std::string Function4() const { return ""; }; unsigned int Function5() const { return 2; }; }; std::map<std::string, boost::function<void> > functions; Foo foo; functions["Function3"] = boost::bind(&Foo::Function3, &foo); functions["Function4"] = boost::bind(&Foo::Function4, &foo); functions["Function5"] = boost::bind(&Foo::Function5, &foo); // call the functions functions["Function4"](); -------------- Calling the correct function with the entries in the map is no problem, but how can I get the return value. I tried something like that: "unsigned int i = functions["Function5"]();" but sadly it doesnt work, maybe cause in the map I declared for the return value "void"? How can I have such a map where to have functions with different return types in it and to get the return value after a call of the function through the map? Thanks in advance Julia

3 4

Re: threads and signals question
by Ken Thomases 04 Sep '02

04 Sep '02

On 29 Aug 2002, at 20:12, "lparrab" <lparrab(a)gmx.net> wrote: > I'm starting a multi-threaded program using Boost.Thread library: > it is a "server", in which a thread loops around a "select" to > accept new connections and see when a socket has data to be read, in > which case puts the fds in queue from which other threads are taking > them out to read the data. > The problem I have, is that when a "ReceiverThread" finishes reading > the data from the socket, it puts the fd back in the "all > connections list", but by this time the other ("main")thread already > copied the fds from the list and got into the next "select" loop, > which means the socket from which the "receiver" just finished > reading, will not be "selected" (monitored) untill the next select > loop, which will not be untill a) a new connection comes or b)one of > the other connected sockets gets some data that takes makes the main > thread return from select. The cleanest way to wake the main thread from select is to make one of the file descriptors in its FDSET become readable. What you need is a special file descriptor that is always in the FDSET that becomes readable when some other thread needs the main thread to come out of the select call. For this you can use a pipe. Here's a way that requires minimal changes to your existing design: When a thread needs the main thread to wake up, it writes a byte into one end of the pipe. It doesn't matter what the byte contains, its presence in the pipe is the "information" payload. When the main thread comes out of the select, if its end of the pipe was among the readable fds, then it should pull one byte out of the pipe (and discard it). If you use extreme care, you can instead flush the pipe of all bytes if you're sure you won't cause a race condition that way. (Example of race condition: Main thread comes out of select, Main thread builds new FDSET for next select call, Receiver thread writes to pipe to inform it of newly available fd, Main thread flushes pipe and blocks in select. To fix this race condition, you would reverse the order in which the Main thread flushes the pipe and builds the FDSET.) Here's the better design: Consider: why do you need the Receiver threads to wake the Main thread? To transfer responsibility for an fd from a Receiver thread to the Main thread. So, this is similar to the way the Main thread transfers fds to Receiver threads through a queue, and should be implemented in a similar fashion. Instead of using the pipe just to signal the Main thread to wake, actually use it to transfer the fds, just as you use the queue in the other direction. So now, when Receiver threads are done with an fd, they write the actual fd into the pipe. The Main thread wakes because the other end of the pipe was in its FDSET. It should read any and all fds out of the pipe and add them to its "connection list" for its next pass through select. (You can read just one fd from the pipe for each time that select indicates the pipe is readable, or you can set the pipe to be non-blocking and read until the pipe is empty.) This approach is a better design because it implements the actual transfer of responsibility and because the connection list should be private to the Main thread. This way doesn't require that the Receiver threads access the connection list, so the connection list doesn't have to be protected by a mutex. > I think having a thread waiting on each open connection is not the > right approach here, so I thought of going a kind of "production line" > approach in which a few threads (5-10) are reading the data from a > bunch of open connections (50-100), the only thing they do is read the > data, parse it and form a "Request" which they put in a queue for > further processing and then go on to service the other connections. > Then another group of threads is taking this requests and doing > something, and putting Response objects in yet another queue, which > another group of threads "Sender" is taking and sending thorugh the > socket. Just be aware that this design may mean that the client sees responses arrive out of order from their requests. If the client only submits a request after any previous requests have been satisfied, you're OK. If the client can have multiple requests outstanding at once, the Request threads or the Sender threads may finish out-of-order. Also, if the Sender threads don't write atomically or with exclusive access, then the data from multiple responses might be interleaved. This illustrates why it is cleaner to have a thread take full ownership of a connection for its lifetime as others have suggested. Of course, you're not being unreasonable in your approach, but you can marry the two somewhat. You might have each worker thread combine the Receiver, Request, and Sender jobs in sequence and then relinquish the connection back to the main thread. It's not clear to me that there is any advantage in terms of number of threads, thread workload, or throughput to splitting those jobs up. Hope that helps, Ken

1 0

boost::recursive_mutex for thread-safe logging crashing
by Ani Taggu 03 Sep '02

03 Sep '02

Hello: I have a simple class to do simple thread-safe logging using recursive_mutex as shown below. The problem is, once in a while, it causes any thread to die while it tries to log. I haven't been able to isolate why this happens. Is recursive_mutex being used correctly? The logging is done like so: extern FileLogger &TheLog() { static g_log("my.log"); return g_log; } TheLog() << "Hello World" << endl; I am using boost 1_28 with MSVC 6 SP5. ---------------------------------------------------------------------------- ------------------ #include <fstream> #include <string> #include "boost/thread/recursive_mutex.hpp" class FileLogger { public: // set second arg = false to do no logging. FileLogger(const std::string &logName, bool log=true) : log_(log) { if (log_) { strm_.open(logName.c_str(), std::ios::ate); } } // logging can be accessed from any thread. template <typename T> std::ostream & operator<< (T d) { if (log_) { boost::recursive_mutex::scoped_lock l(strmMutex_); strm_ << d; } return strm_; } ~FileLogger() { if (log_) { strm_.close(); } } private: std::ofstream strm_; boost::recursive_mutex strmMutex_; bool log_; };

2 3

RE: [Boost-Users] tuple and enums
by Tom Matelich 03 Sep '02

03 Sep '02

Hello Jaakko, Thanks for replying. It works if the constructor is written cons() {} Is there any purpose to putting those default calls there? Tom > From: Jaakko Jarvi [mailto:jajarvi@cs.indiana.edu] > Sent: Thursday, August 29, 2002 8:16 AM > > Hi Tom, > > Your code compiles fine with gcc 3.x and icc 6 (linux), so it may just > be gcc 2.96 problem. > > Cheers, Jaakko > > On Wed, 28 Aug 2002, Tom Matelich wrote: > > > It appears that an enum cannot be default constructed in > the way that > > tuple > > does, > > cons() : head(), tail() {} > > > > Any idea on how to get around this (besides using an int in > the tuple)? > > > > Thanks, > > Tom > > > > > > <sample_code> > > > > #include <boost/tuple/tuple.hpp> > > #include <string> > > > > enum Foo { Willis, Arnold }; > > > > void test() > > { > > boost::tuple<Foo, std::string> a; > > } > > > > </sample_code> > > > > </error compiler="gcc version 2.96 20000731 (Mandrake Linux 8.2)"> > > > > > /usr/local/eddynet/opt/include/boost/tuple/detail/tuple_basic.hpp: In > > method > > `boost::tuples::cons<HT, > > TT>::cons () [with HT = Foo, TT = boost::tuples::cons<string, > > boost::tuples::null_type>]': > > > /usr/local/eddynet/opt/include/boost/tuple/detail/tuple_basic.hpp:454: > > instantiated from `boost::tuples::tuple<T0, T1, T2, T3, T4, > T5, T6, T7, > > T8, > > T9>::tuple () [with T0 = Foo, T1 = string, T2 = > > boost::tuples::null_type, T3 > > = boost::tuples::null_type, T4 = boost::tuples::null_type, T5 = > > boost::tuples::null_type, T6 = boost::tuples::null_type, T7 = > > boost::tuples::null_type, T8 = boost::tuples::null_type, T9 = > > boost::tuples::null_type]' > > tuple_enum_test.cpp:8: instantiated from here > > > /usr/local/eddynet/opt/include/boost/tuple/detail/tuple_basic.hpp:263: > > cannot convert `int' to `Foo' in > > assignment > > > > </error> > > > > > > > -------------------------------------------------------------- > --------- > > DISCLAIMER: Information contained in this message and/or > > attachment(s) may contain confidential information of Zetec, Inc. > > If you have received this transmission in error, please notify > > the sender by return email. > > > -------------------------------------------------------------- > --------- > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > > Info: <http://www.boost.org> > > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > -- -- -- Jaakko Järvi email: jajarvi(a)cs.indiana.edu -- Post Doctoral Fellow phone: +1 (812) 855-3608 -- Pervasive Technology Labs fax: +1 (812) 855-4829 -- Indiana University, Bloomington Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

RE: [Boost-Users] tokenizer
by Jim.Hyslop 03 Sep '02

03 Sep '02

Vijay (macrodisk(a)yahoo.com) wrote: > Is there anyway I can combine two tokens and check it as single one? > > I want to divide my string when both "-" and ">" occur together: > > Cell 12-1 -> xyz... > > I want to get the first token as Cell 12-1, how can I achive this via > tokenizer? I haven't used the tokenizer, but it seems to me that your TokenizerFunction can peek at the character after the '-' to see if it is a '>', to determine whether it should treat the '-' as a regular character or part of a separator. -- Jim

2 1

Problems with MSVC-STLPORT toolset
by davlet_panech 03 Sep '02

03 Sep '02

Hello, I'm having problems building release 1.28 with MSVC 6/STLPort 4.5.3/bjam on Windows NT 4. It seems that bjam tries to make a very VERY deep directory tree which at some point becomes too large due to path name limitations. By looking at the trace messages it seems something is very wrong there :) -- the directory tree is modelled after the command line options with some of the options repeated with different values at different levels in the tree. For example the following target fails (and there a few cases similar to this one; so that nothing gets compiled): mkdir libs\regex\build\bin\libboost_regex.lib\msvc- stlport\stlport-iostream-on\debug-symbols-on\exception-handling- on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime- link-dynamic\stlport-cstd-namespace-std\stlport-iostream-off ...failed MkDir1 libs\regex\build\bin\libboost_regex.lib\msvc- stlport\stlport-iostream-on\debug-symbols-on\exception-handling- on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime- link-dynamic\stlport-cstd-namespace-std\stlport-iostream-off... Notice how the path includes both stlport-iostream-off and stlport- iostream-on components. The command line I was using: bjam \ -sTOOLS=msvc-stlport \ -sBUILD=stlport-iostream-on -sSTLPORT_4.5.3_PATH="h:\PROGRA~1\MICROS~1\VC98\INCLUDE\stlport" The MSVC-specific environment was set up correctly (MSVCDir, INCLUDE, LIB). The STLPORT_4.5.3_PATH points to the directory containing the STLPort headers. What am I doing whrong? Thanks, D.P.

2 1

[bind] does bind do overload resolution?
by Alex Henderson 02 Sep '02

02 Sep '02

Hi, I'd like boost::bind to use overloaded member functions, but get an internal compiler error. Does bind support overload resolution, or is my compiler at fault? (...or more likely the code!) system = C++Builder 5 (patched), Win2k, boost_1_28_0 example (simplified) code below Thanks, Alex //-------------------------------------------------------------------- ------- #include <string> #include <vector> #include <iostream> #include <boost/bind.hpp> //-------------------------------------------------------------------- ------- struct part { std::string name; int id; part(std::string name, int id) : name(name), id(id) {} bool is(int test) { return id == test; } // bool is(std::string test) { return name == test; } // uncomment for error }; //-------------------------------------------------------------------- ------- int main() { int x = 6; // swap comments here for error // std::string x("handle"); // swap comments here for error std::vector<part> parts; part a("top", 3); parts.push_back(a); part b("spout", 6); parts.push_back(b); part c("handle", 9); parts.push_back(c); std::vector<part>::iterator it = std::find_if(parts.begin(), parts.end(), boost::bind(&part::is, _1, x)); std::cout << it->name << std::endl; return 0; } //-------------------------------------------------------------------- -------

4 3