- Boost - lists.boost.org

[Test] BOOST_TEST removed?
by Doug Gregor 04 Feb '05

04 Feb '05

BOOST_TEST has been used for testing Boost since the dawn of time, but it's just been removed from CVS, breaking a whole lot of test cases both in Boost and elsewhere. Some warning would have been nice. Not removing it would have been nicer. Doug

11 26

[iostreams] MAP_FILE not available on some platforms
by Caleb Epstein 04 Feb '05

04 Feb '05

The iostreams module mapped_file.cpp fails to compile on (at least) Solaris because it makes use of the mmap flag MAP_FILE which does not exist on that platform. I think this should be protected in an #ifdef MAP_FILE block or similar. http://tinyurl.com/4gv9p -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Bug in Boost.Thread?
by John Eddy 04 Feb '05

04 Feb '05

I noticed a potential hazard in exceptions.cpp of the thread library. The method: const char* thread_exception::message() const returns the c_str of a string with local scope. This is a problem at least in VC 7 .NET 2003. The error can be exposed by the following code. try { throw boost::lock_error(1); } catch(boost::lock_error& e) { cerr << e.message(); } Thanks, John

2 2

[boost.range] RFC on small updates
by Thorsten Ottosen 04 Feb '05

04 Feb '05

Hi All, I have planned to add a few extra convenience function to iterator_range and sub_range. Some people have said the classes could have been a little easier to use. The changes I suggest are the following: iterator_range: -------------- value_type& front() const; value_type& back() const; value_type& operator[]( size_type ) const; value_type& at( size_type ) const; void advance( size_type ); void narrow( size_type left, size_type right ); iterator_range& operator++(); value_type& operator*() const; sub_range: ---------- the same, but now constness is propagated freestanding: ------------ iterator_range make_sub_range( range&, size_type left, size_type right = 0 ); iterator_range make_super_range( range&, size_type left, size_type right = 0 ); iterator_range make_range( range&, difference_type left, difference_type right = 0 ); Comments? -Thorsten

6 18

atomic_count on MSVC/Win32, Tim Fenders optimization
by Hauptmann Peter 04 Feb '05

04 Feb '05

Hi, I noticed that boost/detail/atomic_count.hpp uses the intrinsic verisons of _InterlockedIncrement, _InterlockedDecrement only for Win64 builds. is there a reason? it is documented for VC 2003 without target platform restrictions (and it's "known to work" on VC6, too). thanks peter __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

2 1

Singleton/Multiton Longevity
by Jason Hise 04 Feb '05

04 Feb '05

Just a status update on the singleton/multiton library, so that people know I am still alive ;). After much chaos trying to write a multiton longevity lifetime policy, I had the sudden realization that both singletons and multitons should be able to play nicely together. Thus, I am writing a single(ton) class to manage a priority queue of shared_ptrs to nodes. The longevity policies will derive privately from their respective dependency policies, and create their own derived node types which hold dependencies. As the inheritance is private, these will be the only dependencies in existence. Both multitons and singletons will be destroyed as the dependency-holding nodes are popped in the destructor of the instance registry, which itself will have a static dependency to ensure existence for the entire lifetime of the program. Thoughts and suggestions, as always, are welcome. -Jason

2 2

Semaphore in boost.Thread
by Serguei Kolos 04 Feb '05

04 Feb '05

Hello As far as I know semaphores have been removed from the boost.Thread library. But the point is that on many platforms (Linux for example) semaphore is the only async-signal safe synchronization object. Does anybody know how to synchronize signal handlers with the other programming threads without semaphores? Cheers, Sergei

1 0

A swapping implementation of the C++ library
by Chris Jefferson 04 Feb '05

04 Feb '05

While this isn't strictly related to the development of boost, I believe it may be interesting to developers of boost, and I would also be very interested in hearing any opinions (good and bad) from users and developers of boost. I am currently in the process of implementing all applicable (sort, rotate, partition, etc..) functions in the C++ standard library using only calls to iter_swap. Obviously for those classes with expensive copies and cheap swaps (list, vector, map, set, etc) this is a big win, however it unfortunatly can be slightly slower for classes and types which fall on the basic definition of swap. Therefore there will be an implementation-specific type trait defined (name to be decided) which can be defined to enable the swapping versions of functions. I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library). While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements. I would be interested in knowing if anyone has any comments, and also should such code be implemented in g++ if boost would be willing to add the compiler-specific extra information to mark any classes with efficent swap as such. Note: I am aware there are various ways of trying to approximate if someone has specialised swap, such as checking for a swap member function. However at least at first, it is my belief such a library should probably be strictly op-in. Thank you, Chris

2 2

boost v 1.33 ?
by Robert Ramey 04 Feb '05

04 Feb '05

Could we consider fixing a date for boost 1.33. I would like to agree to just concentrate on fixes, tests and resolving pending issues regarding code currently checked into cvs.. I think this would be relatively painless - at least compared to the last time. Robert Ramey

8 19

[serialization] add_facet question
by Jonathan Turkanis 04 Feb '05

04 Feb '05

Hi Robert, I'd like to use add_facet from serialization in the iostreams library, but I don't understand why the generated locale is dynamically allocated. It would seem be more reusable to declare it as follows: template<typename Facet> inline std::locale add_facet(const std::locale& loc, Facet* facet); If you need a dynamically allocated locale, you could write new std::locale(add_facet(loc, facet)) Jonathan

2 4