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

[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

Re: [Boost-users] converting value before inserting into a list
by Flex Ferrum 20 Sep '06

20 Sep '06

Hello. David Walthall wrote: > Flex Ferrum wrote: > > map<int,int> m; > > vector<int> a,b; > > std::transform(a.begin(), a.end(), std::back_inserter(b), var(m)[_1]); > Is this a case where transform is not appropriate? My understanding is > that the operation supplied to transform must not have any side effects, > and here m may be modified by operator[]. Does this count as a side effect? Yes, of course, map::operator[] _can_ have side effects. But if author of such code absolutely sure what each value from source vector has corresponded map entry then map::operator[] will not have side effects and will suitable for transormation operation. ____________ Best Regards Flex

1 0

Boost.Python, MinGW, & ImportError
by Corey Wright 20 Sep '06

20 Sep '06

this is in reference to the following postings to c++-sig and boost-users: 1. http://lists.boost.org/boost-users/2006/02/17367.php 2. http://mail.python.org/pipermail/c++-sig/2006-September/011202.html the summary: individuals, including myself, are seeing "ImportError: dynamic module does not define init function (inithello)" whenever trying to import a module compiled with mingw against boost.python, specifically the python examples and tutorial distributed with boost. the symptom: g++ fails to properly link whenever a null library search path (ie -L"") is specified (because maybe it stops parsing arguments there?). the cause: MINGW_BIN_DIRECTORY is null the short answer (for those newbies just trying to get through the tutorial/example and don't care to dive into the details of boost.build): bjam -sMINGW_BIN_DIRECTORY=C:\MinGW\bin (or where ever your mingw installation is) the longer answer: see attached patch the explanation: A. in gcc-tools.jam: 1. the gcc-Link-action contains -L"$(STDLIBPATH:T)" 2. STDLIBPATH is set based on following commands: a. flags gcc GCC_STDLIB_DIRECTORY : $(GCC_STDLIB_DIRECTORY) ; b. GCC_STDLIB_DIRECTORY ?= $(GCC_ROOT_DIRECTORY)$(SLASH)lib ; c. flags gcc STDLIBPATH : $(GCC_STDLIB_DIRECTORY) ; but when using mingw, the values in gcc-tools.jam are set... B. in mingw-tools.jam 1. local GCC_BIN_DIRECTORY = $(MINGW_BIN_DIRECTORY) ; 2. local GCC_STDLIB_DIRECTORY = $(MINGW_STDLIB_DIRECTORY) ; 3. flags mingw STDLIBPATH : $(GCC_BIN_DIRECTORY) ; so for mingw, STDLIBPATH is always composed of GCC_BIN_DIRECTORY (which is really MINGW_BIN_DIRECTORY). if you set MINGW_STDLIB_DIRECTORY, but not MINGW_BIN_DIRECTORY, you end up with -L"mingw_stdlib_directory" -L"". you must set MINGW_BIN_DIRECTORY to get rid of the null string or insure the null string in MINGW_BIN_DIRECTORY never gets added to STDLIBPATH. i successfully compiled boost.python without needing to set MINGW_BIN_DIRECTORY because the mingw tools are in my path and everything "just works". but if you try to compile python extensions (or at least the tutorial and examples), then things start mysteriously failing. i haven't had time to fully test my patch by building all of boost with it applied, but i'm currently in the process and last i looked bjam had compiled date and filesystem libraries, and was working on iostreams. thanks for boost.python and the mingw support (it feels liberating to compile free software, gratis & libre, with free software; and we'll overlook the operating system ;-). -- undefined(a)pobox.com

2 1

boost shmem
by Clarke, Trevor 20 Sep '06

20 Sep '06

I need to use shared memory in an application on Windows and Solaris so I've grabbed boost::shmem 0.93. It works fine on Windows but fails to compile on Solaris 10/SunPro 11. Has anybody had success on Solaris? I get the following errors when I try to compile. "boost/shmem/detail/segment_manager.hpp", line 253: Error: Redefining boost::shmem::detail::segment_manager<boost::shmem::detail::CharType, boost::shmem::detail::MemoryAlgorithm, boost::shmem::detail::IndexType<boost::shmem::detail::IndexConfig>> after use in boost::shmem::detail::segment_manager<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>::index_config<c har>. "boost/shmem/indexes/flat_map_index.hpp", line 29: Where: While specializing "boost::shmem::detail::segment_manager<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>::index_config<c har>". "boost/shmem/indexes/flat_map_index.hpp", line 29: Where: Specialized in boost::shmem::flat_map_index_aux<boost::shmem::detail::segment_manager<c har, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>::index_config<c har>>. "boost/shmem/indexes/flat_map_index.hpp", line 45: Where: Specialized in boost::shmem::flat_map_index<boost::shmem::detail::segment_manager<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>::index_config<c har>>. "boost/shmem/detail/segment_manager.hpp", line 1046: Where: Specialized in boost::shmem::detail::segment_manager<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>::header_t. "boost/shmem/detail/segment_manager.hpp", line 1053: Where: Specialized in boost::shmem::detail::segment_manager<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>. "boost/shmem/detail/named_object_impl.hpp", line 73: Where: Specialized in boost::shmem::detail::basic_named_object_impl<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>. "boost/shmem/named_shared_object.hpp", line 42: Where: Specialized in boost::shmem::basic_named_shared_object<char, boost::shmem::simple_seq_fit<boost::shmem::shared_mutex_family, boost::shmem::offset_ptr<void, boost::shmem::offset_1_null_ptr>>, boost::shmem::flat_map_index<boost::shmem::IndexConfig>>. "Signaling.h", line 52: Where: Specialized in non-template code. 1 Error(s) and 1 Warning(s) detected. The offending bit of code is: void sendPathAndName(std::string &path, std::string &name, boost::shmem::named_shared_object *pSegment) { if(mpPath != NULL) { pSegment->deallocate(mpPath.get()); // <-- error } Where mpPath is a boost::shmem::offset_ptr<char> that was created with pSegment->allocate() -------------------- Trevor R.H. Clarke tclarke at ball.com <mailto:tclarke@ball.com> Ball Aerospace & Technologies Corp

2 1

Re: [Boost-users] converting value before inserting into a list
by Flex Ferrum 20 Sep '06

20 Sep '06

Hello, Alexander Shyrokov, You wrote: > I want to convert values according to a map before inserting it into the > list. What is a proper way to do that? > I have this: > map<int,int> m; > vector<int> a,b; > for(vector<int>const_iterator i=a.begin();i!=a.end();++i) > b.push_back(m[*i]); > I could use std::copy with std::back_inserter to add elements to b, but > how do I convert it first? Should I write my own version of > back_inserter for that? > copy(a.begin(),a.end(),my_back_inserter(b,m)); > Thanks. Try this: #include <boost/lambda/lambda.hpp> using namespace boost; using namespace boost::lambda; //... //... map<int,int> m; vector<int> a,b; std::transform(a.begin(), a.end(), std::back_inserter(b), var(m)[_1]); Flex

3 2

[MultiIndex] comparison operator
by Lukasz Dobrek 20 Sep '06

20 Sep '06

Hi, I know that there are for sure important design decisions explaining why all std containers as well as multiindex take a comparison operator, as template parameter. This behavior is satisfactory as long, as comparison is sort of context independent. The best example say ints, but there exist cases when comparison of two object requires some priory knowledge about context this objects exist in. My favorite example is tenor ( time period ). It is impossible to say whether 1 month is less then 30 days unless you know when you start counting. So in order to compare such objects I need to specify some anchor date. Unfortunately I cannot have a std::set of such objects, nor a multiindex indexed with this objects. Note: I am able to sort a vector of such objects using std::sort. First question: Is there a way to use such objects with multiindex, if not why? Second question: I cannot be the only bloke disturbed by this issue, how are you dealing with it? Regards, Lukasz Dobrek

2 2