- Boost - lists.boost.org

CVS problems
by Jonathan Turkanis 08 Apr '05

08 Apr '05

Hi, I'm getting "No space left on device" errors, apparently referring to the remote server, while trying to checkout boost via anonymous CVS. Who should I report this to? Jonathan

4 4

[Ann] Proposed Math library additions (complex number inverse trig functions).
by John Maddock 08 Apr '05

08 Apr '05

As part of the project to produce a Boost TR1 implementation I've implemented the additional algorithms in <complex> that are part of the TR: fabs asin asinh acos acosh atan atanh It occurs to me that maybe these should really be spun out as a separate library rather than "slipped in" as part of another submission (comments welcome on that). In the mean time these algorithms can be downloaded as part of the TR1 library here: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… All the inverse trig functions are defined for the full complex plain, and do the right thing even for exceptional input (no overflow or underflow during the computation if the result is actually representable). They also do the right thing for infinities and nan's, as specified by C99. The asin/asinh/acos/acosh algorithms have a theoretical max error bound of 9.5e (experimental bounds are much lower, about 4e), there is no theoretical work on atan/atanh that I know of, but experimentally the error bound seems lower than for asin/acos. This is some of the most heavily commented code I've written, so refer to the header for more information on the literature sources used etc. During the implementation I found that I needed a few other things that might make useful Boost components (part implemented, part wish list as noted below): log1p: ~~~~ This algorithm is part of C99, but by no means all compilers support it yet, I used a Taylor series expansion for small x: I'm aware that there are much more efficient methods, but optimizing compilers completely trash the logic of these (Intel C++ proved to be particularly bad). Series Summation (Kahan Method): ~~~~~~~~~~~~~~~~~~~~~~~~ I wrote a small routine to apply the Kahan summation method to a nullary-functor that generates successive terms in a series. Summation stops when the next term is below a particular threshold. I've found the Kahan method to be significantly more accurate for certain series, but again some highly optimizing compilers can cause small errors to creep in (I believe that the issue is double-rounding of intermediate terms on machines with extended-double registers). Probably my current interface to this one needs some more thought before it could be anything other than a detail, and if we're talking about wish lists, infinite product, and continued fraction evaluation would be useful additions too.... Floating point testing: ~~~~~~~~~~~~~~ Currently just a version of C99's isnan, and only works for quiet nan's with IEEE-conforming compilers. More of a wish list really, I could really use all the C99 fp-testing macros (as C++ functions obviously). Numeric constants: ~~~~~~~~~~~~~ Currently I've embedded the numeric constants used inside the implementation, a numeric constants library really would have simplified things... just a pity we could never agree on an interface last time this came up. Whew, I think that's all, thanks for reading this far! Regards, John.

2 6

[Wave] Library updated, test suite in place
by Hartmut Kaiser 08 Apr '05

08 Apr '05

Hi all, after Wave was accepted into Boost I've fixed all of the things mentioned during the review and reported afterwards by different people (thanks a lot for all the comments and help I've got!). Here are the main points: - I've fixed all the problems reported during the review and tried to incorporate all of the remarks done there as well. - The first version of a test suite was implemented and is integrated into the Boost regression process. This test suite currently consists out of more than 100 different unit tests from 2 categories: . Systematic testing of all aspects of the preprocessor as described in the Standard . Set of regression tests collected during the development of Wave over th elast couple of years. The test system is very flexible and is easy to extend. In the future I'll add even more unit tests to check even more details. Since it was asked here before: the test suite currently takes a couple of seconds to execute. The integration of Wave into the regression test procedure revealed some portability issues which I'm currently trying to resolve. - A new sample lexed_tokens was added. It shows how to use one of the C++ lexers included with the library only (without using the C++ preprocessing component). For the details see the Changlog file here: http://tinyurl.com/4fu8m. Overall, I think Boost.Wave is ready for prime time now and can be included into the next Boost release. Regards Hartmut

1 0

[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