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

[boost::signal][boost::bind] signal::disconnect problem with MSVC 2005
by david callu 21 Sep '06

21 Sep '06

Hi, See this code ... #include<iostream> #include<boost/bind.hpp> #include<boost/signal.hpp> struct CSignal { typedef boost::signal< void (void) > UpdateSignal; UpdateSignal sig; }; struct CSlot {: void update(int i) { std::cout << "Call void update( " << i << " )" << std::endl; } void connect(CSignal& cs) { cs.sig.connect(boost::bind(&CSlot::update, this, 5)); } void disconnect(CSignal& cs) { cs.sig.disconnect(boost::bind(&CSlot::update, this, 5)); } }; int main() { CSignal csignal; CSlot cslot; cslot.connect(csignal); csignal.sig(); cslot.disconnect(csignal); csignal.sig(); return (0); } When i compile with GCC 4.1.1, this compile fine. But when i compile with MSVC 2005 it report an error: .\main.cpp(30) : error C2664: 'boost::signal1<R,T1,Combiner,Group,GroupCompare,SlotFunction>::disconnect' : cannot convert parameter 1 from 'boost::_bi::bind_t<R,F,L>' to 'const int &' with [ R=void, T1=int, Combiner=boost::last_value<void>, Group=int, GroupCompare=std::less<int>, SlotFunction=boost::function<void (int)> ] and [ R=void, F=boost::_mfi::mf1<void,CSlot,int>, L=boost::_bi::list2<boost::_bi::value<CSlot *>,boost::arg<1>> ] Reason: cannot convert from 'boost::_bi::bind_t<R,F,L>' to 'const int' with [ R=void, F=boost::_mfi::mf1<void,CSlot,int>, L=boost::_bi::list2<boost::_bi::value<CSlot *>,boost::arg<1>> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called have you any idee to solve this problem? thank david callu

3 4

Boost.signals with -pthread
by Pavel Syomin 21 Sep '06

21 Sep '06

Hi, all! I am novice in this list, so don't beat freely :) I confronted with a strange thing using boost.signals on SLES 9 SP3. I don't shure Boost.signals bug, becase on FC4 and RHEL AS 3 all fine. Test case: --------------------- CUT HERE ------------------ #include <boost/signal.hpp> #include <iostream> struct MySlot { void operator() () { std::cout << "YES!" << std::endl; } }; MySlot myslot; boost::signal<void ()> mysig; int main() { mysig.connect(myslot); return 0; } --------------------- CUT HERE ------------------ Compile and run: c++ test.cc -o test -lboost_signals ./test Programm will succesfully exit. Compile and run: c++ test.cc -o test -lboost_signals -pthread ./test Programm will not exit never. Boost version: 1.31.0 (from SuSE rpm) GCC version: c++ (GCC) 3.3.3 (SuSE Linux) I run this test on other SuSE boxes with same results. Any ideas? P.S. I can't use GCC without '-pthread' because my program use threads...

2 5

[Boost Conference] Save the Date
by David Abrahams 21 Sep '06

21 Sep '06

================================ Save the Date: May 14-18, 2007 ================================ We're pleased to issue this pre-announcement of the first annual Boost Conference, BoostCon 2007. The conference will take place in Aspen, Colorado, May 14-18. This promises to be the main face-to-face event for all things Boost, from from using Boost libraries to writing them, from evangelizing Boost to deployment within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2. Given the range and interests of the participants, this event promises to be intense and in-depth. Due to the breadth of our community, the conference will be organized into two primary tracks: one directed mostly at hard-core Boost developers, and the other focused on the practical interests of Boost end-users. In the spirit of Boost, however, the conference will be planned to foster collaboration and interaction both within *and* across these tracks, with an emphasis on hands-on, participatory sessions. More details, including a call for session proposals, will be forthcoming in the next few weeks. Enrollment for this event will be limited, so we're issuing this notice to the Boost community well in advance. In the meantime, we have set up a page on the Boost Wiki where we're doing an informal, preliminary survey of interest (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostCon) If you want to be a part of the inaugural BoostCon and are likely to attend, we'd appreciate it if you'd add yourself (or an alias) to the list there, to help us with event planning. Thanks, The BoostCon 2007 Organizers ------------------------------------------------------------------ David Abrahams Beman Dawes Jeff Garland Kevlin Henney Scott Meyers Eric Niebler Sean Parent Rene Rivera Jeremy Siek Matthias Troyer ------------------------------------------------------------------

