- Boost - lists.boost.org

[range] breaking changes
by Thorsten Ottosen 08 Apr '05

08 Apr '05

Dear all, Have anybody any last objections to breaking changes to boost.range: boost::range_iterator<T>::type becomes boost::range::iterator<T>::type and so forth. All code that relies on ADL inside the range library by overloading the functions begin() etc will need to be renamed range_begin() etc. br -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 13

[boost::pool_allocator] possible bug with vector of vectors
by Greg Rosenblatt 07 Apr '05

07 Apr '05

While debugging some recent changes to a program I'm working on, I discovered that pool_allocators seem to break when a vector using the allocator is contained within another vector. The problem disappears when the standard allocator is used instead. I'm including a small test program that illustrates the problem. The program causes a segmentation fault on my computer with GCC 3.3 and a friend's computer with GCC 3.4. Am I using the pool library incorrectly, or is there a real issue here? I really like the concepts behind this library, and I'd like to continue using it. This is also my first time posting to this mailing group, so if I've made any mistakes in this post, please let me know so I can correct them. Thanks in advance, Greg Source: Note that switching the definition of EventVector will fix the problem. Also note that the definition of IndexVector doesn't seem to matter. #include <boost/pool/pool_alloc.hpp> #include <vector> #include <iostream> template <typename DataType> struct PooledVector { typedef std::vector<DataType ,boost::pool_allocator<DataType> > Type; }; typedef PooledVector<int>::Type EventVector; //typedef std::vector<int> EventVector; //typedef PooledVector<EventVector>::Type IndexVector; typedef std::vector<EventVector> IndexVector; int main() { try { std::cout << sizeof(EventVector) << " " << sizeof(IndexVector) << "\n"; IndexVector iv; iv.push_back(EventVector()); iv.back().push_back(3); std::cout << "it works\n"; } catch (...) { std::cout << "exception\n"; } return 0; }

1 0

shared_ptr on ppc?
by Peter Dimov 07 Apr '05

07 Apr '05

Any volunteers with CodeWarrior and g++ access on a PowerPC? ;-) -- Peter Dimov http://www.pdimov.com

6 42

[ptr_container] post review comments
by Pavel Chikulaev 07 Apr '05

07 Apr '05

Thorsten, I've got some comments on ptr_container library: 1. Since we can iterate over elements in container using pair of begin end or pair of ptr_begin ptr_end it's not enough to provide member-functions which take only iterators as arguments, we also need overloads which take ptr_iterators. Motivation example: ptr_vector<int> v; //... ptr_vector<int>::iterator i = std::find(v.begin(), v.end(), 5); if (i != v.end()) v.erase(i); //works just fine, but int k = 5; int * pk = &k; ptr_vector<int>::ptr_iterator i = std::find(v.ptr_begin(), v.ptr_end(), pk); if (i != v.ptr_end()) //here we can just write simple erase, we need to write something like that: v.erase(v.begin() + std::distance(v.ptr_begin(), i)); //and it's really no good. I'd like to list all the functions that need to have a twin, but I'd better say shorter - at least every public function that have one or more parameters with type iterator. Differently, ptr_iterators seem to be sick, petty and harmed. We just can't use them anywhere. Another, more simple approach is to provide function that returns iterator of the corresponding ptr_iterator. The funny thing is that we already can get ptr_iterator from iterator, but it's not so needed as the backward transformation. But I do think this is not a good solution, because with this approach we can achive the required functionality, but the syntax will be very very bad. One more approach is to simply get rid of ptr_iterators, but provide user with adapters he will ever need. I like it, but sometimes (or more oftener) I (and you) still simply need ptr_iterators. IMO the best solution is the hardest solution - approach number 1. 2. The next drill is on templated functions and constructors. If we will decide to keep ptr_iterators, consider the following code: ptr_vector<int> v; ptr_vector<int> v2(v.ptr_begin(), v.ptr_end()); IMO user (that was I) expects this compiling. But it's not. Why can't I construct ptr_vector from ptr_iterators? It's good iterators, just any else, but I can, because they need special care to handle them. IMO it's nonsense not to enable such support. The same applies to templated insert, assign, and other functions. So, all of them need an overload for templated ptr_iterators. I think the library should either supply the user of ptr_iterators all he will every need or get rid of them completely. No some more remarks, but they are not so important as the above. 4. IMO header <boost/ptr_container/clone_allocator.hpp> deserves to be higher in folder hierarchy since its' contents can be widely used by other libraries/people. 5. IMO header <boost/ptr_container/exception.hpp> contents doesn't follow good naming scheme. What do other people think when they see boost::bad_index & ? Some class, maybe exception, since it has prefix bad, but how knows that this class comes with ptr_container library? No-one. BTW why don't you use std::out_of_range? At least please change its' name. The same for boost::bad_pointer in the same header file. 6. What a funny name!! boost::ptr_container_ptr_container_detail in <boost/ptr_container/nullable.hpp> Maybe this header also deserves more fame(I mean nullable<T>)? 7. Why don't you throw std::out_of_range exception like std containers when ptr_sequence_adapter::at is out of bounds? Instead, you throw unknown boost::bad_index. 8. It's seems you didn't put contents of detail headers in detail namespace so we have boost::map_config class in <boost/ptr_container/ptr_map_adapter.hpp>. Why don't you put all adapters and their config classes to ptr_container::detail namespace? I don't think anyone will use them. 9. <boost/ptr_container/ptr_predicate.hpp> contents derserve to be documented. And it's better to make ptr versions to all <functional> functions and introduced these classes: template<typename T, typename U, typename R> class boost::ptr_binary_function : std::binary_funtion<T *, U *, R> {}; template<typename T, typename R> class boost::ptr_unary_function : std::unary_funtion<T *, R> {}; It will simplify your code and IMO it will be useful for users who wants to make their own ptr functions/predicates. 10. indirected1, indirected2 are not good names, don't you think? 11. std::set doesn't have set::at, why does boost::ptr_set have one(even two)? Sorry to dig so deep. P.S. BTW, have you fixed that const_ptr_iterator bug yet? -- Pavel Chikulaev

