- Boost - lists.boost.org

Regression in Multi-index, 1.35?
by Amit 03 Apr '08

03 Apr '08

Hi, I am trying to migrate my project to 1.35. The following used to compile and work with 1.34.1: bmx::multi_index_container<wstring, bmx::indexed_by<bmx::ordered_unique<bmx::identity<wstring> >, bmx::random_access<> >, boost::fast_pool_allocator<wstring> > But refuses to compile with 1.35 (I use Intel compiler 10.1 with MSVC7.1 STL). Something to do with allocator rebind. I am including some of the compiler output below. Can someone please suggest a resolution (hopefully keeping the pool allocator intact)? Thanks Amit C:\DevLibraries\Boost\include\boost-1_35_0\boost/pool/pool_alloc.hpp(130): error: reference to void is not allowed typedef value_type & reference; ^ detected during: instantiation of class "boost::fast_pool_allocator<T, UserAllocator, Mutex, NextSize> [with T=void, UserAllocator=boost::default_user_allocator_new_delete, Mutex=boost::details::pool::default_mutex, NextSize=32U]" at line 149 of "C:\Boost\include\boost-1_35_0\boost/detail/allocator_utilities.hpp" instantiation of class "boost::detail::allocator::rebinder<Allocator>::result<Type> [with Allocator=boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, Type=boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>]" at line 158 of "C:\Boost\include\boost-1_35_0\boost/detail/allocator_utilities.hpp" instantiation of class "boost::detail::allocator::compliant_allocator_rebind_to<Allocator, Type> [with Allocator=boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, Type=boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>]" at line 62 of "C:\Boost\include\boost-1_35_0\boost/mpl/eval_if.hpp" instantiation of class "boost::mpl::eval_if_c<C, F1, F2> [with C=false, F1=boost::detail::allocator::partial_std_allocator_rebind_to< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>>,

4 4

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 03 Apr '08

03 Apr '08