2 2

Boost/ptr_vector and BCB6
by Ivo Trowitzsch 21 Sep '06

21 Sep '06

Hello everyone, I am new to Boost. I am using Borland C++ Builder 6 (bcc32 v5.6). Now I wanted to use the ptr_container/ptr_vector: So I included <boost/ptr_container/ptr_vector.hpp>. that's where the trouble starts, without actually using a ptr_vector. Compiling leaves me with errors in reversible_ptr_container.hpp: "reversible_ptr_container.hpp(487): E2404 Dependant type qualifier 'reversible_ptr_container<Config,CloneAllocator>' has no member type named 'allow_null'." To be honest: I have no clue, what to do to to get rid of that error. I guess ptr_vector should work on the bcc32, at least I was not able to find anything related to this error searching this mailing-list's archive and elsewhere with google. I imagine I might have set some compiler's settings wrong or something, but I don't know. If anyone could help me out on this, I'd be very thankful! Ivo.

2 1

Probably bug in condition::timed_wait()
by Pavel Syomin 21 Sep '06

21 Sep '06

Hi, I'm porting custom library from UNIX to Windows and found that some piece of code work correctly on UNIX and some time segfaulting on Windows. I think, that problem is on boost::condition::timed_wait() function. To be sure I write small test: #include <stdexcept> #include <iostream> #include <boost/thread.hpp> #include <windows.h> using namespace boost; using namespace std; class AsyncQueue { public: AsyncQueue() : m_counter(0) {} void push() { mutex::scoped_lock lock(m_mutex); m_counter++; m_condition.notify_one(); } void timed_pop(const xtime &time) { mutex::scoped_lock lock(m_mutex); if(m_counter) { m_counter--; return; } if(!m_condition.timed_wait(lock, time)) return; if(!m_counter) throw out_of_range("oops..."); m_counter--; } private: mutex m_mutex; condition m_condition; int m_counter; }; static AsyncQueue queue; static void start() { for(;;) { queue.push(); Sleep(100); } } int main(int argc, char **argv) { thread thread(start); xtime time; for(;;) { xtime_get(&time, TIME_UTC); time.nsec += 10000; queue.timed_pop(time); } return 0; } AsyncQueue is a simple asynchronous queue container with two operations - push() and timed_pop(). Because this is test, AsyncQueue don't really collect something, but it's has variable (m_counter field) that count current number on elements in container. When push() called m_counter incremented and when timed_pop() "virtually" remove item from queue m_counter decremented. In main() I create additional thread, which push data to queue. Data popped from queue in main thread by calling timed_pop(). But sometimes timed_pop throw out_of_range exception. If you look in code you can see that it's mean that condition::timed_wait() return true, but queue is empty! I look to boost-users list and found e-mail's about similar problems from Eric Colleu, but decision wasn't found. Two words about my environment. I use Visual Studio 2005, Windows XP SP2 on VMWare 5.5.1. Boost version is 1.33.1. Thanks for constructive answers.

3 5

[asio]how can I wait the last handler return in destructor
by Wang Yun 21 Sep '06

21 Sep '06

