February 2010 - Boost - lists.boost.org

[BGL/PM] Composition of two property maps
by Matthias Walter 16 Feb '10

16 Feb '10

Hi, I currently have a function which gets a graph plus an index-map and want's to call a BFS. Therefore it needs to build a color-map which maps vertex_descriptors to colors. As the user already gives a way to map vertex_descriptor to index, I'd like to use this mapping. What I need is a way to define a property map as a composition: composed-map (vertex_descriptor) -> color via color-map (index-map (vertex_descriptor)) -> color whereas index-map (vertex_descriptor) -> index and color-map (index) -> color Of course this should not be too difficult to implement, so I'd just like to ask whether there already exists some kind of implementation, because I neither found a hint by looking in the docs, nor by digging through some of the code. The actual reason I ask is because there might be other ways to come around the problem, e.g. making the color-map itself use vertex_descriptors as keys, so maybe my suggested solution is not the best. best regards Matthias Walter

2 1

C++0x and MSVC 10
by Zachary Turner 16 Feb '10

16 Feb '10

Playing with the release candidate of MSVC 10, and I'm noticing boost 1.42.0 is not using any C++0x features. Has this been discussed before, or is there a reason for this? Taking a peek at boost/config/compiler/visualc.hpp, I see the following: #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #endif // _MSC_VER < 1600 // C++0x features not supported by any versions #define BOOST_NO_CHAR16_T #define BOOST_NO_CHAR32_T #define BOOST_NO_CONCEPTS #define BOOST_NO_CONSTEXPR #define BOOST_NO_DEFAULTED_FUNCTIONS #define BOOST_NO_DELETED_FUNCTIONS #define BOOST_NO_EXPLICIT_CONVERSION_OPERATORS #define BOOST_NO_EXTERN_TEMPLATE #define BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS #define BOOST_NO_INITIALIZER_LISTS #define BOOST_NO_RAW_LITERALS #define BOOST_NO_SCOPED_ENUMS #define BOOST_NO_SFINAE_EXPR #define BOOST_NO_TEMPLATE_ALIASES #define BOOST_NO_UNICODE_LITERALS #define BOOST_NO_VARIADIC_TEMPLATES It almost appears as if the #else was simply forgotten on the first #if. Can't we safely change the first conditional to the following? #if _MSC_VER < 1600 #define BOOST_NO_AUTO_DECLARATIONS #define BOOST_NO_AUTO_MULTIDECLARATIONS #define BOOST_NO_DECLTYPE #define BOOST_NO_LAMBDAS #define BOOST_NO_RVALUE_REFERENCES #define BOOST_NO_STATIC_ASSERT #define BOOST_NO_NULLPTR #else #define BOOST_HAS_AUTO_DECLARATIONS #define BOOST_HAS_AUTO_MULTIDECLARATIONS #define BOOST_HAS_DECLTYPE #define BOOST_HAS_LAMBDAS #define BOOST_HAS_RVALUE_REFERENCES #define BOOST_HAS_STATIC_ASSERT #define BOOST_HAS_NULLPTR #endif // _MSC_VER < 1600 Zach

7 13

boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR
by Vincent Lefevre 16 Feb '10

16 Feb '10

Hi, I'm a MPFR developer and the following problem with Boost has been reported in the MPFR mailing-list. As of Boost 1.42, the macros INTMAX_C and UINTMAX_C (in particular) are always defined, and on a system without <stdint.h> (Microsoft C++ compiler), the build of a program using Boost 1.42 and MPFR failed. The reason is that mpfr.h supports systems with and without intmax_t (so that it does not force <stdint.h> inclusion), thus it must have a way to determine when intmax_t is available, without requiring the user to do anything else than including <stdint.h> first. So, it has several heuristics, one of them being the test of the existence of INTMAX_C and UINTMAX_C. Indeed, in C, which does not have namespaces, it is rather intuitive that the existence of INTMAX_C and UINTMAX_C implies that the corresponding types intmax_t and uintmax_t are available. However, in C++ with Boost, intmax_t and uintmax_t are not necessarily available (in the global namespace). Even though one could specify a macro for MPFR that would allow the user to disable (u)intmax_t support explicitly, I think that Boost's behavior is rather awkward, and may break other software too (in particular libraries that would do the same kind of things as Boost). Indeed (correct me if I'm wrong, I don't know very much about C++), while types have namespaces, macros don't, but there are conventions under which using a prefix such as BOOST_ can be used in place of a namespace (to avoid conflicts with other software). So, I wonder why Boost doesn't do the following: since it defines the intmax_t and uintmax_t types in the boost namespace, it should use the BOOST_ prefix for the corresponding macros, e.g. BOOST_INTMAX_C and BOOST_UINTMAX_C. The only acceptable artifact concerning these types would be that additional types and macros be defined due to the inclusion of standard headers such as <stdint.h>; but in such a case, the behavior would remain consistent (i.e. INTMAX_C and UINTMAX_C would be defined only if intmax_t and uintmax_t are available). If, for some reason, Boost really needs to define the INTMAX_C and UINTMAX_C macros, then it should also define intmax_t and uintmax_t in the global namespace. But I don't think that's a good idea. Regards, -- Vincent Lefèvre <vincent(a)vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

