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

[thread] is there an interest on this unique_to_shared_mutex_adapter class?
by vicente.botet 30 May '08

30 May '08

Hi, boost::mutex is a model of Lockable but do not conforms to a SharedLockable, UpgradeLockable concepts. Do you think that we can make an adapter of boost::mutex to be a model of SharedLockable, UpgradeLockable or there is something I've missed? Consider the following situation: template <class SharedLockable> void f(SharedLockable&l) const { /*< externally locked generic const function>*/ boost::shared_lock<Lokable> lock(smtx); // ... some read operations } // elsewhere boost::mutex mtx; /*< the external user prefer to use a mutex and not a shared_mutex >*/ // { shared_lockable_adapter smtx(mtx); /*< mtx must be adapted to a shared_mutex >*/ f(smtx); /*< to call f without compiler errors >*/ //.. } Do you know a simple way to achieve this? Do you think this adapter could be of general use? The class shared_lockable_adapter can be defined as follows: template <typename Lockable> class shared_lockable_adapter { shared_lockable_adapter(Lockable& mtx): mtx_(mtx) {} ~shared_lockable_adapter() {} void lock_shared() {mtx_.lock();} void unlock_shared() {mtx_.unlock();} bool try_lock_shared() { return mtx_.try_lock();} void lock() {mtx_.lock();} void unlock() {mtx_.unlock();} bool try_lock() { return mtx_.try_lock();} // other functions .... private: Lockable& mtx_; }; Comments? _____________________ Vicente Juan Botet Escriba

4 5

"joinable"
by David Abrahams 30 May '08

30 May '08

Seems to me that if we have "detach()," it we should be asking whether a thread is "attached()," rather than "joinable()." Our documentation says "if *this refers to a thread of execution..." all over it, which would seem to indicate that joinable() is an important question even when you're not about to join(). Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

7 30

trac version entry for branches/release is missing
by Maik Beckmann 30 May '08

30 May '08

Hi, I would like to make a bug report for the code in branches/release, but trac doesn't got an version entry for this one. Is this by intention? -- Maik

2 2

boost::filesystem::remove() throws on some symlinks
by dizzy 30 May '08

30 May '08

