- Boost - lists.boost.org

[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

Re: [boost] CORBA iimplementation for Boost interest?
by Stefano Delli Ponti 02 Apr '08

02 Apr '08

(Duplicated post, the previous one was not complete - sorry) Hello Jon, Jonathan Biggar wrote: > I've been working on a C++ CORBA implementation for a long time. I've > considered making it open source in the past, but I hadn't seen the > exact niche for it to fill. > > Now that Boost 1.35 is out, including ASIO and the new Threads > implementation, I'm considering retargeting my implementation to only > use boost libraries for underlying services. > > I'd be quite happy to contribute my implementation to boost, if there's > enough interest for me to proceed. > > So, what do you all think? > That's wonderful! (I am so happy also because I know, being a long-time CORBA user, the expertise of Jonathan and his contributions to the standard). Some considerations: - I think that many on this list underestimate the importance that CORBA has still today. For large client-server/distributed applications there aren't yet many valid alternatives. - The main benefit of CORBA is its cross-platform, cross-language nature: our C++ distributed application is accessible through C++, Java, Python, COM, .Net in Solaris, Windows, Mac OS X and Linux. - There are very good open-source implementations, like TAO and OmniORB, with great support facilities. - The main drawback of CORBA is probably its awkward C++ binding (as Jon said, there were many /historic/ reasons). I know that an effort for a new binding began some months ago at OMG: I am not updated on that one. TAO is a robust implementation based on ACE. ACE is a large C++ framework, which implements many network-related pattens. Boost is now entering the ACE's territory with a much more modern C++ perspective but it still lacks many features (waiting for pion-net/cpp-netib, log et al.). But, as Jon said, Boost has now the functionalities needed to build an ORB. I see many benefits about a Boost ORB: - A modern C++ implementation - A place to experiment with new bindings and other things - A large piece of code that reuse and test a lot of other Boost libraries I would use such a beast immediately on the client-side. So, let's do it. I would be glad to contribute. Regards, Stefano

2 1

[thread] Missing initializer warnings from gcc in 1.35.0
by Colin Caughie 02 Apr '08

02 Apr '08

I just tried moving to 1.35.0 (from 1.34.0) and am getting the following warnings: /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/pthread/ timespec.hpp: In function 'timespec boost::detail::get_timespec(const boost::system_time&)':/usr/local/boost/1.35.0/x86/include/boost-1_35/boost/ thread/pthread/timespec.hpp:18: warning: missing initializer for member 'timespec::tv_nsec' /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/xtime.hpp: In function 'boost::xtime boost::get_xtime(const boost::system_time&)': /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/xtime.hpp:59: warning: missing initializer for member 'boost::xtime::nsec' We compile with -Wall and -Werror, and would like to continue doing so. Anyone know of a way of suppressing this warning? We're using gcc 4.1 and 4.2.1. Thanks, Colin

3 2

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

02 Apr '08

> >> Base::Base(int k) : base(new BaseImpl(k)){} > >> Derived1::Derived1(int k, int l) : Base(new Derived1Impl(k, l)) > > > > No, this initialization method is not allowed. One needs to use reset() > > instead as you show below. I considered the syntax above and rejected it > > on the grounds that it does not add new functionality (as reset() already > > does that) and it is not generic enough as it won't work for "Derived2 : > > public Derived1" > > Why this syntax could not work? Could you elaborate more? For that syntax to work with a hierarchy every class needs to explicitly declare a constructor taking "implementation*". That is, in the following hierarchy Base : pimpl<Base> {} Derived1 : public Base {} Derived2 : public Derived {} pimpl, Base and Derived1 need to have those mentioned constructors so that the following could work Derived2::Derived2(int) : Derived1(new Derived2Implementation()) { } 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 cannot think of any particular implementation constraints > > Imagine that after using the your pimpl class which will do an extra > allocation, and due to performance I need to come back to a traditional > class. If my class inherits publicaly from pimpl I will need to provide the > same interface as when using the pimpl class. > > Before > class A : public pimpl<A>::value_semantic ... > > After > class A { > public: > // needs to implement publicaly the null function, bool_type operator, > // and the ! operator. > protected: > // needs to implement all the protected part inherithed from > pimpl<A>::value_semantic > > } 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. > 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. 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) ... > 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. ... > >> class A; > >> > >> class B : A, public pimpl<B>::value_semantics {...} > >> > >> How the B implementation has access to A? > > > > I am not sure it is a good (from pimpl perspective) design. Pimpl is about > > separation of interface and implementation and implementation hiding. By > > inheriting from A we just threw all that out the window. So, doing that > > for B implementation does not seem to have much value. Having said that, > > if one indeed needs access to A inside B implementation, then keeping B* > > inside B implementation seems to solve the problem. With regard to > > handling polymorphic hierachies the Bridge description from GoF would be a > > good start. That'll be fully applicable to the proposed pimpl. > > Keeping a A* inside B implementation will complicate a bit the B > implementation, isn't it? It depends. Even if it does, it'll be truly just a bit. > >> maybe we need something like that > >> > >> class B : public pimpl<B, A>::value_semantics {...} > >> > >> making the implementation of B inherit from A. > > > > "making the implementation of B inherit from A" is > > > > struct pimpl<B>::implementation : public A > > { > > } > > > > That certainly makes sense (to me anyway). > > How do you ensure this way that B inherits from A? It feels like you want two separate hierarchies -- for interface and implementation. The application of the Pimpl idiom to polymorphic class hierarchies is well described in the "Bridge" section of GoF. > >> 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. I am not sure how relevant it is to the technical side of things. We are not in a legal profession where for legal reasons they write "may contain traces of nuts" on a packet of nuts. I see infrastructure as providing a service. Decision about applicability of that service for a particular situation is application developer's responsibility. I dot thin the time of the infrastructure developer will be well spent trying to think of every situation where his code *cannot* be used. > >> Can we manage with multiple inheritance? > >> class A : public pimpl<A>::value_semantics {...}; > >> class B : public pimpl<B>::value_semantics {...}; > >> class C : public A, public B {...}; > > > > Sure... with all the relevant multiple-inheritance perks/drawbacks. > > Imagine that I have up to now > class A; > class B; > class C : public A, public B {}; > > and that I have no problems with multiple-inheritance because I have no > common class on the inheritance hierarchy (even if I don't like it very > much). > Now I'd like to use your pimpl classes and now a found a common class, or > atleast some common functions or operators. Does it means that again I need > to > use private inheritance. Yes, I understand what you describe and 'no' I do not think it'll be an issue. And, no, again, in my view private inheritance does not help you one bit. (Just admit you like "her", don't you. :-) ) > > 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. > >> How pimpl interacts with STL containers? > >> > >> stl::list<A> al; > >> B b; > >> al.push_back(b); > >> // ...somewhere else > >> A a =al.pop_back(); > >> > >> How 'a' should behaves? like a A or like a B? > > > > I presume > > > > struct A : pimpl<A>::... {} > > struct B : public A {} > > > > Then the result depends if A is of value_semantics or pointer_semantics. > > With pointer_semantics it behaves as, say, boost::shared_ptr would behave. > > Otherwise, during copying B part will be chopped off. So, "A a" will > > behave as A. > > OK, I have missed that. Does it means that only pimpl<A>::value_semantic > is sustitable for a class which was already used with STL containers? No, it does not. I am overwhelmingly using pimpl::pointer_semantics and those are happily in various containers. And those objects behave polymorphically because they have pointer semantics. If it is not the desired behavior, then value_semantics should be used instead. It is up to the class designer to decide. > >> The STL container user that > >> shouldn't knowns nothing about A implementation, expect that it will > > behaves > >> as a A, but it think that 'a' will behaves like a B. How can we protect > > from > >> this situation? > > > > I probably do not understand something as I still do not see what it is to > > protect from. A pimpl-based class behaves as any ordinary class (as it is > > in fact an ordinary class). > > > > May be we can resume: do not use the pimpl pointer semantics if your class > has value semantics. Well, I probably can agree with this conclusion... although I am temped to argue that in that case we'll have to put similar "warnings" everywhere. Like "do not use knife when you actually need a spoon", etc. > > In order to understand better your purpose: > * Could you give an example in which the object has value semantics and the > implementation pointer semantics? > * Could you give an example in which the object has pointer semantics and > the implementation value semantics? Private implementation does not have any particula semantics. It is the interface (pimpl-derived) class who has pointer_ or value_semantics... meaning how it treats the implementation -- aloows to share it or copies it. > > >> Could we store a non polymorph pimpl object in shared memory? > >> Could we store non polymorph pimpl objects in a container in shared > > memory? > > > > I am not convinced these special cases require anything from the pimpl. > > Although these certainly need more effort from the developer. Issues and > > means to deal with those seem to be the same as if one tried to store a > > pointer or std::auto_ptr or a boost::shared_ptr in shared memory. Given > > it's all in the developer's hands (implementation can be allocated > > explicitly and then associated via reset()) it'll be the developer's pain. > > This seems to be merely part of overall painful experience of dealing with > > shared memory. :-) > > You are right, auto_ptr and shared_ptr do not work on shared_memory. The > difference is that as you state a pimpl is not a pointer, and so we should > not suffer from the pointer liabilities. When a user use std::auto_ptr or > boost::shared_ptr he knows that there are some pointers not too far. In the > case of the pimpl the user has nothing to be with the pimpl classes and its > pointers. 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. > Imagine that you are using a class A in shared memory and even a container > of A in shared memory and you want now to use your pimpl class to hide the > implementation of A. What I can do? Shared memory is a delicate area. It's like embedded programming where not all language resources are readily available. If your A class can live in shared memory, then it is essentially a POD. Say, consisting of a few integers, no pointers, no inheritance. Otherwise, two processes cannot access/manipulate that same object in shared memory (not easily anyway). Still, those processes must have access synchronization issues resolved. More so, you mention a container in shared memory. Is it a standard container? 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. 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. > Do not forget that you have two pointer member? > > template<class Interface> > template<class Implementation> > class pimpl<Interface>::impl_ptr > { > ... > traits const* traits_; > Implementation* p_; > }; > > May be you need to add some policies to your class in order to manage with > this (see for example void_pointer in Boost.Intrusive)? > > May be we can resume: pimpl library can not be used for classes that can be > stored in shared memory (atleast in his current state). Well, again I am not sure we should rush with conclusions based purely on hypothetical assumptions without trying. I admit I did not try using pimpl with shared memory as I do not use shared memory these days. It's almost not portable, limiting, hard to handle, and most (all?) of the time is better implemented as a multi-threaded app anyway. > > >> I hope that you will find good solutions to these problems. > > > > So, do you find my answers to your satisfaction? > > > > Not completly, but I hope that this discusion will serv to construct a > better > pimpl library or atleast to show the limits where this library is not really > adequated. Well, I certainly biased :-) but I am trying to keep an open mind and so far I do not see anything that I'd consider as a limitation. Call me a stubborn nut if you like. ... > The question is, can we subtitute a class A by a class A : public > pimpl<A>::xxx_semantics? I think that it will be better to restrict the null > object and the bool type operator to the pointer semantics. > > What do you think? I consider value- or pointer-semantics to be the behavior when null() is clearly a functionality. They are very much orthogonal to each other. Foo::null() clearly declares an invalid (unusable) object regardles of its semantics. I see value in it. If one does not need that functionality, he probably won't use it. As simple as that. I did not hear compellling arguments *not" to provide that functionality for value-semantics classes. Thanks, Vladimir.

2 1