2 4

[thread] Moving a `recursive_lock`
by Daniel Trebbien 16 Feb '10

16 Feb '10

Hello all, I have been working on a project that uses the Boost Thread library, and I realized that there is a part of the code that needs to transfer a lock to a thread that has just been started. My idea for implementing this was to use a `boost::recursive_mutex` and pass a non-`const` reference to a `boost::recursive_mutex::scoped_lock` to the thread via `boost::ref`. Also, to ensure that the `scoped_lock` does not go out of scope until until the lock is moved, I thought to use a `boost::barrier`. After writing some test code, I find it interesting that if I use a `recursive_mutex`, then an assertion fails, but if I use a `boost::mutex`, then the code seems to work fine. Here is the test code that I have been experimenting with (the `recursive_mutex` version, which is also attached): #include <iostream> #include <boost/ref.hpp> #include <boost/thread.hpp> static boost::recursive_mutex s_mutex; static boost::barrier s_lockMoveBarrier(2); void thread_fun1(boost::recursive_mutex::scoped_lock& lock_) { //boost::recursive_mutex::scoped_lock testLock(s_mutex); // uncommenting this causes deadlock, as expected std::cout << "in `void thread_fun1(...)`: moving lock..."; boost::recursive_mutex::scoped_lock lock2(boost::move(lock_)); std::cout << "done" << std::endl; s_lockMoveBarrier.wait(); std::cout << "in `void thread_fun1(...)`: after the barrier" << std::endl; } int main() { boost::recursive_mutex::scoped_lock lock(s_mutex); std::cout << "in `int main()`: lock on `s_mutex` acquired" << std::endl; boost::thread(&thread_fun1, boost::ref(lock)); s_lockMoveBarrier.wait(); std::cout << "in `int main()`: after the barrier" << std::endl; } After compiling and running this on Debian Squeeze with Boost 1.42.0, I get: in `int main()`: lock on `s_mutex` acquired in `void thread_fun1(...)`: moving lock...done in `int main()`: after the barrier a.out: /usr/local/include/boost/thread/pthread/recursive_mutex.hpp:62: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. Aborted After replacing "boost::recursive_mutex" with "boost::mutex", however, the output is: in `int main()`: lock on `s_mutex` acquired in `void thread_fun1(...)`: moving lock...done in `void thread_fun1(...)`: after the barrier in `int main()`: after the barrier This leads me to wondering: 1. Is it correct and/or safe to move a lock to a new thread in this way? 2. Why does the `recursive_mutex` version fail and the `mutex` version succeed? Daniel Trebbien

3 3

Re: [boost] [Boost][gsoc]Intrest - big integer library
by Kamil Witecki 16 Feb '10

16 Feb '10

>Given the number of times which a big integer library has been >started, I'd be wary of suggesting it as a GSoC project. I did not thought it would be so hard to be done. >Since there are already many C big integer libraries (with various >licenses), I'd be far more interested in an expression template system >that would let me hook in the operations I need. That way if I'm ok >with LGPL I can just use GMP, for instance. Also, a naive >implementation could be provided for testing and verification. It sounds very good. And does not involve reinventing the wheel from scratch as would do a new implementation of big integers. You would recommend creating expression templates that will allow to bind operators (functions or functionals) and types(for example big integers from third party library) together using type traits and passing functional as template parameter, have I got your idea right? >I remember hearing that someone had started something like that, but I >don't know its progress. I will take a deeper look if anybody has done it already. >~ Scott -- Kamil Witecki.

2 1

[filesystem] Mac OS default codecvt facet
by Beman Dawes 15 Feb '10

15 Feb '10

On Mac OS, Boost.Filesystem currently uses std::locale() as the default, since Apple doesn't see fit to support std::locale(""). There has been a request (ticket #3928) to change the codecvt facet to UTF-8 for the Boost.Filesystem default on Mac OS. This would at least potentially be a breaking change, so I wanted to ask other's opinions before making it. Questions: * Is UTF-8 OK with Mac OS users as the Boost.Filesystem default? * Would Linux users also prefer UTF-8 as the Boost.Filesystem default? Thanks, --Beman

