- Boost - lists.boost.org

[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

[Boost-bugs] [ boost-Bugs-1178259 ] Muss of "host" and "target"
by SourceForge.net 07 Apr '05

07 Apr '05

Bugs item #1178259, was opened at 2005-04-06 21:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Muss of "host" and "target" Initial Comment: When I try build boost for crossplatform compiler (i386-mingw32msvc-gcc) on linux host. When I set tool to mingw, jam try build ".so" libraries (I use hack for set $OBJCOPY to i386-mingw32msvc-objcopy). When I set WINNT variable, jam try use windows directory delimiter. And in any case it fails build ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] large file support detection broken on Solaris (possibly others)
by Caleb Epstein 06 Apr '05

06 Apr '05

The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy) The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on. Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably. -- Caleb Epstein caleb dot epstein at gmail dot com

2 6

[Boost-bugs] [ boost-Bugs-1178092 ] std::locale construction slows down convert_to_lower()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178092, was opened at 2005-04-07 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: std::locale construction slows down convert_to_lower() Initial Comment: Replacing std::locale loc(""); with static const std::locale loc(""); improves speed a lot in VC7.1 and VC8.0 beta ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1178068 ] Past-the-end tokenization in parse_date()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178068, was opened at 2005-04-06 23:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: Past-the-end tokenization in parse_date() Initial Comment: Loop termination condition is wrong. Comma is used instead of and operator: for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end(), pos < spec_str.size(); ++beg, ++pos) Should read as for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end() && pos < spec_str.size(); ++beg, ++pos) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0