- Boost - lists.boost.org

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::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::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::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::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

type_with_alignment.hpp VC8 error
by Ralf W. Grosse-Kunstleve 02 Apr '08

02 Apr '08

Hi, svn revision 43952 broke my VC8 build: C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('8') ) won't be aligned The compilation command is attached. Ralf cl /nologo /D_SECURE_SCL=0 /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EH sc /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_ALL_NO_LIB -DBOOST_PYTHON_MAX_ BASES=2 /IC:\AUTOBU~1\sources /IC:\AUTOBU~1\sources\boost /IC:\AUTOBU~1\build\ base\python\include /c C:\AUTOBU~1\sources\boost_adaptbx\optional_ext.cpp /Fob oost_adaptbx\optional_ext.obj

5 5

BoostCon'08 Early Registration Deadline
by David Abrahams 02 Apr '08

02 Apr '08

Reminder: early registration for BoostCon'08 closes Monday, April 7. It's still not too late to avoid the late registration fee for what may be the finest C++ event of 2008. For the 2nd annual Boost C++ libraries conference, we've put together a fantastic program crowned by a keynote address from Bjarne Stroustrup. In addition to existing Boost libraries, we're covering technology of interest to any C++ developer trying to stay on the cutting edge, including hands-on sessions with features from the upcoming 2nd version of the C++ standard. This year we've also added a collection of short "author's corner" sessions for those of you who want an inside perspective on how advanced libraries are developed. See http://www.boostcon.com/program for details. BoostCon 2008 will be hosted at Aspen Center for Physics, one of the most beautiful meeting sites in the world, and a great venue for collaboration and discovery. The combination of a relaxed pace and intense inquiry made BoostCon'07 an event to remember, and we expect no less for this year. Please visit http://www.boostcon.com/registration to register. Thanks! -- The BoostCon Planning Committee David Abrahams Joel de Guzman Jeremy Siek Beman Dawes Eric Niebler Matthias Troyer Jeff Garland Sean Parent

1 0

issue #1694
by David Grüner 02 Apr '08

02 Apr '08

Hi, I'm not sure why this track is set to Milestone 1.36 / No Version. This bug is there since at least 1.35 RC1 and not fixed in 1.35 Release. AFAIR i set the version or milestone to something like 1.35*. If that's impossible :) and nobody changed it, i'm really sorry. However, this needs to be addressed soon (IMHO), and it's easy to fix anyway. #define NDEBUG #define BOOST_ENABLE_ASSERT_HANDLER #include <boost/range.hpp> void reproduce() { boost::iterator_range<char const*>("early").end(); }

1 0

[bind] VC8 warning
by Ralf W. Grosse-Kunstleve 01 Apr '08

01 Apr '08

Hi, Coincidentally, I just noticed this VC8 warning when compiling the Boost.Python tests (using the current boost svn trunk): C:\home\rwgk\hot\boost\boost/bind.hpp(1639) : warning C4180: qualifier applied to function type has no meaning; ignored The full warning + cl command line is attached. What's the best way to resolve this warning? Ralf

2 1

[gsoc 2008] A C++ Remote Method Invocation Framework using Boost.Asio
by salinda h 01 Apr '08

01 Apr '08

Hi All, For the google summer of code 2008, I wish to build a Cross Platform Remote Method Invocation Framework for C++ using Boost.Asio, similar to Java's remote method invocation (RMI). I will provide some macro definitions to create the proxy code. Please provide me your comments to adjust this idea to best suit the interests of boost community. I higly appreciate your suggestions. A sample code that will use this framework wold look like, account.h -------------- DECLARE_BEGIN_PROXY(account) DECLARE_METHOD_1(deposit, void, double); DECLARE_METHOD_0(get_balance, double); DECLARE_END; class account { .......... ......... } Server Code ----------------- account acc = new account("Foo", 250); Server s = new server(server::TCP, 19000); s.attach("Foo", acc); s.run(); Client Code ---------------- account_proxy acct = account_proxy::get_proxy("172.25.44.195", server::TCP, 19000, "Foo"); acct.deposit(100); double balance = acct.get_balance(); Thank You, Salinda

7 6

Two 1.35 Issues
by Jared McIntyre 01 Apr '08

01 Apr '08

Has something changed in the way you build libraries? I'm building using the following command: bjam --build-dir=builddir --toolset=msvc-8.0 stage This no longer builds any of the libboost* versions, nor any debug builds when run against 1.35. bjam version is 03.1.16. I'm not having any issues with gcc builds. Secondly, is there a link on the website to the 1.35 Getting Started docs? I ended up finding it through the searc on the site. It might be nice if that was linked to from the documentation section. Maybe even listed at the top. Thanks, Jared

10 12

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

01 Apr '08

...skipped the beginning which appears to be duplication of the previous email > Could you clarify if the base implementation pointer can or can not be > initialized with a pointer to the implementation of the derived class? There > is something wrong in > > 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" > Base::Base(int k) : base(null()) > { > reset(new BaseImpl(k)); > } > > Derived1::Derived1(int k, int l) : Base(null<Base>()) > { > reset(new Derived1Impl(k, l)); > } > > Could a class inherit privately from pimpl? > > class A : private pimpl<A>::value_semantics {...} Well, I guess it can... although I am yet to see a compelling case to actually do that. It'll deny all the functionality that is in pimpl_base to the derived class(es). > There is something that seams extrange to me. If the pimpl is there to mask > the implementation, doesn't adds the public inheritance of > pimpl<A>::value_semantics some implemtation constraints? I cannot think of any particular implementation constraints > Note that public inheritance adds to the class interface the null() > function, bool type conversion and ! operator, and adds also all the > protected functions to the derevied classes. I am not sure I understand. Is it a bad thing? > Can we found always a null object for every class when pimpl is not used? null<T>() has boost::enable_if_c<is_pimpl<T>::value, T>::type so my implementation only kicks in for pimpls. > Can a class that inherits from a non pimpl class has its own private impl? > > class A; > > class B : A, public pimpl::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. > 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::implementation : public A { } That certainly makes sense (to me anyway). > 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). > Can we manage with multiple inheritance? > class A : public pimpl<A>::value_semantics {...}; > class B : public pimpl::value_semantics {...}; > class C : public A, public B {...}; Sure... with all the relevant multiple-inheritance perks/drawbacks. > 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. > 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). > 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. :-) > I hope that you will find good solutions to these problems. So, do you find my answers to your satisfaction? > In any case, I > will apreciate that you include in the library documentation the limitations > of the approach, if there are any. Thanks, Vladimir.

2 1