2 6

Downcast taking account of virtual inheritance
by vicente.botet 15 Feb '10

15 Feb '10

Hi, I have a generic class that needs to downcast from a base class to a template class. The template class can use virtual inheritance or not. When the derived class use virtual inheritance I need to use dynamic cast, but not on the other cases. I'm wondering if a new downcast function that will take in account these facts would be of interest in Boost. clase B {...}; class D : public B {...}; class DV : public virtual B {...}; B* ptr; ptr= new D(); D* dPtr = downcast<D*>(ptr); // uses static_cast as is_virtual_base_of<B,D>::type is false ptr= new DV(); DV* dPtr = downcast<DV*>(ptr); // uses dynamic_cast as is_virtual_base_of<B,DV>::type is true What would be a good name for this downcast function? Best, _____________________ Vicente Juan Botet Escribá

6 11

[config] macors with variable arguments support
by vicente.botet 15 Feb '10

15 Feb '10

Hi, is threa macro to know if the compiler supports macros with variable arguments? Best, _____________________ Vicente Juan Botet Escribá

1 0

incomplete_smart_cast: a smart_cast to incomplete types
by vicente.botet 15 Feb '10

15 Feb '10

I have another user case: template <class Final, typename Base=base_transaction_object> class deep_transaction_object : public Base { Final* final() { return static_cast<Final*>(this); } const Final* final() const { return static_cast<Final const*>(this); } public: static Final* make_cache(Final const* rhs, transaction& ) { return new Final(*rhs); } virtual base_transaction_object* make_cache(transaction& t) const { return new Final(*final()); } virtual void delete_cache() { delete this; } virtual void copy_cache(base_transaction_object const & rhs) { *final() = *smart_cast<Final const*>(&rhs); // (1) } }; deep_transaction_object is a mixin class that is be used as follows class F : public deep_transaction_object<F> {...}; At the moment we use smart_cast in deep_transaction_object (1), F is not completly defined. smart_cast is a template class that needs its class parameters to be completly defined, as is_virtual_base_of needs this. In this context I can not check if Final is_virtual_base_of base_transaction_object. As F is a deep_transaction_object<F> which is a Base, the check could be limited to see if Base is_virtual_base_of base_transaction_object. Thus I need a kind of incomplete_smart_cast which in addition has an intermidiate class used for the tests *final() = *incomplete_smart_cast<Final const *, Base const*>(&rhs); incomplete_smart_cast<Target,Intermediate, Source> works like smart_cast except that instead of testing with Target, it test with Intermediate to select the cast to apply to target incomplete_smart_cast<F*, I*>(ptr) = static_cast<F*,smart_cast<I*>(ptr)> For the case of single inheritance this seems to too much to add, but with multiple inheritance the situation we can not build it from static_cast and smart_cast, we need to check if one of the intermediate classes is_virtual_base_of the base class. For example if the mixin allows to inherit from two classes template <class Final, class Base1, class Base1> class deep_transaction_object2 : public Base1, public Base2 { ... virtual void copy_cache(base_transaction_object const & rhs) { *final() = *incomplete_smart_cast2<Final const*, Base1 const*, Base2 const*>(&rhs); // (1) } }; Please let me know if my rationale is correct and if my use case is enough common to interest the Boost community. Best _____________________ Vicente Juan Botet Escribá

1 0

boost::any_ref and boost::any_const_ref
by Daniel Larimer 14 Feb '10

14 Feb '10

I am attempting to create a library with a generic interface run-time interface and have need for something like boost::any; however, boost::any requires heap allocation. boost::variant is not acceptable either because I do not know the full set of types in advance. Has anyone seen the equivalent of a type-checked void* or const void*? Effectively I would like to create a polymorphic method like this: void myclass::method( const_any_ref p1, const_any_ref p2, const any_ref p3 ) { const uint16_t& _p1 = p1; const double& _p2 = p2; const std::string& _p3 = p3; //If any of the types do not match it should throw an exception. alternatively the follow syntax may work if you want to avoid exceptions? boost::optional<const uint16_t&> _p1 = p1; if( !_p1 ) // cast failed? } Anyone have any nifty ideas on how to accomplish this without RTTI and no heap allocation? In place of RTTI I do have a "manual" RTTI system that I could use. get_typename<T>::str will return a unique const char* pointer. I am guessing the best I can hope for is a pair of pointers, one "void*" and one const char*. I am going to write such a class unless someone here knows of an existing solution. Dan

1 1