May 2009 - Boost - lists.preview.boost.org

Re: [boost] Interest check: container with preallocated buffer
by Brian Wood 19 May '09

19 May '09

Thorsten Ottosen writes: >>Dmitry Vinogradov skrev: >> Boost.Array offers constant size container with preallocated buffer, >> Boost.Optional provides from zero to one element. There are no STL >> container with preallocated buffer and it seems custom allocator does >> not help to do this with existing containers. >> >> Does any container exist to offer functionality like Boost.Array but >> allowing to store from 0 to N elements? Is there any interest in such >> container? >> >> PS. It's similar to fixed_string but as a generic container. >Please see >http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip >http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/ > I was looking at the documentation and the Serialization and "Differences from std::vector<T>" pages were both empty. It would be nice to indicate there's nothing there yet for those pages. On the Semantics page is says: auto_buffer( const auto_buffer& r ); - *Effect:* Copy constructor. - *Postconditions:* capacity() == max(r.size(),N) && size() == r.size() . - *Throws:* Nothing if size() <= N and the copy constructor of T cannot throw. Otherwise this might throw exceptions from the allocator of from T's copy constructor. I think there's a typo in the last sentence there. -- Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the LORD has helped us.'"

2 1

[array] assignement operator
by vicente.botet 19 May '09

19 May '09