Hi all, I have a class class Connection { ... ~Connection() { _socket.close(); } void receiveHandler() { // will crash } tcp::socket _socket; } io_service.run() is called in a working thread, and there are many other sockets runing on the io_service. I call async_read on the _socket, and bind Connection::receiveHandler() as the handler function. Then I delete the Connection object in main thread, the receive operation will be cancelled and the receiveHandler() will be called with errcode boost::asio::error::operation_aborted, but at that time, the Connection object has been deleted, calling receiveHandler() will crash if it access the object's data member. Because there are still other sockets running on the io_service, I can't just join the working thread in Connection's destructor. I want to ensure the socket is closed completely and no more handler will be called in the destructor. One method is create an event before calling _socket.close(), then wait for the event, in receiveHandler(), set the event. Are there any easier method to do this? Thanks, Wang Yun

2 2

program_options ??
by Konstantin 20 Sep '06

20 Sep '06

Hi! Try to umderstand boost and... have got a trable. What are wrong? // no boost: void CommandLineParser::Parse(void) { wostringstream wostr; m_szArglist = CommandLineToArgvW(GetCommandLineW(), &m_nArgs); if( NULL == m_szArglist ) { wostr << L"CommandLineToArgvW failed" << ends; m_objErrFileWriter->PutLineIntoLogFile(wostr.str()); return ; } else wostr << endl ; for( int i=0; i < m_nArgs; ++i) { wostr << L"Command line parameter " << i << " is " << m_szArglist[i] << endl ; } wostr << ends ; m_objLogFileWriter->PutLineIntoLogFile( wostr.str()); // OK. //in file //Command line parameter 0 is C:\UPL\projects\vc\game\ufo_pl.exe //Command line parameter 1 is --help } // with boost: BOOL CommandLineParser::Parse(BOOL boost) { //vector<string> args = po::split_winmain(GetCommandLineW()); // not for wstring //vector<string> args = po::split_winmain(lpCmdLine); // not get file name and path vector<wstring> args = po::split_winmain(GetCommandLineW()); try { // po::options_description desc(L"Allowed options"); // not work whith wstring po::options_description desc("Allowed options"); desc.add_options() // (L"help", L"produce help message") // not work ("help", "produce help message"); po::variables_map vm; po::store(po::wcommand_line_parser(args).options(desc).run(), vm); po::notify(vm); if (vm.count("help")) // do not catch a "help" ???????????? { // not work //wostringstream wosstr; //wosstr << desc << endl; //MessageBoxW(NULL, wosstr.str().c_str(), L"Allowed options", MB_OK); ostringstream ostrem; ostrem << desc << endl; MessageBoxA(NULL, ostrem.str().c_str(), "Allowed options", MB_OK); return FALSE; } } catch(exception& e) { wcerr << "error: " << e.what() << "\n"; return TRUE; } catch(...) { wcerr << "Exception of unknown type!\n"; } return TRUE; }

1 0

Re: [Boost-users] Boost serialization : concurrency
by Robert Ramey 20 Sep '06

20 Sep '06

Daniel F. Savarese wrote: > In message > <1DDB0D3CC4E7F14FAE946361C0A606550143CA11(a)isr-jlm-mail.Kayote.com>, > "Moshe Matitya" writes: I want to thank you guys for spending time on this. I know it's time consuming and you have other things to do. I'm watching the discussion in the hope that a consensus will be achieved and I can just update i/oserializer with the conclusion. If you made a simple - reliable test case, I would consider adding it to the test suite as this aspect of the library is important to me. However, I realize that that might not be possible. And compromises - like presuming that no de-serialization occurs before main is called are very acceptable to me - given the alternatives. Note that the order of creation is related to the fact that we use this idiom - instantiation via the usage of static variables - in several places. On is to instantiate serializers for derived classes (later) and one for maintaining the global table of types that the system knows about (sooner) Maybe that is helpful. Robert Ramey

2 3

date_time question
by Arkadiy Vertleyb 20 Sep '06

20 Sep '06

Hi, I am looking at the possibility of replacing our custom-made datetime classes with the ones from boost::date_time. The library looks very attractive to me, and I would certainly go ahead and use it... however there is (at least) one catch, and this is the snap-to-end-of-month behavior of the months duration, according to which: {2000-Feb-29} + {1 month} = {2000-Mar-31} The problem is that it contradicts to the XSD spec we are using, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#adding-durations-to-dat…, that says that months must be just "pinned to be within range". Maybe there is (could be added) some sort of policy, that could be used to achieve this behavior? Thanks, Arkadiy

2 2

Library Interface Design
by Scott Meyers 20 Sep '06

20 Sep '06

I have a question about library interface design in general with a strong interest in its application to C++, so I hope the moderators will view this at on-topic for a list devoted to the users' view of a set of widely used C++ libraries. In its most naked form, the question is this: how important is it that class constructors ensure that their objects are in a "truly" initialized state? I've always been a big fan of the "don't let users create objects they can't really use" philosophy. So, in general, I don't like the idea of "empty" objects or two-phase construction. It's too easy for people to make mistakes. So, for example, if I were to design an interface for an event log that required a user-specified ostream on which to log events, I'd declare the constructor taking an ostream parameter (possibly with a default, but that's a separate question, so don't worry about it): EventLog::EventLog(std::ostream& logstream); // an ostream must be // specified I've slept soundly with this philosophy for many years, but lately I've noticed that this idea runs headlong into one of the ideas of testability: that classes should be easy to test in isolation. The above constructor requires that an ostream be set up before an EventLog can be tested, and this might (1) be a pain and (2) be irrelevant for whatever test I want to perform. In such cases, offering a default constructor in addition to the above would make the class potentially easier to test. (In the general case, there might be many parameters, and they might themselves be hard to instantiate for a test due to required parameters that their constructors require....) Another thing I've noticed is that some users prefer a more exploratory style of development: they want to get something to compile ASAP and then play around with it. In particular, they don't want to be bothered with having to look up a bunch of constructor parameters in some documentation and then find ways to instantiate the parameters, they just want to create the objects they want and then play around with them. My gut instinct is not to have much sympathy for this argument, but then I read in "Framework Design Guidelines" that it's typically better to let people create "uninitialized" objects and throw exceptions if the objects are then used. In fact, I took the EventLog example from page 27 of that book, where they make clear that this code will compile and then throw at runtime (I've translated from C# to C++, because the fact that the example is in C# is not relevant): EvengLog log; log.WriteEntry("Hello World"); // throws: no log stream was set This book is by the designers of the .NET library, so regardless of your feelings about .NET, you have to admit that they have through about this kind of stuff a lot and also have a lot of experience with library users. But then on the third hand I get mail like this: > The .NET libraries have many objects with many constructors that leave the constructed object in a not ready-to-use state. > > An example: > System.Data.SqlClient.SqlParameter is a class that describes a bound parameter used in a database statement. Bound parameters are essential to prevent SQL injection attacks. They should be exceedingly easy to use since the "competition" (string concatenation of parameters into the SQL statement) is easy, well understood, and dangerous. > > However, the SqlParameter class has six constructors. Only two constructors create a sqlParameter object that can be immediately used. The others all require that you set additional properties (of course, which additional properties is unclear). Failure to prepare the SqlParameter object correctly typically generates an un-helpful database error when the SQL statement is executed. To add to the confusion, the first ctor shown by intellisense has 10 parameters (which, if set correctly, will instantiate a usable object). The last ctor shown by intellisense has only 2 parameters and is the most intuitive choice. The four in between are all half-baked. It's confusing, and even though I use it all the time, I still have to look at code snippets to remember how. So I'm confused. Constructors that "really" initialize objects detect some kind of errors during compilation, but they make testing harder, are arguably contrary to exploratory programming, and seem to contradict the advice of the designers of the .NET API. Constructors that "sort of" initialize objects are more test-friendly (also more loosely coupled, BTW) and facilitate an exploratory programming style, but defer some kinds of error detection to runtime (as well as incur the runtime time/space costs of such detection and ensuing actions). So, library users, what do you prefer, and why? Thanks, Scott

37 90