1 1

[ptr_container] post review comments
by Pavel Chikulaev 07 Apr '05

07 Apr '05

Thorsten, I've got some comments on ptr_container library: 1. Since we can iterate over elements in container using pair of begin end or pair of ptr_begin ptr_end it's not enough to provide member-functions which take only iterators as arguments, we also need overloads which take ptr_iterators. Motivation example: ptr_vector<int> v; //... ptr_vector<int>::iterator i = std::find(v.begin(), v.end(), 5); if (i != v.end()) v.erase(i); //works just fine, but int k = 5; int * pk = &k; ptr_vector<int>::ptr_iterator i = std::find(v.ptr_begin(), v.ptr_end(), pk); if (i != v.ptr_end()) //here we can just write simple erase, we need to write something like that: v.erase(v.begin() + std::distance(v.ptr_begin(), i)); //and it's really no good. I'd like to list all the functions that need to have a twin, but I'd better say shorter - at least every public function that have one or more parameters with type iterator. Differently, ptr_iterators seem to be sick, petty and harmed. We just can't use them anywhere. Another, more simple approach is to provide function that returns iterator of the corresponding ptr_iterator. The funny thing is that we already can get ptr_iterator from iterator, but it's not so needed as the backward transformation. But I do think this is not a good solution, because with this approach we can achive the required functionality, but the syntax will be very very bad. One more approach is to simply get rid of ptr_iterators, but provide user with adapters he will ever need. I like it, but sometimes (or more oftener) I (and you) still simply need ptr_iterators. IMO the best solution is the hardest solution - approach number 1. 2. The next drill is on templated functions and constructors. If we will decide to keep ptr_iterators, consider the following code: ptr_vector<int> v; ptr_vector<int> v2(v.ptr_begin(), v.ptr_end()); IMO user (that was I) expects this compiling. But it's not. Why can't I construct ptr_vector from ptr_iterators? It's good iterators, just any else, but I can, because they need special care to handle them. IMO it's nonsense not to enable such support. The same applies to templated insert, assign, and other functions. So, all of them need an overload for templated ptr_iterators. I think the library should either supply the user of ptr_iterators all he will every need or get rid of them completely. No some more remarks, but they are not so important as the above. 4. IMO header <boost/ptr_container/clone_allocator.hpp> deserves to be higher in folder hierarchy since its' contents can be widely used by other libraries/people. 5. IMO header <boost/ptr_container/exception.hpp> contents doesn't follow good naming scheme. What do other people think when they see boost::bad_index & ? Some class, maybe exception, since it has prefix bad, but how knows that this class comes with ptr_container library? No-one. BTW why don't you use std::out_of_range? At least please change its' name. The same for boost::bad_pointer in the same header file. 6. What a funny name!! boost::ptr_container_ptr_container_detail in <boost/ptr_container/nullable.hpp> Maybe this header also deserves more fame(I mean nullable<T>)? 7. Why don't you throw std::out_of_range exception like std containers when ptr_sequence_adapter::at is out of bounds? Instead, you throw unknown boost::bad_index. 8. It's seems you didn't put contents of detail headers in detail namespace so we have boost::map_config class in <boost/ptr_container/ptr_map_adapter.hpp>. Why don't you put all adapters and their config classes to ptr_container::detail namespace? I don't think anyone will use them. 9. <boost/ptr_container/ptr_predicate.hpp> contents derserve to be documented. And it's better to make ptr versions to all <functional> functions and introduced these classes: template<typename T, typename U, typename R> class boost::ptr_binary_function : std::binary_funtion<T *, U *, R> {}; template<typename T, typename R> class boost::ptr_unary_function : std::unary_funtion<T *, R> {}; It will simplify your code and IMO it will be useful for users who wants to make their own ptr functions/predicates. 10. indirected1, indirected2 are not good names, don't you think? 11. std::set doesn't have set::at, why does boost::ptr_set have one(even two)? Sorry to dig so deep. P.S. BTW, have you fixed that const_ptr_iterator bug yet? -- Pavel Chikulaev

