April 2008 - Boost - lists.preview.boost.org

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<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. > 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). > 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<B>::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

Bug in 1.35: header inclusion order dependency introduced between recursive_mutex.hpp and asio.hpp on Windows
by James Talbut 01 Apr '08

01 Apr '08

recursive_mutex.hpp include windows.h, which includes winsock.h. asio.hpp barfs if winsock.h has been included. Clearly it's not boost's fault that windows.h and winsock2.h have inclusion order problems, but this change will break code that currently uses them both. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

7 8

[smart_ptr] shared_from_this in constructor potential pitfalls
by Frank Mori Hess 01 Apr '08

01 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It has occurred to me, constructors which throw exceptions might cause difficulties with the new support for calling shared_from_this() from constructors. If a constructor uses shared_from_this(), then throws an exception, it may result in dangling shared_ptrs (or the BOOST_ASSERT in the enable_shared_from_this destructor getting triggered). The problem can be avoided by not calling shared_from_this until you are sure your constructor won't throw. However, suppose you have a hierarchy such as "U derived from T derived from enable_shared_from_this<T>". Then if the constructor of U throws, it could be difficult to clean up any shared_ptr objects created by shared_from_this calls in the T constructor. Another tactic would be to restrict oneself to storing weak_ptrs when using shared_from_this() in constructors, and not locking any of them until the object is fully constructed. An exception thrown later in a constructor would cause the weak_ptrs to expire. This kind of tactic might be enforced by dropping support for shared_from_this in constructors. Instead, we would have a method in enable_shared_from_this which, instead of returning a shared_ptr like shared_from_this(), returns some object (call its class "shared_from_that" for the moment) with a method (say, shared_from_that::get()) that will return a shared_ptr to the original object when one is available. If the object is not owned by a shared_ptr yet, then shared_from_that::get could return an empty shared_ptr. If the object has destructed without ever being owned by a shared_ptr, or its owning shared_ptrs have expired, then shared_from_that::get() could throw bad_weak_ptr. Then client code would be able to distinguish between the two possible failures of either the shared_ptr not being available yet, or being expired, and act accordingly. An slightly different formulation might be a "weak_from_that" class, with a get() method that returns a weak_ptr and throws if the original object doesn't have an owning shared_ptr yet. I'm still on the fence as to whether shared_from_that would be an improvement or not. It seems more honest and safer than shared_from_this in constructors, but less convenient and a more complicated interface. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH8oHq5vihyNWuA4URAuDiAJ4j2MAP8JvdOWf1neQifNzQXJxLvwCffUsf /atoUpoioLgDMtbvS2bKeRI= =MkM6 -----END PGP SIGNATURE-----

1 0

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

01 Apr '08

Hi, Thaks for your replies. > Interesting. Have you checked that there isn't something available already on > asio...not sure, but I think someone might have already done something like > this. That said, AFAIK it's not in Boost so this would be a nice extension. Thanks to Paolo Coletta's reply, I found the CodeProject article by Jarl Lindrud "RCF - Interprocess communication for C++". It is similar to what I suggested. Since it is not in a Boost library form Paulo suggests possible integration between this library and boost.interface. > Have a look at Boost.Interface http://www.cdiggins.com/bil.html > This library was never fully proposed for Boost, but it has alot of the same > ideas/needs as you do w.r.t. binding with C++ interfaces. Thanks for making my attention on this. After looking at the article, I understood that the Boost.Interface library will releive me from the burden of writing a custom Macro library. However I couldn't find a link on that page to get the source code of that library. Please tell me where can I get the source code. > Also, a totally different way to go would be to support an IDL like language > and write a tool to generate the needed C++. Yes. Internet Communication Engine (http://www.zeroc.com/ice.html) (Where I got the inspiration for this project.) uses an IDL. Since this is a C++ only project I thought I can avoid the additional step of code generation by using Macros. ( I likek the macro bindings in boost.python. It is so simple & smart than SWIG.) > What do you have in mind for the transport protocol? Both TCP and UDP. (Option is given to the user.) Thanks! Salinda

2 2