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

[program options] Using similar option strings
by Jason House 18 Sep '06

18 Sep '06

I recent attempted the equivalent of allowing the follwoing two options: --help --help-command [arg] --help-component [arg] When I ran the program with --help, I got an error that it was ambiguous. I didn't realize it, but program options allows the user to not specify the full string with "--". This then makes all the options above match --help. How can I get this type of functionality without getting runtime errors about ambiguity? If I were to reduce it to just --help and --help-command, it may be possible to just do --help with an optional argument, but I don't know how to do that. Currently, I'd like to avoid a shared namespace for commands and components.

2 1

Re: [Boost-users] Library Interface Design
by Sohail Somani 18 Sep '06

18 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Robert Kindred > > Can you not create them all, have them wait on some > condition variable > > and signal when you're ready to go? > > Yes, I suppose that works, with some extra effort. So does > this mean that a > monolithic constructor is very important to you? Not necessarily a monolithic constructor. Just before it starts doing work, you wait on the condition. I wouldn't expect that to be a ton of work. However, it is important to me to not have to remember the order in which to create things. This is just asking for a bug at 2am. Sohail

1 0

boost::interprocess::node_allocator & VC8 run-time problem
by alexmark 18 Sep '06

18 Sep '06

I have the problem with VC8 release build (all release build options - by default, i.e., optimization is "Maximize speed /O2" and so on). A run of "repro" output executable finishes with the exception on attempt to read data from address 0. I noticed it for boost::interprocess (and boost::shmem too) allocators of type: - node_allocator - cached_node_allocator and not to: - allocator - private_node_allocator The way out I found (for "problematic" allocator types) is to set additional compiler option "/Og-" (already declared deprecated). With VC7.1 it all is ok for any allocator type w/o setting /Og- or any other additional options. Have anyone noticed this problem? Where the problem originates from? VC8 optimization specifics (NRVO is affected by /Og option)? Or smth. wrong in "repro" code? Thanks. ////////////// The "repro" code is the following: #include "stdafx.h" #include <boost/interprocess/managed_external_buffer.hpp> #include <boost/interprocess/allocators/node_allocator.hpp> #include <boost/interprocess/containers/list.hpp> using namespace boost::interprocess; enum { A_SHARED_MEMORY_SIZE = 65536, A_POOL_SIZE = 64 }; typedef node_allocator<int, A_POOL_SIZE, managed_external_buffer::segment_manager> user_allocator_t; typedef list<int, user_allocator_t> MyUserList; int _tmain(int argc, _TCHAR* argv[]) { static char static_buffer[A_SHARED_MEMORY_SIZE]; managed_external_buffer user_buffer(create_only, static_buffer, A_SHARED_MEMORY_SIZE); MyUserList *userlist = user_buffer.construct<MyUserList>("MyUserList")(user_buffer.get_segment_manager()); return 0; }

2 1

Memory leask in class thread.
by 蹬三轮的 18 Sep '06

18 Sep '06

I found a memory leak in boost's thread class. Here is the sample program: void func() { } int _tmain(int argc, _TCHAR* argv[]) { _CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_DEBUG); _CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_DEBUG); _CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_DEBUG); { thread t(func); t.join(); } _CrtDumpMemoryLeaks(); return 0; } The output is: The thread 'Win32 Thread' (0xb24) has exited with code 0 (0x0). Detected memory leaks! Dumping objects -> {188} normal block at 0x003A9DA8, 24 bytes long. Data: < - > D0 2D 15 00 FF FF FF FF 00 00 00 00 00 00 00 00 {187} normal block at 0x003A9C78, 8 bytes long. Data: < : > A8 9D 3A 00 01 CD CD CD Object dump complete. So I think boost should resolve this problem in the next version.

5 5

Pb with Boost and VC++7.1 : inconsistent code ?
by Washburn 18 Sep '06

18 Sep '06

