- Boost - lists.boost.org

[review] Exception - result
by Tobias Schwinger 09 Nov '07

09 Nov '07

I'm pleased to announce that the Exception library has been accepted into boost. Thanks to all formal and informal reviewers and to Emil Dotchevski for the library! Summary of possible improvements: ================================= Design ------ Nearly all reviewers made suggestions for syntactic improvements. The "tag(value) syntax" (as suggested by John Torjo) for instance provides sufficient syntactic sugar and seems lightweight to implement. Suggested features in this area are (those are implementable on top of the current design - but will keep users from reinventing the wheel if provided by the library): - Support for grouping information, and - support for generating stack traces. I personally still have a bad feeling about 'enable_error_info' - let's just revisit and discuss it on the list before changing boost::throw_exception. The related discussions about clone/rethrow support is still ongoing. Documentation ------------- Best practices for the catch-site should be clarified in the documentation. Same goes for using the same tag multiple types with one exception object. Other comments should be addressed (I won't put much energy into summarizing documentation comments, guessing most of them might have been taken care of, already). Deployment ---------- There was a suggestion (from Pavel Vozenilek) to put #ifdef around the code of boost::exception that could be put into a separate translation unit. There should probably also be a 'build' directory and a Jamfile so there is smooth integration with the Boost build system. Of course, Jamfiles for test/examples should be added. Implementation -------------- Several reviewers noted that the library is rather allocation-heavy. It pretty much comes down to shared_ptr overuse (causing many unnecessary allocations of small objects and synchronized instructions to be executed) though not in performance critical code possibly affecting other threads and future allocations. -- Tobias Schwinger - Review Manager -

2 1

[interprocess] Atomic ops supports for Alpha processors.
by Markus Schöpflin 09 Nov '07

09 Nov '07

Hello, attached patch introduces support for the atomic ops needed by interprocess on Tru64/CXX/Alpha. It currently misses support for atomic add and sub, but those are not used right now. There are a few issues I would like to raise regarding the atomic operations: 1) Currently it is not specified whether an atomic operation implies a memory barrier or not. This should be explicitly stated. 2) atomic_sub32 does not return the old value, but atomic_add32 does. This seems inconsistent to me. 3) Has the use of the low level atomic ops API as proposed in WG21/N2047 (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html) been considered. If yes, why has it been rejected? If no, would it makes sense to use this API? 4) Is there a need for an atomic ops boost library? I seem to remember that other libraries need atomic ops as well. Regards, Markus Index: atomic.hpp =================================================================== --- atomic.hpp (revision 40078) +++ atomic.hpp (working copy) @@ -436,6 +436,82 @@ } //namespace interprocess{ } //namespace boost{ +#elif defined(__osf__) + +#include <machine/builtins.h> +#include <c_asm.h> + +namespace boost{ +namespace interprocess{ +namespace detail{ + +//! Atomically increment an apr_uint32_t by 1 +//! "mem": pointer to the object +//! Returns the old value pointed to by mem +inline boost::uint32_t atomic_inc32(volatile boost::uint32_t *mem) +{ return __ATOMIC_INCREMENT_LONG(mem); } + +//! Atomically decrement an boost::uint32_t by 1 +//! "mem": pointer to the atomic value +//! Returns false if the value becomes zero on decrement, otherwise true +inline bool atomic_dec32(volatile boost::uint32_t *mem) +{ return __ATOMIC_DECREMENT_LONG(mem); } + +// Rational for the implementation of the atomic read and write functions. +// +// 1. The Alpha Architecture Handbook requires that access to a byte, +// an aligned word, an aligned longword, or an aligned quadword is +// atomic. (See 'Alpha Architecture Handbook', version 4, chapter 5.2.2.) +// +// 2. The CXX User's Guide states that volatile quantities are accessed +// with single assembler instructions, and that a compilation error +// occurs when declaring a quantity as volatile which is not properly +// aligned. + +//! Atomically read an boost::uint32_t from memory +inline boost::uint32_t atomic_read32(volatile boost::uint32_t *mem) +{ return *mem; } + +//! Atomically set an boost::uint32_t in memory +//! "mem": pointer to the object +//! "param": val value that the object will assume +inline void atomic_write32(volatile boost::uint32_t *mem, boost::uint32_t val) +{ *mem = val; } + +//! Compare an boost::uint32_t's value with "cmp". +//! If they are the same swap the value with "with" +//! "mem": pointer to the value +//! "with" what to swap it with +//! "cmp": the value to compare it to +//! Returns the old value of *mem +inline boost::uint32_t atomic_cas32 + (volatile boost::uint32_t *mem, boost::uint32_t with, boost::uint32_t cmp) +{ + // Notes: + // + // 1. Branch prediction prefers branches, as we assume that the lock + // is not stolen usually, we branch forward conditionally on success + // of the store, and not conditionally backwards on failure. + // + // 2. The memory lock is invalidated when a branch is taken between + // load and store. Therefore we can only branch if we don't need a + // store. + + return asm("10: ldl_l %v0,(%a0) ;" // load prev value from mem and lock mem + " cmpeq %v0,%a2,%t0 ;" // compare with given value + " beq %t0,20f ;" // if not equal, we're done + " mov %a1,%t0 ;" // load new value into scratch register + " stl_c %t0,(%a0) ;" // store new value to locked mem (overwriting scratch) + " bne %t0,20f ;" // store succeeded, we're done + " br 10b ;" // lock has been stolen, retry + "20: ", + mem, with, cmp); +} + +} //namespace detail{ +} //namespace interprocess{ +} //namespace boost{ + #else #error No atomic operations implemented for this platform, sorry!

