November 2007 - Boost - lists.preview.boost.org

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

What does a milestone of "release" mean?
by John Maddock 08 Nov '07

08 Nov '07

Looking at http://svn.boost.org/trac/boost/report/3 We have a large number of reports with a milestone of "release" whatever that may be ! Many of these appear to be old, and/or no longer relevant, looks like these need triaging and either assigning to 1.35 or "To be determined" (or whatever we call it). John.

3 2

[trunk] people folder missing?
by Joaquín Mª López Muñoz 08 Nov '07

08 Nov '07

Excuse me if I'm missing something obvious, but this looks like an oversight to me: there's no people folder at the trunk. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3