... > > That requirement to have > > > > Derived1::Derived1(implementation*) > > > > is unreasonable as it is clearly not related to to the Derived1 *public* > > interface. On the other hand reset()-based approach works fine and scales > > fine. > > > > ... > > I understand now. This will force to add an artifial *protected* constructor > to > Derived1. Do you really think that this is a real problem for the developer > of Derived1? > If I understand your library forbids this to the developper because > pimpl_base do not have the following protected constructor. > pimpl_base (implementation* impl) : impl_(impl) {} > > I think that this will be a good adding to the pimpl_base class. Respectfully I have to disagree. The reason is that it has been long established precedent in C++ not to provide alternative mechanisms/tools/interfaces if the existing already does that. An immediate example OTOH is that an introduction of "superclass" keyword was rejected because a typedef would do the same thing. Granted, tediously and not as elegantly but still. Here IMHO it's the same story -- we are not talking about missing functionality but rather questionale interface sugar-coating which BTW requires the user to do more than he really have to ("force to add an artifial *protected* constructor"). ... > > I am not sure what that is supposed to demonstrate. You use infrastructure > > to help you to do your job. If you decide that the infrastructuere does > > not help you and discard that, you'll obviously have to re-implement > > whatever functionality from that infrastructure you managed to deploy. If > > one uses std::list and then for whatever reason goes ahead with his own > > list implementation or merely swaps it for std::vector, he'll likely to > > face the same issue. Trade-offs of the pimpl idiom are well-known -- > > another indirection and memory allocation. In the end, one can deal with > > memory-allocation by writing a custom allocator for > > pimpl<Foo>::implementation. > > If pimpl is here to hide the implementation, why it needs to extends the > interface of the initial class? > Why the user of my class should suffer from the trade-offs of the pimpl > idiom at the inteface level? Pimpl extend the interface so that the user does not have to provide those methods. Like comparison and validity check, etc. That does not come at the user's expence and, therefore, how exactly the user suffers from that escapes me. > >> Do you really think that the pimpl idiom is helping me to hide my > >> implementation. If I want to hide my implementation I need to restrict > > to > >> private inheritance. > > > > I cannot say about you but I do really think that the pimpl idiom is > > helping me to hide the implementation. Private inheritance restricts > > access but not hides the implementation. > > I was talking about private inheritance from pimpl!!! If you try deploying pimpl in applications, you'll quickly see that you'll need public inheritance. I do. Having said that, if you insist on inheriting privately, there is nothing stopping you. We are not discussing missing pimpl functionality or crooked implementation, right? > > struct Base { int k; }; > > class Derived : Base {} > > > > Here Base::k is not accessible in Derived but not hidden. More, if that > > stuff is a commercial library, I can easily circumvent that restriction by > > modifying Derived declaration. Pimpl really hides the implementation. See > > for more about the idiom > > > > 1. Guru of the Week #24. http://www.gotw.ca/gotw/024.htm > > 2. Herb Sutter. Exceptional C++ (Addison-Wesley, 1999) > > 3. J. Carolan. Constructing bullet-proof classes. In Proceedings C++ at > > Work'89 (SIGS Publications, 1989) > > 4. James O. Coplien. Advanced C++ Programming Styles and Idioms > > (Addison-Wesley, 1992) > > 5. Eric Gamma et al. Design Patterns (Addison-Wesley,1995) > > This is why I suggested to remove the null object and bool type conversion > operators for pimpl<A>::value_semantics. Maybe it will be a good idea to > give them protected acces. I admit that "This is why" escpes me. Invalid objects are all over -- nullptr, shared_ptr(), -1, etc. Pimpl extends that concept onto actual classes and gives it uniform and proper implementation. I've been using this extensively and I do indeed need that... public. If one does not need that, he won't use that. That feature won't kick in by accident. > >> Once we remove the public inheritance from pimpl, it is not eassy to > >> implement all these extra functions and operators. > > > > Then do not remove public inheritance. I am far from being convinced that > > insistence on private inheritance is justified. > > Conveinced or not this is a way to mask the pimpl functions, and it seams to > me the best way to use pimpl<A>::value_semantics. This is not the case with > pimpl<A>::pointer_semantics from which it is better to inherit publically > giving acces to the null object and the bool type conversion operators. > This is only a comment on how I will use it :-) Yes, that makes sense. Although if my usage experience is of any guidance, you'll swap private for public fairly soon. I guess, we'll see. ... > >> >> Could we inherit publicly from A and privatly from pimpl<B, > >> >> A>::value_semantics? > >> > > >> > Cannot comment on this one as I am not convinced we need that (see > > above). > >> Imagine A3ppClass is a 3pp class ( we can not modify it), and before > > using > >> the > >> your pimpl class we had: > >> > >> class MyClass : public A3ppClass {}; > >> > >> How can we use pimpl without changing the interface of MyClass, neither > >> adding nor removing any function? > >> > >> May be we can resume: do not use the pimpl library is you can not master > > the > >> complete inheritance hierarchy. ... > In any case I don't see a real benefit of using pimpl when the base class is > 3pp class and we can not change it. Well, if you build a run-time polymorphic hierarchy on top of an existing 3rd-party base class, then I tend to agree with you as you have to follow the design and strategy outlined by the base class designer. I do not feel like it is a pimpl inherent weakness. Havind said that, I'd shy away from coming to your generic conclusion based on that particular case. Unless I have to write deep run-time polymorphic hierarchies (like Widgets, etc.), I tend to cut inheritance short and I believe it is the strong current programming trend in C++. Therefore, in your case I'd try pimpl<MyClass>::implementation : public A3ppClass {} then in MyClass I'd bridged to A3ppClass only the interface that MyClass needed: MyClass::foo() { (*this)->A3ppClass::foo(); } It might not be applicable in your particular case -- no one claims to have the silver bullet. ... > >> class A : private pimpl<A>::value_semantics {...}; > >> class B : private pimpl<B>::value_semantics {...}; > >> class C : public A, public B {...}; > >> > >> May be we can resume: do not use the pimpl library if you need multiple > >> inheritance. > > > > I cannot see anything drastically wrong with the code above even though I > > probably would not do it that way. So, I'll have to disagree with your > > conclusion. > > Anyway, we will do the same, don't use pimpl with multiple inheritance. I would not say that I will not. If/when the time comes for me to deploy multiple inheritance, I cannot see myself hesitating because of the pimpl. ... > > I have to disagee as I find that view over-simplified and in fact > > incorrect. Pimpl or no pimpl in general no objects beyond value-semantics > > PODs can be safely (or without additional effort) put into shared memory. > > I hope so, and I expect that you will do what is needed to achiev this. I > tried only to help you. And it is much appreciated. > Pointers are emulated in Boost.Interprocess with the smart pointer > offet_prt. > You can yet have inheritance without virtual functions. Well, I would not insist on that without severe reservations, numerous ifs and buts. > Please, could you take a look to the Boost.Interprocess, Boost.Intrusive and > Boost.MultiIndex libraries. > Even if not standards they are portable. :-) Yep, had a quick look at boost.interprocess. Seems like it takes care of shared memory hasssle. Cool. I presume he managed it for UNIXes and Windows. Super cool. And I see boost.multiindex supporting boost.interprocess allocators. Now I get it. Still I do not feel like rushing to support the feature. :-) We'll get the bridge when we get there. I'll keep it iin mingd though. Thanks for your patience and insistence. You see, I not THAT thick after all. :-) > > Then, you'll have to provide custom allocators. The issue just > > keeps more and more complicated. Do you actually have that setting or we > > are talking hypothetically? If the former, then pimpl will not be your > > primary concern. :-) If it is the latter, then I find it too ephemeral to > > discuss effectively. > > I insist. This is not hypothesis. I have to manage a lot of data shared > between process, I use specific allocators, and synchronization mechanisms. > I wanted only to know if I can hide the implementation of this classes with > the pilm classes. That's all. OK, I see you need that. :-) It'll take me sometime to get up to speed with boost.interprocess. Worse, for various reasons I cannot use un-official boost. So, go and figure. > > If you do not have several processes accessing the same data and, > > therefore, do not care for inter-process data-access synchronization, > > inter-process vtbl pointer correction, etc., then I'd be wondering why you > > use shared memory in the first place. > > Who has said that I have no several process sharing the same data? No, you certainly did not say you did not have several processes. Have you noticed there was 'if' at the beginning of my sentence? :-) > But the data has no virtual functions. This is not a raison to don't want to > hide its implementation. Fair enough. You convinced me. Honestly, Unfortunately, or reasons beyond my influence I won't be able to extend pimpl support onto boost.interprocess in a short timeframe. Apologies. .. > Thank you very much for your time and good luck for your review. > I promise I'll try your library. Thanks for your input. Much appreciated. Thanks, Vladimir.

