- Boost-users - lists.boost.org

[type traits][enable_if] how do I resolve ambiguous class template instantiation?
by Steve Lorimer 28 Jul '10

28 Jul '10

I'm trying to use template specialization and enable_if / type_traits to correctly allocate memory for different types, where the template parameter will be one of: 1. boost::intrusive_ptr // create U on the heap, return intrusive_ptr 2. boost::shared_ptr // create U on the heap, return shared_ptr 3. U* // create U on the heap, return raw pointer 4. U // create U on the stack I'm pretty sure I'm just doing something stupid, but I'm getting ambiguous conflicts between my template for types of U and the smart pointer types. Please can you comment on how to fix the code below? TIA Steve #include <boost/utility.hpp> #include <boost/type_traits.hpp> #include <boost/intrusive_ptr.hpp> #include <boost/shared_ptr.hpp> #include <iostream> template<typename U, class Enable = void> struct alloc; template<typename U> struct alloc<U, typename boost::disable_if< boost::is_pointer >::type > { U operator()() { std::cout << __LINE__ << std::endl; return U(); } }; //----------------------------------------------------- template<typename U> struct alloc<U, typename boost::enable_if< boost::is_pointer >::type > { U operator()() { std::cout << __LINE__ << std::endl; return new U; } }; //----------------------------------------------------- template< typename U > struct alloc< boost::intrusive_ptr > { boost::intrusive_ptr operator()() { std::cout << __LINE__ << std::endl; return boost::intrusive_ptr(new U); } }; //----------------------------------------------------- template<typename U > struct alloc< boost::shared_ptr > { boost::shared_ptr operator()() { std::cout << __LINE__ << std::endl; return boost::shared_ptr(new U); } }; //----------------------------------------------------- template<typename T> struct test { alloc<T> create; T fun() { return create(); } }; struct foo { uint32_t refs; foo() : refs() { std::cout << "foo" << std::endl; } }; inline void intrusive_ptr_add_ref(foo* p) { ++p->refs; } inline void intrusive_ptr_release(foo* p) { if (!--p->refs) delete p; } int main() { test<int*> a; int* p = a.fun(); *p = 5; test<int> b; int d = b.fun(); d = 5; test< boost::intrusive_ptr<foo> > c; boost::intrusive_ptr<foo> z = c.fun(); z.get(); test< boost::shared_ptr<int> > gd; boost::shared_ptr<int> x = gd.fun(); x.get(); return 0; }

2 1

does Boost Parameter support non-type class template parameters?
by Nathan Ridge 28 Jul '10

28 Jul '10

Hello, Does the Boost Parameter library's named template parameters feature work for templates where some of the parameters are non-type parameters? Thanks, Nate. _________________________________________________________________ MSN Dating: Find someone special. Start now. http://go.microsoft.com/?linkid=9734384

1 0

how to release element from ptr_map?
by archie14 28 Jul '10

28 Jul '10

I have an instance of ptr_map<int, classA>. I need to release an element from the map and use it somewhere else, making sure that it will not be deleted when the instance of ptr_map is deleted. I am successfully doing it with ptr_vectors, but can't get it right with ptr_map. What is the proper syntax of such call? I am doing it like in the code below, which does not compile. class classA {}; typedef ptr_map<int, classA> ptrmaptype; ptrmaptype val; val.insert(1, new classA()); ptrmaptype::mapped_type t = val.release (val.begin()); // I want "t" to be of classA* type

2 2

[Random] Getting normal_distribution<> to work
by Hossein Haeri 28 Jul '10

28 Jul '10

Dear all, When I run the following simple code, the output is "-1.#IND" in MSVC 2008 and "nan" in GCC 4.4.0. I guess that means something is not initialised yet... So, what's missing here? boost::normal_distribution<double> gen; boost::mt19937 engine; double r = gen(engine); cout << r; TIA, --Hossein

2 1

boost_python: static vs shared library sizes on Windows
by David Aldrich 28 Jul '10

28 Jul '10

