- Boost-users - lists.boost.org

[program_options] Bug in example and documentation
by Peter Gerell 31 Jan '06

31 Jan '06

Hi, I believe the example found in example/response_file.cpp and referenced in the documentation has a bug. In the following code fragment a temporary string object is passed as the first argument to the tokenizer constructor. This string is destroyed before the iteration over the tokens start. /Peter if (vm.count("response-file")) { // Load the file and tokenize it ifstream ifs(vm["response-file"].as<string>().c_str()); if (!ifs) { cout << "Could not open the response file\n"; return 1; } // Read the whole file into a string stringstream ss; ss << ifs.rdbuf(); // Split the file content char_separator<char> sep(" \n\r"); tokenizer<char_separator<char> > tok(ss.str(), sep); vector<string> args; copy(tok.begin(), tok.end(), back_inserter(args)); // Parse the file and store the options store(command_line_parser(args).options(desc).run(), vm); }

1 0

Request help with boost::compose to boost::bind conversion
by gdprosch＠micron.com 30 Jan '06

30 Jan '06

Let me apologize in advance for my ignorance but I have not been able to update the following code successfully in order to migrate from Boost 1_29 to 1_33. Despite reading the boost::bind documentation a few times I am failing to make the necessary connection regarding the use of _1, _2 and handling the use of DeRef in the equal function below. // Unary dereference functor (a functor that returns the value of the specified // parameter, dereferenced via operator*) // (Note: This DeRef code is included in a separate header.) template < class Ptr, class T > struct DeRef : public std::unary_function< Ptr, T > { T & operator()( Ptr & ptr ) const { return *ptr;} }; // --- // Compare LocalStringMap (a custom map container with Tag/Value pair). // A TagValue is a class that contains a tag and a value (both strings) // A TagValuePtr is a custom, dereferencable smart pointer. inline bool LocalStringMap::operator==( const LocalStringMap &that ) const { // Must be same size if( this->size() != that.size() ) { return false;} return equal( this->_list.begin(), this->_list.end(), that._list.begin(), boost::compose_f_gx_hy( equal_to< TagValue >(), DeRef< const TagValuePtr, const TagValue >(), DeRef< const TagValuePtr, const TagValue >() ) ); } Any assistance with this would be most helpful. I get the impression that I do not need to use the DeRef class the original author created given boost:bind's more capable traits identification. Here's what I have so far... return std::equal( this->_list.begin(), this->_list.end(), that._list.begin(), boost::bind<bool>( std::equal_to< TagValue >(), ??? Thank you, Greg Prosch Micron Technology, Inc.

1 0

Re: [Boost-users] Boost shared pointers and MSVC++ 6.0
by Sohail Somani 30 Jan '06

30 Jan '06

> The object is always deleted by the same library that created the > shared_ptr. This is done by instantiating an appropriate deleter at > construction time. You can defeat this by creating the object > in library A > and the shared_ptr in library B, of course. > > Mixing single- and multithreaded libraries might be a problem > for other > reasons, but even that should work on Windows with Boost 1.33 > with the > default configuration. Thanks Peter, please disregard my reply to your other email.

1 0

Re: [Boost-users] Boost shared pointers and MSVC++ 6.0
by Sohail Somani 30 Jan '06

30 Jan '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Sohail Somani > Sent: Monday, January 30, 2006 1:06 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost shared pointers and MSVC++ 6.0 > > > -----Original Message----- > > No, this isn't normal. shared_ptr should work even if you > > don't do (1) or > > (2), with one exception: the plugin that created a shared_ptr > > needs to be > > present in memory when the last copy of this shared_ptr is > destroyed > > (because the creator plugin contains the destructor code.) So > > if you don't > > unload plugins dynamically, it _should_ work. If it doesn't, > > try to isolate > > a simple example for us to investigate. > > How will it work if the main program is linked against the > multi-threaded dll and some other library the single-threaded, but the > object that was created in the MT-linked dll is deleted by the one in > the ST-dll? > > Wouldn't different deletes be called? After mulling a bit, I think this is the whole point of shared_ptr. But I am not sure how it works. Is this encapsulated in the check_delete?

1 0

Boost shared pointers and MSVC++ 6.0
by Henri Herscher 30 Jan '06

30 Jan '06

Hi, I'm making heavy use of the boost shared pointers in the open source audio recording (voip and sound devices) project I'm developing (http://www.oreka.org) The software is cross platform (Windowns/Linux) and shared pointers are created in plugins and typically destroyed in other plugins or in the main program. Under linux, I haven't had any kind of problem. On windows however, using MSVC++ 6SP6 I have observed strange crashes that happen only in the release mode. So far I think I have been able to solve that doing two things (both needed or crash !): 1. Make sure all DLLs and the main program are compiled with the same runtime (multithreaded DLL) 2. Make sure all DLLs and the main program are compiled with inline function exapansion disabled My questions: * Is this normal ? What have other people experienced ? * Will this go away if I upgrade to MSVC++ 7 ? Thanks Henri

2 2

Re: [Boost-users] Boost shared pointers and MSVC++ 6.0
by Sohail Somani 30 Jan '06

30 Jan '06

> -----Original Message----- > No, this isn't normal. shared_ptr should work even if you > don't do (1) or > (2), with one exception: the plugin that created a shared_ptr > needs to be > present in memory when the last copy of this shared_ptr is destroyed > (because the creator plugin contains the destructor code.) So > if you don't > unload plugins dynamically, it _should_ work. If it doesn't, > try to isolate > a simple example for us to investigate. How will it work if the main program is linked against the multi-threaded dll and some other library the single-threaded, but the object that was created in the MT-linked dll is deleted by the one in the ST-dll? Wouldn't different deletes be called?

2 1

[thread] Static mutex members
by David A. Greene 30 Jan '06

30 Jan '06

The following single-file testcase fails to link: #include <boost/thread/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <iostream> template<typename Type> class singleton { public: typedef boost::recursive_mutex mutex_type; typedef Type * handle; private: typedef mutex_type::scoped_lock lock_type; static mutex_type mutex; static handle inst; public: static Type &instance(void) { lock_type lock(mutex); if (!inst) { inst = new Type; } return(*inst); }; }; class tester { public: void test(void) { std::cerr << "Test" << std::endl; }; }; template<> singleton<tester>::mutex_type singleton<tester>::mutex; template<> singleton<tester>::handle singleton<tester>::inst = 0; int main(void) { singleton<tester>::instance().test(); return(0); } thread.o: In function `singleton<tester>::instance()':/home/greened/projects/apsim/current/apsim/msim/test/thread.cc:21: undefined reference to `singleton<tester>::mutex' collect2: ld returned 1 exit status I was getting undefined references to "inst" before I added the initializer. Is this a new adherance to the standard by g++ 4.0.2? I didn't used to have to add the initializer to get it to link. This is troublesome with boost::recursive_mutex because it is noncopyable. How do I specify an initializer for it? Is it just not possible to have a mutex static member? -Dave

2 1

Re: [Boost-users] Spawning a thread on a member function
by Sliwa, Przemyslaw (London) 30 Jan '06

30 Jan '06

Can I spawn the thread within another member function? I believe it should be not a problem. Thanks Kind regards Pshemek Przemyslaw Sliwa Global Foreign Exchange FX Risk Engine Development Merrill Lynch ( +44 (0)20 7995 4182 ) +44 (0)79 6325 2319 * Email: przemyslaw_sliwa(a)ml.com -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Patrick Sent: 27 January 2006 23:03 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Spawning a thread on a member function You are correct the "boost::ref(*this)" is not needed. Simple(boost::bind(&Simple::run, this)) {} -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Christian Henning Sent: Friday, January 27, 2006 4:47 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Spawning a thread on a member function This is even simpler. Is there is reason for "boost::ref(*this)" ? class Simple { Simple() : th( boost::bind( run, this )) {} void run() { for(;;){ //Thread's work goes here. } } private: boost::thread th; }; _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

problem with include files
by Frank Pleyer 30 Jan '06

30 Jan '06

Hi, Im new to boost and after building the libraries to c:\boost, I wanted to go through the [String Algorithm First Example]. Im using visual c++ 2005 with windows xp SP2 and when I tried to build my project I get the following error: fatal error C1083: Datei (Include) kann nicht geöffnet werden: "boost/algorithm/string.hpp" corrosponding to that line of code: #include <boost/algorithm/string.hpp> All # include calls have a unix like path description and not a common windows path like : c:\boost\include\algorith\string.hpp. That seems to be a general problem with all #include calls in all boost *.hpp files. I have included the the path[c:\boost] and [c:\boost\include] to my VC++ INCLUDE Path. Can somebody please help. -Frank

2 1

Re: [Boost-users] Boost shared pointers and MSVC++ 6.0
by Sohail Somani 30 Jan '06

30 Jan '06

> My questions: > > * Is this normal ? What have other people experienced ? Normal. If you are sharing heaps, data structures across DLLs, you should be sure that you link with the same runtimes. > * Will this go away if I upgrade to MSVC++ 7 ? Maybe not if you're using C++.NET?

1 0