2 1

Removing copyright symbols from files.....
by Marshall Clow 03 Apr '08

03 Apr '08

Unless anyone objects, I am going to remove the copyright symbol "©" from source and header files (in response to support request #597). I will not touch anything that's not in a comment. ;-) It looks like about 37 header files, and 24 source files. I'll do this tonight, unless anyone objects. Example transformation: In file "boost/archive/detail/auto_link_archive.hpp", on line #12: // © Copyright Robert Ramey 2004 will become: // (c) Copyright Robert Ramey 2004 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 5

[1.35] VC8 compiler bug makes boost spill types into global namespace, which breaks IntelTBB
by Marcus Lindblom 03 Apr '08

03 Apr '08

Hi all, This is with VC8 SP1. We tried to compile our app with boost 1.35.0 and got errors in Intel TBB that int32_t was already defined. After some debugging, we have boiled it down to the following repro case, which shouldn't compile. It compiles on VC8 but not on VC9. Just run cl on the following: ========================= namespace bzt { typedef long fiddle; } namespace foo { using namespace bzt; // removing using makes it work too class baz { public: virtual void meep() // removeingvirtual makes it fail { } }; namespace foobar { void geronimo() { throw baz(); } } // namespace foobar } // namespace foo fiddle dummy; // should not compile, but does ========================= For boost, the actual names used are namespace bzt = boost fiddle = int32_t foo = boost_132 baz = bad_weak_ptr meep = bad_weak_ptr::what foobar = detail geronimo = bad_weak_ref throw baz() = boost::throw_exception(bad_weak_ptr) and can be reproduced using boost code with simply: ========================= #include <boost/cstdint.hpp> #include <boost/detail/workaround.hpp> #include <boost/serialization/detail/shared_count_132.hpp> int32_t dummy; // Should not compile, but does. ========================= The function throwing is boost_132::detail::sp_counted_base::add_ref_lock() which does boost::throw: void add_ref_lock() { if(use_count_ == 0) boost::throw_exception(bad_weak_ptr()); ++use_count_; } Where bad_weak_ptr have a virtual function. I suppose a fix/workaround would be to not use the boost_132 namespace which imports boost. This is a pretty bad bug, so we're thinking of switching to VC9 to avoid this. Cheers, /Marcus P.S. Great work on getting Boost 1.35 out! We really appreciate all the effort spent and will try harder to find time to test the RCs at root these things out earlier. Hope this helps somewhat in improving boost though.

1 0

gsoc prposal
by Inosh Goonewardena 03 Apr '08

03 Apr '08

Hi, I have send a proposal to gsoc regarding the JSON Archives for Boost.serialization. I have attached my propsoal with this e mail

3 2

Re: [boost] GSoC Ideas: Optimizing Boost libraries for multi-core machines
by Cristianno Martins 02 Apr '08

02 Apr '08

Hi, >In my experience, there are very few instances where parallelism can be >usefully concealed behind a library interface. OpenMP has very high >overhead and will help only for very long-running functions -- at least >under Microsoft's compiler on x86 and x64 platforms. Right, but this is something that depends of the algorithm. For example, let's take the regular expression library implementation in Boost (Xpressive). Pattern matching is an expensive task and it's a kind of thing that comes in a library set like Boost. Researchers have tried parallelize regular expression matching ( http://ieeexplore.ieee.org/iel5/10901/34300/01636074.pdf) So, I guess there would be researches that are based on parallel libraries construction. >Algorithms that >are likely to be applied to very large datasets could have the OMP >pragmas inserted optionally but they would need to be protected by >#ifdef logic (or given distinct names) because otherwise the overhead >will destroy programs that make more frequent calls on smaller datasets. Ok, but the feasibility study of the parallel version of an algorithm should be a part of the parallelization task. Not all of the parallelizable tasks would be really interesting running in parallel. >Also consider that, in an application that is >already parallelized, there are no extra cores for the library to use >internally. Well, but what if the library is already parallelized? Maybe the extra task generated by parallelize the real application would be dispensable. >On a smaller scale, adding "vectorized" and/or "streaming >producer-consumer" interfaces for selected libraries may help a lot by >encouraging use of vector instruction / execution units, unrolling of >loops and improving instruction and data locality. This is a pretty good idea. Best, -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype: cristiannomartins gTalk: cristiannomartins msn: cristiannomartins(a)hotmail.com

1 0

Re: [boost] GSoC Ideas: Optimizing Boost libraries for multi-core
by Cristianno Martins 02 Apr '08

02 Apr '08

Hello again, first of all, thank you for comments. That is certainly an interesting project. When you submit your GSoC > application, please identify exactly which library you plan to > parallelize with OpenMP, and which parts of that library you will > parallelize. > > - Doug Well, I enumerated three libraries that I could parallelize with OpenMP in the project. Therefore, I did't specify how I'd parallelize them, because (in the project) one of the tasks to be done after choose a library is to identify the bottlenecks. So, I thought I should do this at that moment. Furthermore, if I have opportunity to parallelize more than three libraries, it'll be necessary to do this step for the others libraries; so, why mustn't I do it for all of them? > Just a quick question. Wouldn't be TBB the better choice instead of > > OpenMP? > > > I can see good reasons for both options. TBB will make it easier to > implement task-oriented parallel algorithms, but it brings with it a > dependency on a non-Boost library. OpenMP is reasonably good at data > parallelism (and can require fewer changes to algorithms where it > applies), and depends on features available in many compilers, but it > isn't as widely applicable as TBB. I think you choice will be dictated > mainly by the library you choose, and how you think you will need to > parallelize that library. > > - Doug > The use of TBB is a really good idea, so I could parallelize each chosen library in Boost with the best library to that case (between OpenMP and TBB). What do you think about it? Best, -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype: cristiannomartins gTalk: cristiannomartins msn: cristiannomartins(a)hotmail.com (rarely used)

1 0

[range] Proposal to add make_view
by Andrey Semashev 02 Apr '08

02 Apr '08

Hi, I propose to add a simple helper function to create an iterator range of boost::transform_iterators. This would effectively create a view over a different range or a container. Currently this is possible to do with considerable code duplication: make_iterator_range( make_transform_iterator(vec.begin(), fun), make_transform_iterator(vec.end(), fun)); Here "fun" could be a rather complex lambda or bind expression. What I propose is to wrap these calls into a simple generator make_view. The above code would look much better: make_view(vec.begin(), vec.end(), fun); or make_view(vec, fun); I've attached a sample implementation of the make_view function. Do you think this could be useful? #ifndef BOOST_RANGE_VIEW_HPP_INCLUDED_ #define BOOST_RANGE_VIEW_HPP_INCLUDED_ #include <boost/iterator/transform_iterator.hpp> #include <boost/range/iterator_range.hpp> #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/iterator.hpp> namespace boost { template< typename IteratorT, typename FunT > inline iterator_range< transform_iterator< FunT, IteratorT > > make_view(IteratorT const& begin, IteratorT const& end, FunT const& fun) { return make_iterator_range( make_transform_iterator(begin, fun), make_transform_iterator(end, fun)); } template< typename RangeT, typename FunT > inline iterator_range< transform_iterator< FunT, typename range_iterator< const RangeT >::type > > make_view(RangeT const& range, FunT const& fun) { return make_view(begin(range), end(range), fun); } } // namespace boost #endif // BOOST_RANGE_VIEW_HPP_INCLUDED_

4 5

#pragma warning (dsiable : 4996) ineffective?
by Roland Schwarz 02 Apr '08

02 Apr '08

I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings. However this seems not to work (at least on my machine). There seems to be some unintended interdependence with _SCL_SECURE_NO_DEPRECATE. I was not able to find out what exactly is causing the warnings not go away. Hoever, compiling with _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE quiets the build. Couldn't this issue be handled by the boost config headers? Is this something wrong with my setup only, or do others experience the same problem? Thank you, to anyone who cares. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

6 7

[1.35] Documentation of Boost.Range incomplete
by Boris 02 Apr '08

02 Apr '08

The webpage http://www.boost.org/doc/libs/1_35_0/libs/range/doc/range.html is empty (or missing?). I got there by clicking on a range concept at http://www.boost.org/doc/libs/1_35_0/libs/range/index.html. Boris

2 2