Hello If one creates a symlink like this "ln -s sym sym" (to itself symlink), bfs::exists("sym") will throw because the documentation defines it to do so (and I have nothing against it doing so, although in my programs because of this I am forced to just use "lstat()" and I can't replace using "lstat()" to check if something exists with bfs::exists). However, I do think that bfs::remove("sym") throwing for the same reason (because it calls upon bfs::exists()) is the wrong thing to do. The source around bfs::remove() implementation even try to solve the issue of "dangling symlinks" as they call it by having an exception in case bfs::exists returns false and the target path points to a dangling symlink and still tries to remove it. Unfortunetly, exists will throw in my example of a symlink (not even dangling technically speaking :) ) even tho a remove on that kind of symlink should work just fine (it does work in shell or just doing std::remove()). Is this a bug? If so, I should put it in the tracker? Thanks! -- Mihai RUSU Email: dizzy(a)roedu.net "Linux is obsolete" -- AST

2 3

Review Request: future library (Gaskill version)
by Braddock Gaskill 30 May '08

30 May '08

I wanted to formally request a review of my Futures library. Latest Version: http://braddock.com/~braddock/future/ The library has matured greatly over the past year. It has been heavily used as a key component in a mid-sized commercial application on both Linux and Windows. Extensive unit tests and (just now) documentation have been written - in fact there are more than twice as many lines of test code and documentation than are in the library proper. The library incorporates many ideas from this list, from other prospective submissions, other languages, and from academic papers. The library does not currently use jamfiles or boostdoc (I tried I really did). It is a header-only library. The documentation is currently straight HTML, and should be very easy to translate to boostdoc if the submission looks good. NOTE - to avoid confusion, note that there is an older 2005 boost.future candidate in the vault by Thorsten Schuett that is not related to mine (although it was studied early on). Thanks, Braddock Gaskill braddock(a)braddock.com

10 100

[thread] suspend/resume functions
by vicente.botet 30 May '08

30 May '08

Hello, Currently we can interrupt a thread. Have the functions suspend/resume a sens for a thread? Best regards Vicente

2 1

[config] C++0x macros
by Beman Dawes 30 May '08

30 May '08

There was some past discussion of changing the C++0x BOOST_HAS_* macros to BOOST_NO_*. Several participants thought that was better for the long run. Who needs to do what to make this happen? The motivation for asking is that I'm starting to update some Boost code that could benefit from C++0x features and so would like to start using these macros. Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null? --Beman

14 31

[spirit] 'nother patch, (building example5.cpp on gcc4.2), attribute_transform.hpp
by troy d. straszheim 30 May '08

30 May '08

Hi again guys, This one is easier. Having applied the assign_to/construct patch, examples 4 and 6 compile fine, but example5.cpp died on this: example5.cpp:283: instantiated from here ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:144: error: ambiguous class template instantiation for 'boost::spirit::traits ::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:144: error: invalid use of incomplete type 'boost::spirit::traits ::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:32: error: declaration of 'boost::spirit::traits::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' You just disambiguate via enable_if to get things building. Works on gcc4.2: --- attribute_transform.hpp (revision 45915) +++ attribute_transform.hpp (working copy) @@ -11,6 +11,7 @@ #include <boost/spirit/home/support/unused.hpp> #include <boost/spirit/home/support/component.hpp> #include <boost/spirit/home/support/attribute_of.hpp> +#include <boost/spirit/home/support/detail/values.hpp> #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/is_sequence.hpp> #include <boost/variant/variant_fwd.hpp> @@ -25,16 +26,19 @@ namespace traits { + using boost::spirit::detail::not_is_variant; + // Here, we provide policies for stripping single element fusion // sequences. Add more specializations as needed. - template <typename T, typename IsSequence> + template <typename T, typename IsSequence, typename Enable = void> struct strip_single_element_sequence { typedef T type; }; template <typename T> - struct strip_single_element_sequence<fusion::vector<T>, mpl::false_> + struct strip_single_element_sequence<fusion::vector<T>, mpl::false_, + typename boost::enable_if<not_is_variant<T> >::type> { // Strips single element fusion vectors into its 'naked' // form: vector<T> --> T @@ -42,7 +46,8 @@ }; template <typename T> - struct strip_single_element_sequence<fusion::vector<T>, mpl::true_> + struct strip_single_element_sequence<fusion::vector<T>, mpl::true_, + typename boost::enable_if<not_is_variant<T> >::type> { // Strips single element fusion vectors into its 'naked' // form: vector<T> --> T, but does so only if T is not a fusion Let me know if you just want a commit, (also for the other stuff). There are a few more things like this around, I'll get after them. Thanks for a great library (these little gotchas notwithstanding). I'm getting a real kick out of all this, learning a lot... this code is *crazy*. You guys have definitely raised the bar. -t

2 1

[date_time] boost time is lacking a big bang
by Joachim Faulhaber 29 May '08

29 May '08

Hi! My first goal in boostifying my proposed interval template library (ITL http://sourceforge.net/projects/itl) was to provide good examples for interval_sets and interval_maps using boost::date_time objects. This was much harder than I had expected, because incidentally the most important syntactical and semantical requirements that I do rely on for a parameter T of itl::interval<T> are not provided by boost::date_time. The one property of boost::date_time that knocked my socks off was the default constructor that 'is-not-a-date-time'. I paraphrase this as: boost::time is lacking a big bang ;-) Default constructors in nearly all the types that I've seen in my lifetime (I know the realm of my unknown unknowns is vast ;-) are intended to be elements of the type they do construct. Moreover in so many cases including built in types, default ctors serve as *initial elements*. Other elements can be *reached* from T() applying operations of T on them. This applies to all built in types and many std::types, like e.g. string, set, list etc. The most simple instance is unsigned int() with increment operation ++ that resembles the Peano axiomatic operations 0 and successor for natural numbers. This semantics of default ctors, at least in common built in and standard types and also in so many user defined types is so fundamental that I took it as a *semantical invariant* for the construction of my library. In the ITL an empty interval<T> [1,0] for instance, has to be defined generically: [ type<T>::unon(), type<T>::neutron() ] where type<T>::neutron() is implemented via T() : the default ctor and type<T>::unon() is implemented via ++T() : the default ctor incremented exactly once. So, striving to be as generic as possible I tried to set those minimal requirements that I assumed to be common sense: For discrete types T, the existence of an initial value T() and In(De)crementation. Instead of being a big bang of time, boost::date_times default constructors are cannibals. They give birth to a date_time() object that they immediately swallow. Then saying schizophrenic things about themselves like: cout << to_simple_string(ptime()); "not-a-date-time" They are singularities having an infinite gravitational pull on any operators. You can apply as many of them on the constructed black whole and they are never seen again having no effect. In addition to making the expected source of all elements of boost::date_time an awesome creature to be avoided, the universal c++ way of saying the next object within minimal distance '++' has also been taken away from me. May be with the good intension to prevent me from doing silly things like iterating over whole centuries in nanoseconds ;-) Yet all my applications of ++ and -- in my generic code use them only once like in comparing intervals of discrete types (a, b] == [c, d] is true, if(++a==c && b == d) that have different borders. I only have to make sure here that the minimal distance is proceeded only once. To summarize: What I have been relying on in my design, an initial default ctor T() and an increment operator ++ on the least availabel distance unit is exactly not provided by boost::date_time. Now the good news: Both libraries are so well designed that these seemingly contrarian designs can still be coupled with relatively small changes. Specifically, which is crucial for me, I can adapt my libraries code so that I can use all of boost::date_time in it's current form without patching anything (which would also work as I wrote in my last posting). The seemingly most decoupled remedy was, to implement the the missing functions type<T>::neutron() as well as increment ++ and decrement -- operators using the public interface of boost::date_time. This had to be done for every boost::date_time type like e.g. ptime: itl/ptime_adapter.hpp: ------------------------------------------------------------- boost::posix_time::ptime operator ++(boost::posix_time::ptime& x) { return x += boost::posix_time::ptime::time_duration_type::unit(); } boost::posix_time::ptime operator --(boost::posix_time::ptime& x) { return x -= boost::posix_time::ptime::time_duration_type::unit(); } template<> inline boost::posix_time::ptime type<boost::posix_time::ptime>::neutron() { return boost::posix_time::ptime(boost::posix_time::min_date_time); } ------------------------------------------------------------- Drawbacks of this are: (1) Designs are not completely decoupled, for every boost::a_date_time the matching adapterfunctions must be included. This is a complication for the usage. (2) *Every* generic library that relies on the existence of an initial default ctor and incrementation has to provide an adapter. (3) Every adapter has to be maintained, when boost::date_time is changed. (Kind of a distributed responsibility that is error prone) I would suggest, that a type that in it's basic characteristics resembles an intergral numeric type like boosts date_time types, that type should follow the concept Integral. cheers Joachim Interval Template Library download from http://sourceforge.net/projects/itl documentation http://www.herold-faulhaber.de/

5 9

[smart_ptr] trunk version of enable_shared_from_this incompatible with TR1
by Daniel Frey 29 May '08

29 May '08

TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this. Regards, Daniel

6 25