Boost.Array defines an assignement operator with the following prototype template<typename T, std::size_t N> class array { public: /... template<typename U> array& operator=(const array<U, N>& rhs); // Effects:std::copy(rhs.begin(),rhs.end(), begin()) }; I was wondering if this can be extended to manage with arrays of different sizes, having as effect the copying of the minimum of N and M elements from the source to the target. template<typename T, std::size_t N> class array { public: /... template<typename U, std::size_t M> array& operator=(const array<U, M>& rhs); // Effects:std::copy(rhs.begin(),rhs.begin()+min(N,M), begin()) }; Is there anything wrong with this interface? Best, _____________________ Vicente Juan Botet Escribá

5 11

Boost up for SourceForge Community Choice Award
by David Abrahams 19 May '09

19 May '09

Cast your vote here: http://tinyurl.com/boost-cca09 Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[thread] Exception propagation for thread::join
by Emil Dotchevski 18 May '09

18 May '09

When joining a thread, in case the thread has exited, I find it convenient to have any exception the thread function throws propagated to the caller of join(). Just as an illustration of what I'm talking about, below is my Win32 implementation of a similar interface. An interesting design decision is what to do if a detached thread throws an exception. Note the line marked with (1) -- I've decided to assert in this case (instead of ignoring the exception, which would be the alternative behavior.) Would something similar be a good addition to Boost Thread? struct windows_thread_info { DWORD id; boost::shared_ptr<HANDLE const> h; boost::function<void()> f; mutable boost::exception_ptr e; boost::shared_ptr<windows_thread_info> self; ~windows_thread_info() { assert(!e); } }; namespace { DWORD WINAPI thread_proc_fwd( void * p ) { assert(p!=0); boost::weak_ptr<windows_thread_info> w; boost::function<void()> f; { boost::shared_ptr<windows_thread_info> wti; static_cast<windows_thread_info *>(p)->self.swap(wti); assert(wti); f=wti->f; assert(f); w=wti; } try { f(); } catch( ... ) { boost::shared_ptr<windows_thread_info> wti=w.lock(); assert(wti); //(1) wti->e=boost::current_exception(); } return 0; } } boost::shared_ptr<windows_thread_info const> win_CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, boost::function<void()> const & f, DWORD dwCreationFlags ) { assert(f); boost::shared_ptr<windows_thread_info> wti(new windows_thread_info); wti->f=f; wti->self=wti; if( HANDLE h=CreateThread(lpThreadAttributes,dwStackSize,thread_proc_fwd,wti.get(),dwCreationFlags,&wti->id) ) { make_handle(h,CloseHandle).swap(wti->h); return wti; } else { wti->self.reset(); BOOST_THROW_EXCEPTION(x_system() << xi_win_last_error(GetLastError()) << xi_function("CreateThread")); } } void join( windows_thread_info const & wti ) { (void) win_WaitForSingleObject(*wti.h,INFINITE); boost::exception_ptr e; { using std::swap; swap(e,wti.e); } if( e ) boost::rethrow_exception(e); } -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 3

git clone up
by troy d. straszheim 18 May '09

18 May '09

In case this reaches any other git enthusiasts, I've rigged up a git clone that is automatically tracking boost svn, here: http://sodium.resophonic.com/git/boost/ Click around on it... it's smoking fast, despite the fact that it is running on hardware I found in the trash on the end of a mediocre uplink. There is a little howto here: http://sodium.resophonic.com/git/boost/about/ The repository (minus checkout) is about 150M, it contains branches and tags going all the way back. It will take a while to do the initial clone but fetches after that are very fast. -t

4 8

release notes for 1.39.0?
by Neal Becker 18 May '09

18 May '09

Where can I find some more detailed release notes? I looked here: http://comments.gmane.org/gmane.comp.lib.boost.announce/233

2 1

[serialization] Enum loading may lead to uninitialized value [Ask for change]
by Andrey Upadyshev 18 May '09

18 May '09

Hi! I found that template boost::archive::detail::load_enum_type (boost\archive\detail\iserializer.hpp) may overvrite loading enum's value with uninitialized ones. See comments: template<class Archive, class T> struct load_enum_type { static void invoke(Archive &ar, T &t){ int i; // Initialize 'i' with trash ar >> boost::serialization::make_nvp(NULL, i); // Imagine: some code in archive skips loading t = static_cast<T>(i); // Ooops, get the trash into 't' } }; I think it is more secure to initialize 'i' from 't'. So, if archive's code skips loading, we just get 't' unchanged instead of corrupted. Probably, someone can fix this in svn? Andrey Upadyshev P.S. Sorry for my English.

2 2

[regex] patch for Sun CC
by Steven Watanabe 18 May '09

18 May '09

AMDG To get regex to work with Sun 5.9, I had to add std:: in one place. Most of the tests pass, but a few still fail for mysterious reasons. Okay to commit? In Christ, Steven Watanabe

2 1

[boost1.38][serialization][Patch Request] Request a patch for fixing crashes on SunOS 64bit platform
by Joanne chiang 18 May '09

18 May '09

Hi, Please consider : 1. fixing the regression issues (iostream error/exception, segmentation faults , illegal instruction etc.) happened when running the testsuite bundled with boost.serilation (v1.38, though I believe it applies to other revisions) on SunOS 5.8 sparc v9 (5.9, 5.10 64-bit also get the same crashes). 2. adding SunOS 64bit platform to the boost regression test trunk : http://www.boost.org/development/tests/trunk/developer/serialization.html ,if possible. Thanks very much, Mave

2 4

Re: [boost] [filesystem] copy_file() not atomic proposed fix
by Beman Dawes 17 May '09

17 May '09

On Fri, May 15, 2009 at 5:10 AM, Andre Merzky <andre@...> wrote: > Quoting [Beman Dawes] (May 12 2009): >> >> Ticket #2925 complains that "boost::filesystem cannot atomically copy >> file if target exists" ... >> >> ... >> >> The proposed solution is to add an option to copy_file(): >> >> enum class copy_option { fail_if_exists, overwrite_if_exists }; >> >> void copy_file( const Path & from_path, const Path & to_path, >> copy_option option=copy_option::fail_if_exists ); >> >> The implementation would be atomic on both POSIX and Windows. >> >> Comments? > > Makes sense. OK, fix committed to trunk. It will go in branches/release once sufficient regression tests have cycled. > I would suggest to check the complete lib for similar > problems. I think most operational and convenience > functions are prone to similar problems. Hum... "most" is too strong; many of the operational functions are implemented as a single operating system API call. I really don't want to spend time analyzing and fixing the V2 codebase. Instead, I've added an item to the V3 do-list to do an atomicity review. I'm planning to spend a lot of time on Filesystem.V3 this summer, and release a V3 beta as the code firms up. Thanks, --Beman

1 0