Hello everyone. I'm new to this mailing-list but I have a very annoying and urgent problem concerning Boost and the STL. I just upgraded to Boost 1.33.1 which is needed for the new version of libtorrent, linked statically in one of my DLLs. Build of Boost went quite well (using BJam) Build of lib went OK. Build of DLL : no problem either. But then at runtime I get this : Unhandled exception at 0x77e79282 in TestFileDl.exe: Microsoft C++ exception: boost::filesystem::filesystem_error @ 0x0012d654. Exception thrown in [path_posix_windows.cpp] line 339 : if ( !checker( name ) ) { boost::throw_exception( filesystem_error( "boost::filesystem::path", "invalid name \"" + name + "\" in path: \"" + src + "\"" ) ); } ... because this check does not behave properly : BOOST_FILESYSTEM_DECL bool windows_name( const std::string & name ) { return name.size() != 0 && name.find_first_of( windows_invalid_chars ) == std::string::npos <-------------- (here) && *(name.end()-1) != ' ' && (*(name.end()-1) != '.' || name.length() == 1 || name == ".."); } ... because find_first_of does not return what it should, in [xstring] : size_type find_first_of(const _Elem *_Ptr, size_type _Off, size_type _Count) const { // look for one of [_Ptr, _Ptr + _Count) at or after _Off if (0 < _Count && _Off < _Mysize) { // room for match, look for it const _Elem *const _Vptr = _Myptr() + _Mysize; for (const _Elem *_Uptr = _Myptr() + _Off; _Uptr < _Vptr; ++_Uptr) if (_Traits::find(_Ptr, _Count, *_Uptr) != 0) return (_Uptr - _Myptr()); // found a match } return (npos); // no match } Obviously the std::string is screwed up here, because I think _Mysize should not be 31, which makes the [for] searche outside the boudaries of the buffer, thus returning the wrong results... + this 0x0012d854 {"main_session.log"} const std::basic_string<char,std::char_traits<char>,std::allocator<char> > * const _Mysize 31 unsigned int I also believe that the symbol table is wrong here but I'm not sure. This piece of code belongs to the libtorrent project and is supposed to be stable. Then it gets even worse : after the acual throwing of the exception (the "throw" instruction), my call stack is screwed with a call to feeefeee()... I tried all compilation and link options, getting always the same result. Any idea people ? Please help :( Washburn

3 2

Re: [Boost-users] Library Interface Design
by Sohail Somani 18 Sep '06

18 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Robert Kindred > I can think of one example for not fully constructing objects: [snip] > The problem is in starting up. If each one of these threads > knows about > each other via some method (pointer, or reference), then when > a thread > starts up its own business, whatever that is, then most > likely it will start > generating data and sending messages. When it tries to send > a message to a > thread that does not yet exist, BOOM!!! (yes, I have > experienced this boom). Can you not create them all, have them wait on some condition variable and signal when you're ready to go?

2 1

Re: [Boost-users] Boost serialization : concurrency
by Moshe Matitya 18 Sep '06

18 Sep '06

Daniel F. Savarese wrote: > ... > However, I think I have a workaround that I just finished > testing (at least the unit tests no longer seg fault). > If you're willing to waste some memory and add the equivalent > of the following to oserializer > > private: > static oserializer & dummy; > > static oserializer & _instantiate(){ > static oserializer instance; > return instance; > } > public: > static oserializer & instantiate(){ > return dummy; > } > > and to iserializer: > > private: > static iserializer & dummy; > > static iserializer & _instantiate(){ > static iserializer instance; > return instance; > } > public: > static iserializer & instantiate(){ > return dummy; > } > > and initialize oserializer::dummy as: > template<class Archive, class T> oserializer<Archive,T> & > oserializer<Archive,T>::dummy = > oserializer<Archive,T>::_instantiate(); > > and iserializer::dummy as: > template<class Archive, class T> iserializer<Archive,T> & > iserializer<Archive,T>::dummy = > iserializer<Archive,T>::_instantiate(); > > then the local static will be initialized at program initialization > before any threads are running without incurring the global variable > initialization ordering problem. > ... > This is just a test hack, but I think the concept works. Sorry, I don't think your idea works: (1) What happens if the constructor or initializer of a global or static member variable calls oserializer::instantiate(), and that variable is initialized before oserializer::dummy is initialized? E.g.: struct foo { foo() { // oserializer::dummy might not be initialized yet, // so this can return a reference to an invalid object: oserializer<x,y> os = oserializer::instantiate(); os.do_something(); // boom } }; foo g_f; (2) There exists no guarantee that multiple threads will not be running at program initialization time. Threads can be started in the constructors and initializers of global or static member variables. E.g.: void thread_func() { // oserializer::dummy might not be initialized yet, // so this can return a reference to an invalid object: oserializer<x,y> os = oserializer::instantiate(); os.do_something(); // boom again } struct bar { bar() { boost::thread t(&thread_func); } } bar g_b; (Btw, if your idea really did work, then you would have just invented a thread-safe implementation of the Singleton pattern that does not require any thread synchronization. I don't believe that's possible.) Moshe

1 0

[Boost.Signal] Single-shot Connection?
by Wu Yinghui, Freddie 18 Sep '06

18 Sep '06

Dear all, I sent in this on 14 Sept, but have received no reply so far. As I'm not sure if it was lost in the void, I'm resend the mail again. Please bear with me if you have received the same question before. > I'm a happy user of Boost.Signal, as it brings great power to our > software design in terms of loosening all the coupling between > components. > > However, I recently come across a case where a single-shot slot is > desired (i.e., a signal-slot connection that is automatically > disconnected once the signal is invoked for once). In our current > implementation, we have to keep boost::signals::connection object around > with the slot implementation, so that it can disconnect it after the first invocation. > > However, we have this problem of boost::signals::connection management, > since one signal may be connected to different signals and we have > problem identifying the correct connection to be disconnected. So my > question is: Is there any easier way (i.e., ways that doesn't involve > the implementation of the slot function itself) that I can add a > single-shot signal-slot connection? > > Any suggestion is appreciated. Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

1 0

Re: [Boost-users] Boost serialization : concurrency (was Possibletoappend...)
by Robert Ramey 18 Sep '06

18 Sep '06

Hmmm - well that is interesting. I believe I used this idiom in order to address a problem where global static variables couldn't be guarenteed to be instantiated in a particular order and this was the fix recommended. So now what do we do? Robert Ramey Daniel F. Savarese wrote: > In message <eek3v5$hbk$1(a)sea.gmane.org>, "Robert Ramey" writes: >> So now you know my intention - and I believe that the code reflects >> that. > > Here's what's happening with > static oserializer & instantiate(){ > static oserializer instance; > return instance; > } > Thread 1 calls instantiate and is pre-empted in the middle of > constructing instance the first time control passes through its > declaration. Thread 2 then calls instantiate and returns a > reference to an incompletely constructed instance. Then thread 2 > bombs in basic_oarchive_impl::save_object the first time it tries to > dereference the object to invoke a virtual function > (in this case class_info()) of an incompletely constructed object > (i.e., no virtual function table). And now I'm reminded why whenever > I see a static local variable I have the knee-jerk reaction: > "not thread-safe." I had to reeducate myself by exercising the > debugger and revisiting what the C++ standard has to say about > the initialization of static storage. > > daniel > > -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- > http://www.savarese.org/ In distant lands, I hear the call of my > home. # s a v a r e s e > Yet my work is not done. My journey's just begun.- software > research -- http://www.sleepandthetraveller.com/ # > http://www.savarese.com/

1 0

[boost::serialization]: Dies with access violation (segfaults) reading beyond the end of archive.
by Konstantin Andreev 18 Sep '06

18 Sep '06

When 1) trying to restore from archive the pointer to sample class, and 2) archive is over at this moment boost::serialization causes Access Violation Fault in file: basic_iarchive.cpp, line 470: bpis_ptr = co.bpis_ptr; The code to reproduce the fault follows. -- Konstantin Andreev. ------------------------( cut here )---------------------- #include <iostream> #include <sstream> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> class Sample { private: int pod_int; std::string pod_str; template<class Archive> void serialize(Archive & ar, const unsigned int ){ ar & pod_int & pod_str; }; friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream & os, const Sample & sa ); public: Sample() {}; Sample( int _i, std::string _s ) : pod_int( _i), pod_str( _s ) {}; }; BOOST_CLASS_TRACKING(Sample, track_never) BOOST_CLASS_VERSION(Sample, 19) std::ostream & operator<<(std::ostream & os, const Sample & sa ) { return os << "-- int: " << sa.pod_int << ", str: >" << sa.pod_str << "< at 0x " << &sa << '\n'; } int main( void ) { Sample *obj_to = NULL; const Sample * const obj_fr = new Sample( 55, "**** test string *****" ); std::cout << *obj_fr; std::stringstream archbuf; boost::archive::text_oarchive *oa = new boost::archive::text_oarchive( archbuf, 3 ); *oa << obj_fr; std::cout << "-- archive content: >" << archbuf.str() << "<\n"; delete oa; boost::archive::text_iarchive *ia = new boost::archive::text_iarchive( archbuf, 3 ); *ia >> obj_to; std::cout << *obj_to; /////////////////////////////////// *ia >> obj_to; // ARCHIVE IS OVER. BOOM !!! /////////////////////////////////// std::cout << *obj_to; delete ia; return 0; }

2 2