6 22

helper for managing legacy resources
by Ulrich Eckhardt 09 Nov '07

09 Nov '07

[Note: this is a repost, because there seems to be interest but at the time of the first post nobody responded.] Hi! I have a library here which I would propose for addition to Boost. It is a wrapper around a resource handle, just like std::auto_ptr is a wrapper around a pointer. The main difference to std::auto_ptr is that it doesn't overload operator-> and that it can (or, rather, must) be customized. Therefore it can also be used to hold resources like 'int' (a Unix filedescriptor) or 'FILE*' and also has the known ownership transfer semantics of std::auto_ptr. A few points I'd like to point out: * auto_ptr can hold a FILE*, too! No it can't, because it invokes delete on it while it wasn't allocated with new. * shared_ptr could hold a FILE! Yes, provided you give it a suitable deleter. However, shared_ptr does not provide exclusive ownership semantics and requires dynamic allocation for the reference counter. * It has the same size as std::auto_ptr (I'm assuming an implementation of auto_ptr that only wraps a pointer) and achieves the custom deleting via a policy type (type traits). * When wrapping e.g. an int, the type traits force you to specify whether the int is a timer ID or a filedescriptor, so you even get something like type safety on top of a type-depraved API. * When wrapping e.g. a win32 HANDLE (which is a very opaque type used for lots of things in the win32 API) you can even create traits that tell whether something is a windows handle or an event handle, even though both use the same function for releasing the resource. * You could wrap pointers, too, but since it isn't intended as a smart pointer the syntax would be a bit awkward. Of course, the way the pointers are deallocated would then be customizable, e.g. free() or delete[]. * The same type traits could be used to form a shared_ptr equivalent, but the places where I used this I haven't found the need for this yet. In fact I call exclusive ownership an advantage sometimes, because you precisely don't have to care about whether someone else might be accessing the resource. Also, there is no release() function which I admit is a dangerous function but it is useful nonetheless. I'd call it a sharp tool. I wrote something like this once for a Berkeley socket and once for a win32 thread handle before generalizing it into this class template. It is by no means production-ready (although the idea itself is) so I only want to present the library and some example code (see below) for discussion here. cheers Uli /* example program for a handle wrapper that behaves like std::auto_ptr This wrapper class can be customized with a traits type and then handle resources that are not released with delete, like C's FILE* or Unix filedescriptors. The main characteristics are captured by the trait class. For type FILE, a suitable specialisation is already provided, for other types you can do the same. For use with e.g. Unix filedescriptors, I wouldn't specialise the traits because they are plain ints and thus not a safe identifier for this kind of use (e.g. under win32, you need to differentiate between close() and closesocket(), depending on where you got the int from). Instead, you can use the fact that the first template parameter is only used as default for the traits and not(!) as real storage type. You then simply introduce a special type (the mere declaration of a simple, dedicated struct is enough) and the nested typedef inside the traits is the storage type: // incomplete dummy type, only used as ID for specialisation below struct filedescriptor; // specialize resource_traits template<> resource_traits<filedescriptor> { typedef int handle_type; ... }; auto_handle<filedescriptor> h(open("/dev/stdout", O_WRONLY)); if(h) write( *h, "Heya!", strlen("Heya!")); Note: other than std::auto_ptr, release() doesn't return the resource handle. The reason is that this first needs to be copied to a safe place (i.e. one that guarantees no resource leaks) before releasing ownership. // wrong: if insert() throws, the handle is lost and the // resource is leaked! container.insert(h.release()); // correct: container.insert(h.get()); h.release(); */ #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> /* traits class describing the resource behaviour */ template<typename ResourceHandle> struct resource_traits { /* nested typedef for the handle type Typically the same as the template parameter. */ typedef ResourceHandle handle_type; /* invalid signal value The equivalent of a NULL pointer. */ handle_type get_null() const; /* check for invalid signal values This is useed because there are cases where more than one signal value exists. */ bool is_valid(handle_type h) const; /* release the resource This is the equivalent to delete or free() for the resource type. */ void deallocate(handle_type h) const; }; template<typename ResourceHandle, typename ResourceTraits = resource_traits<ResourceHandle> > struct auto_handle: ResourceTraits { typedef ResourceTraits traits_type; typedef typename traits_type::handle_type handle_type; auto_handle(): m_handle(traits_type::get_null()) {} explicit auto_handle(handle_type h): m_handle(h) {} auto_handle( auto_handle& rhs): m_handle(rhs.get()) { rhs.release(); } auto_handle& operator=(auto_handle& rhs) { if(this!=&rhs) { reset(rhs.get()); rhs.release(); } return *this; } ~auto_handle() { traits_type::deallocate(m_handle); } struct ref { handle_type h; }; operator ref() { ref r = {m_handle}; release(); return r; } auto_handle(ref r): m_handle(r.h) {} auto_handle& operator=(ref r) { reset(r.h); return *this; } handle_type operator*() const { return m_handle; } handle_type get() const { return m_handle; } bool valid() const { return traits_type::is_valid(m_handle); } typedef bool (auto_handle::*boolean_type)() const; operator boolean_type() const { if(traits_type::is_valid(m_handle)) return &auto_handle::valid; else return 0; } // reset handle without deallocating associated resource void release() { m_handle = traits_type::get_null(); } // deallocate resource and reset handle void reset() { traits_type::deallocate(m_handle); m_handle = traits_type::get_null(); } void reset( handle_type h) { traits_type::deallocate(m_handle); m_handle = h; } private: handle_type m_handle; }; template<> struct resource_traits<FILE*> { /* nested typedef for the handle type Typically the same as the template parameter. */ typedef FILE* handle_type; /* invalid signal value The equivalent of a NULL pointer. */ static handle_type get_null() { return 0; } /* compare for invalid signal value This is useful for cases where more than one signal value exists. */ static bool is_valid(handle_type h) { return h!=0; } /* release the resource This is the equivalent to delete or free() for the resource type. */ static void deallocate(handle_type h) { if(is_valid(h)) { printf("deallocate(%p)\n", h); fclose(h); } } }; typedef auto_handle<FILE*> auto_file; auto_file open_file(char const* path) { auto_handle<FILE*> res(fopen(path,"r")); printf("open_file('%s') = %p\n", path, res.get()); return res; } struct filedescriptor; template<> struct resource_traits<filedescriptor> { typedef int handle_type; static handle_type get_null() { return -1; } static bool is_valid(handle_type h) { return h>=0; } static void deallocate(handle_type h) { if(is_valid(h)) { printf("deallocate(%d)\n", h); // TODO: check returnvalue close(h); } } }; typedef auto_handle<filedescriptor> auto_filedescriptor; auto_filedescriptor open_fd(char const* path) { auto_filedescriptor res(open( path, O_RDONLY)); printf("open_fd('%s') = %d\n", path, res.get()); return res; } int main() { { auto_handle<FILE*> f = open_file("/dev/null"); if(!f) printf("failed to open '/dev/null'\n"); f = open_file("/dev/stdout"); if(!f) printf("failed to open '/dev/stdout'\n"); open_file("/dev/null"); } { auto_filedescriptor fd = open_fd("/dev/null"); if(!fd) printf("failed to open '/dev/null'\n"); fd = open_fd("/dev/stdout"); if(!fd) printf("failed to open '/dev/stdout'\n"); open_fd("/dev/null"); } }

4 3

Documenting reused concepts
by Darren Garvey 09 Nov '07

09 Nov '07

[cross-posted this to boost and boost-docs; I can't guess how many people are interested in this.] I'm looking but can't seem to find any comment on how to document reused concepts, except for one very old, dead-end thread: http://lists.boost.org/Archives/boost/2002/09/35728.php Basically I'm in a situation where I want to reuse concepts from a couple of boost libraries so I obviously need to mention those concepts in my docs. What I'm doing now is linking to the concept documentation in the relevant library, which mostly works but I'm afraid it might confuse someone unfamiliar with the other library. The question is: how much concept documentation should lie outside individual libraries? I suppose there are some (many?) that are never going to be decoupled from any one library, but I thought the nature of a 'concept' - especially looking at C++0x stuff - favours general ones. The ones in Boost.Thread (* http://tinyurl.com/35tetq* - out of date, but still relevant) and Boost.Asio( *http://tinyurl.com/2acksh* - see the RH column) seem to be laid out/named like this. I for one think it would be intuitive and helpful if there were a place for library-agnostic concept documentation, somewhere. I get the impression that's the way things are going anyway. Also, since they concepts are usually documented anyway, *combining* the library-agnostic ones shouldn't be too demanding a task (I'm offering). Deciding what concepts are library-independent or even 'truly general' is another issue. I'm sure I can already smell smoke over my anosmia. :-) I was thinking a general concept interface, perhaps a C++0x-style definition too (*http://tinyurl.com/2xhzpr*), plus links to the libraries that use them and/or the types that implement them would be all that's needed. Is there any interest in this? Any fundamental objections? Am I just entering a world of pain? Regards, Darren P.S. This would fit in nicely with the STL concept documentation effort that Andrew Sutton's been working on (see *http://tinyurl.com/3x92du*).

1 0

Why have forward container declaration in boost/functiona/detail/container_fwd.hpp?
by Yingwei Zhang 09 Nov '07

09 Nov '07

Hello - I am migrating our code base from boost 1.33.1 to 1.34.1. Some changes in boost/functional is causing compilation issues. The hash.hpp in 1.33 does include std container header files. In 1.34.1, however, forward declaration is added as following: #if (defined(__GLIBCXX__) && defined(_GLIBCXX_DEBUG)) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) #include <deque> #include <list> #include <vector> .... #else namespace std { ... template <class T, class Allocator> class list; template <class T, class Allocator> class vector; template <class Key, class T, class Compare, class Allocator> class map; ... } I am working on Darwin with gcc 4.0.1, and the #if test is not true, so we fall through the #else path, with only forward declaration. If my code does not include standard container headers explicitly, it will not compile with boost 1.34.1. Of course the easy fix is to add the standard container header in my code instead of depending on boost to pull it in. What is the reason behind this change? Thanks for explanations. Yingwei

4 4

slightly off topic question
by Robert Ramey 09 Nov '07

09 Nov '07

I'm using the gcc compiler with cygwin. In a couple of my testsI'm getting warnings like this in debug mode and crash in release mode.I'm not having any problem with my VC 7.1 compiler.Does anyone know what normally provokes this?Robert Ramey/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_list.h: In function `int test_main(int, char**)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_list.h:435: warning: '__p' might be used uninitialized in this function /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_list.h:435: warning: '__p' might be used uninitialized in this function /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_list.h: In member function `void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive, T = std::list<A, std::allocator<A> >]': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_list.h:435: warning: '__p' might be used uninitialized in this function /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/slist: In member function `void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive, T = __gnu_cxx::slist<A, std::allocator<A> >]': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/slist:285: warning: '__node' might be used uninitialized in this function

1 0

libs/graph/build/Jamfile.v2 suspicious unmerged changes
by David Abrahams 09 Nov '07

09 Nov '07

Could someone check this file out to make sure all the right changes have been merged from 1.34.0 into trunk? Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

12 23

Boost Exception and support for cloning
by Emil Dotchevski 09 Nov '07

09 Nov '07

In the Boost Exception review process, several people have expressed the opinion that since boost::exception (part of the proposed library) is designed to act as a base class for all Boost exceptions, it should also support cloning. This can be done by adding a clone() virtual function to boost::exception. There are several issues we have to consider. First, should clone() be pure virtual, which would require all deriving exceptions to implement it? This can be achieved by modifying boost::throw_exception to throw a type that derives from the passed exception type and implements clone(). If we go that route, we must make sure that Boost does not contain a "naked" throw statement (that is, a throw that does not call boost::throw_exception.) This should be fine, since Boost libraries are required to call boost::throw_exception anyway. However, the functionality provided by boost::exception would be desirable for user code as well, and thus it would make sense for user-defined exception types to derive it. Which raises my second question: should then user code also be required to throw exceptions by calling boost::throw_exception? Emil Dotchevski

5 11

How to create boost rpm
by Yingwei Zhang 08 Nov '07

08 Nov '07

Hi, I need to create rpm packages for linux/darwin. However, I could not find the boost.spec file to specify how to build the package. Do I need to write my own or I can find it somewhere on the internet? I checked the cvs repository and source download and could not find anything. Thanks for help. Ywz

1 0

[serialization] Assertion while serializing polymorphic type through pointer to base class
by Hartmut Kaiser 08 Nov '07

08 Nov '07

Hi all, I'm trying to serialize a polymorphic type through a pointer (shared_ptr) to a base class and I'm getting an assertion deep inside the library here: archive/detail/oserializer.hpp, line 417. I'm using V1.34.1 for this. Is there anything known about this assertion? Anything obvious I'm missing? Regards Hartmut

1 0