1 0

is there a config macro which for has_enable_if?
by Thorsten Ottosen 07 Apr '05

07 Apr '05

Hi, Does anybody know of a config macro which comes close to saying "enable_if won't work" Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 4

[boost] [shared_ptr] m68k and ia64 implementations by Ben Hutchings, RFC
by Peter Dimov 07 Apr '05

07 Apr '05

Ben Hutchings has kindly contributed the attached sp_counted_base implementations for g++ on IA64 and 68020+. The IA64 version of decrement should be changed to: Ben Hutchings wrote: >>> It isn't a memory barrier (unless you add .acq or .rel to it) but I >>> don't believe a barrier is needed for the simple increment and >>> decrement operations. It is always atomic, like lock xadd. >> >> For increment, no. For decrement, yes. It needs to be a release when >> the new value is nonzero, > > Oh yes, of course it does. > >> and an acquire when the new value is zero. > > Hmm, tricky. There would be need to be another instruction afterward > that creates the acquire barrier. Maybe this would do: > > __asm__ (" fetchaddl.rel %0=[%4],-1 \n" > " cmp.eq %2,%3=1,%0 \n" > "(%2) ldl.acq %0=[%4] " : > "=r"(rv), "=m"(*pw), "=c", "=c" : > "r"(pw) : > ); > > Don't ask me whether that's the most efficient way to do this! In your (Boost developers) opinion, 1. Do we need a platform-specific version for 68020+ at all? (It is my understanding that threads aren't very popular there ;-) but I may be wrong) 2. Should we try to get an IA64 version in 1.33 or should this be postponed for 1.34?

3 3

Lock-free shared_ptr on g++/x86, test/review needed
by Peter Dimov 07 Apr '05

07 Apr '05

I just added boost/detail/sp_counted_base_gcc_x86.hpp to the CVS. It is not enabled yet, i.e. sp_counted_base.hpp will not include it automatically. If you are interested, please take a look at the file and give it a test run. The easiest way to enable it is to do #include <boost/detail/sp_counted_base_gcc_x86.hpp> #define BOOST_DETAIL_SP_COUNTED_BASE_HPP_INCLUDED (or to copy it over sp_counted_base.hpp) before including shared_ptr.hpp. Any comments appreciated. As usual, thanks to Alexander Terekhov for all the help and patience. -- Peter Dimov http://www.pdimov.com

3 28

BOOST_STATIC_ASSERT and g++ 3.4
by Angus Leeming 07 Apr '05

07 Apr '05

The code below works as expected when compiled with g++ 3.4 as: $ g++ -I$HOME/boost/cvs -g -W -Wall -o static_test2 static_test2.cpp but it also produces this warning: static_test2.cpp: In static member function `static foo foo::set()': static_test2.cpp:15: warning: no return statement in function returning non-void Clearly, I could add a spurious return statement after the assert, but isn't g++ being a little over eager here? Can the warning not be silenced by the library? Regards, Angus #include <boost/static_assert.hpp> #include <iostream> class foo { public: enum state { state1, state2, state3 }; // Only the specializations (below) of this template will compile. template <int N> static foo set() { BOOST_STATIC_ASSERT( N == state2 ); } private: foo(state) { std::cout << "foo" << std::endl; } }; template <> foo foo::set<foo::state2>() { return foo::state2; } template <> foo foo::set<foo::state3>() { return foo::state3; } int main() { // Compiles, as expected. foo f1 = foo::set<foo::state2>(); foo f2(foo::set<foo::state2>()); // Fail to compile, as expected. // foo f3 = foo::set<foo::state1>(); // foo f4(foo::set<foo::state1>()); return 0; }

2 5

[Test] IsDebuggerPresent() failures on CodeWarrior 9.4 for Windows
by Doug Gregor 07 Apr '05

07 Apr '05

Many Boost tests are failing in the Test library on CW 9.4 due to the lack of IsDebuggerPresent(). Gennadiy? Doug

5 9