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

RE: [Boost-Users] Re: Is it possible to retrieve blank strings with boost::tokenizer?
by Sean Shubin 05 Sep '02

05 Sep '02

That did it. Thanks. -----Original Message----- From: Markus Schöpflin [mailto:markus.schoepflin@ginit-technology.com] Sent: Thursday, September 05, 2002 1:48 AM To: boost-users(a)yahoogroups.com Subject: [Boost-Users] Re: Is it possible to retrieve blank strings with boost::tokenizer? char_separator<char> sep("\t", "", keep_empty_tokens); should do the trick. HTH, Markus

1 0

Newbie boost::mem_fn problem
by Mark Snelling 05 Sep '02

05 Sep '02

Hello, My problem I think is very simple, I just can't seem to find the solution I have an STL list of object pointers and I want to call a member function on each of the pointers in the list usigng the STL for_each algorithm. This would seem easy if the list contained the actual objects rather than pointers to them, but because they are pointers I can't find a way of doing this. class Block { public: void update(int x); }; void main() { list<Block*> blocks; for_each(blocks.begin(), blocks.end(), *****); // Call update on each item in list } what should I replace the ***** with? Any help appreciated! Mark.

2 3

RE: [Boost-Users] Re: msvc-stlport build problems
by Jim.Hyslop 05 Sep '02

05 Sep '02

David Resnick (dresnick(a)mobilespear.com) wrote: > I've fixed the problem, here's my solution in case anyone > else needs it: Hi, David Would you mind taking a moment to add this to the Boost Users Wiki site? Follow this URL: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CommonBuildPr oblems and edit the page to add a brief description of the problem and how you solved it. Thanks! -- Jim

1 0

Is it possible to retrieve blank strings with boost::tokenizer?
by Sean Shubin 05 Sep '02

05 Sep '02

For example, using the code: string line = "\taaa\t\tbbb\t"; typedef tokenizer<char_separator<char> > tok; char_separator<char> sep("\t"); tok tokens(line, sep); for(tok::iterator i = tokens.begin();i!=tokens.end();++i) { cout << "\t\"" << *i << "\"" << endl; } I get this output: "aaa" "bbb" I want to get this output: "" "aaa" "" "bbb" ""

2 1

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