Hi I asked for help a week or so back regarding storing boost_python as a vendor library in our project's svn repository. The aim being to relieve our Windows developers of the effort of installing and building boost. This also ensures that everyone is using the same version. I have built shared libraries for boost_python and everything works nicely now except that it is necessary to include the path to the boost libraries in the system's PATH variable. I would rather not have to modify PATH, so I considered using static libraries instead. However, I was surprised to find that the static libraries are very much bigger than the shared libraries. So I would rather use shared libraries. Is there a way of telling the .exe file the path to the necessary dll's at build time? Is this a purpose of a manifest file? Best regards David

1 0

Is there rotate-shifts in Boost?
by Murilo Adriano Vasconcelos 28 Jul '10

28 Jul '10

Hi, I am a GSoC student and I am implementing a library to handle integral values. I want to know if exists functions to do integer rotate shifts in Boost. If it not exists I am suggesting these functions: http://svn.boost.org/svn/boost/sandbox/SOC/2010/bits_and_ints/boost/integer… To do right and left rotation shifts. And want to know if is better to check if the length of rotation is less than the size in bits of the type. Best, -- Murilo Adriano Vasconcelos http://murilo.wordpress.com

1 0

[Iterator][enable_if] Why use additional type for the enabler?
by Robert Jones 28 Jul '10

28 Jul '10

The iterator facade documention suggests that controlled conversion of iterators between const and mutable variants can be achieved by application of enable_if. Why does this need to involve an additional 'enabler' type, rather than exploiting the default void type of the enable_if template? Thx, - Rob.

1 0

[Serialization] #include order
by dariomt＠gmail.com 28 Jul '10

28 Jul '10

Hi all, Compiling the following program with Boost 1.42 fires an static assertion in boost/serialization/shared_ptr.hpp:153. This is expected. But if I change the order of includes (compile with -DCHANGE) the assertion fires in boost/serialization/shared_ptr.hpp:121. The assertion is expected but I found it strange that I end up compiling a different part of the same file... The code in that section seems related to serialization of shared_ptr in version 1_32, but since I'm not able to understand the difference, I'm just reporting it in case the order of #includes might affect how shared_ptr's get serialized. Regards ---code--- #include <boost/shared_ptr.hpp> #ifndef CHANGE #include <boost/serialization/shared_ptr.hpp> #endif #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #ifdef CHANGE #include <boost/serialization/shared_ptr.hpp> #endif void test() { boost::shared_ptr<int> p (new int); *p = 12345; boost::archive::xml_iarchive ia(std::cin); boost::serialization::load(ia, p, 0); }

1 0

[boost.filesystem v3] recursive_directory_iterator throws unexpectedly
by Tan, Tom (Shanghai) 28 Jul '10

28 Jul '10

In boost::filesystem v3, while it's possible to choose a no-throw version of recursive_directory_iterator by passing an boost::system::error_code object to its constructor, like this: boost::system::error_code m_ec; for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr) However, because in the implementation of the recursive_directory_iterator::increment(), directory_iterator is always constructed with the throw version, it would cause exception throws during the for-loop while accessing folders like \System Volume Information on Windows: void increment() { BOOST_ASSERT(m_imp.get() && "increment of end recursive_directory_iterator"); m_imp->increment(0); if (m_imp->m_stack.empty()) m_imp.reset(); // done, so make end iterator } Where m_imp is an object of recur_dir_itr_imp: void recur_dir_itr_imp::increment(system::error_code* ec) // ec == 0 means throw on error { ... } As it's not possible to catch this exception within the for-loop and continue the loop, it greatly limits the use of recursive_directory_iterator. With rough check, V2 does not seem to have this problem. Is this a bug or change on purpose? I personally would expect the directory_iterator to behave the same as recursive_directory_iterator in this case. Regards, Tom

1 0

program_options, multiple [sections] from a config file
by rrlangly 28 Jul '10

28 Jul '10

I'm using boost program_options 1.41 and would like to know if anyone has a better idea than what I'm trying to do. I am reading from a config file some basic parameters per section, but I have multiple sections. The problem is there could be any number of [sections] in this file, so I don't know what it is ahead of time. [server] name="a" ip="1.2.3.4" [server_2] name="b" ip="4.5.6.7" [server_3] name="c" ip="8.9.0.1" Thanks, -- View this message in context: http://old.nabble.com/program_options%2C-multiple--sections--from-a-config-… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1