- Boost - lists.boost.org

[gsoc2008] Interest in Smart Objects
by Mathias Gaunard 24 Mar '08

24 Mar '08

I would like to propose some project for the Google SoC 2008, but before I would like to determine interest. Smart Objects are like Smart Pointers (the name comes from there, even though it's not definite), except they don't act like pointers but rather like objects. One crucial difference is that Smart Objects do not acquire a pointer to some already pre-allocated area of memory, but rather they are responsible for allocating the object themselves ; which fits well with the value semantics of objects anyway, since it must deep copy. I first thought of naming that Polymorphic Value Objects, but nothing forces such objects to provide some kind of polymorphism. I actually consider a Smart Object to be any container that contains a single value object, while "masking" it to add other extra features: dynamic typing, delayed initialization, etc. Boost.Any, Boost.Variant, Boost.Function, Boost.Optional, Adobe.Poly, and probably others I cannot think of are Smart Objects. The first part of what I propose is a policy-based self-containing non-typed memory allocator framework that would allow pluggable usage of SBO, and that could provide the never-empty guarantee with one technique or the other if desired. Indeed, some Smart Objects can benefit from non-typed memory allocation, and all of them can benefit from SBO, which brings its own problem when wanting to replace an object by another. The standard allocator model cannot allow such things cleanly. Of course it would be possible to use a standard allocator underlyingly, but it would allocate arrays of chars. The second part is the implementation of a few useful Smart Objects using the framework and thus which allocation is still customizable (the names are of course not definite): - pimpl<T>, same as a regular T except that T can be incomplete. - ipoly<T>, which can contain a T or any object whose type derives from T, but only if T provides some virtual copy and move constructors of its own. This provides support for subclassing subtyping. - maybe poly<T>, same as ipoly<T> but without requiring some virtual copy constructors. I believe this would not integrate well with the C++ type system though. I think there is some code for that in the vault already. - structural<Interface>, with Interface an interface of some sort (probably defined with helper macros). Would allow to contain any object which type conforms to the interface, similarly to Adobe.Poly. This provides support for structural subtyping. - maybe duck<Sequence of types>, which would be able to contain any type within the sequence, and provide duck-typing. This basically is the same as structural subtyping except the interface is verified at runtime. Due to limitations of the C++ language, it can only work with a finite sequence of types ; indeed template virtual member functions would be needed to achieve it otherwise. It can be noted that boost::function<R (T1, .., Tn)> is nothing but a structural<Interface> whose Interface is struct { R operator()(T1, .., Tn); } Boost.Overload could have been the same thing with multiple overloads in the interface, but rather it used a different design (containing multiple objects). Access to members for pimpl, ipoly, poly and structural would be done through -> since . cannot be overloaded. Access to members of duck would be different though, since that cannot work. Something like obj.member(<&>(o) (o.the_member)); if we had polymorphic lambdas, probably. (with optional macros to help) There would also be optional variants of those utilities because the never-empty guarantee does not need to be maintained if we allow the smart object to be empty. All of these would have support for move semantics and in-place construction. Please tell me your thoughs about this, so that I can determine whether it's worth it or not to submit a GSoC candidature next week.

4 5

[Serialization] Private destructors and extended_type_info_typeid
by Paul Roberts 23 Mar '08

23 Mar '08

Hi, I just upgraded from trunk for the first time in a few weeks, and now I'm unable to compile classes that use serialization and have private destructors. It seems boost::serialization::extended_type_info_typeid is now trying to access those destructors, and failing. Do I need to friend extended_type_info_typeid now, as well as boost::serialization::access, or is this a genuine bug? I've provided a minimal repro case below, followed by the compiler output from MSVC 9. Regards, -- Paul Roberts paul at pwroberts dot com http://www.m3fe.com/ #include <boost/serialization/access.hpp> #include <boost/serialization/split_member.hpp> #include <boost/archive/binary_oarchive.hpp> #include <fstream> class A { friend class boost::serialization::access; private: ~A() {} template<typename Archive> void serialize(Archive& ar, const unsigned int version) { } public: static A a; }; A A::a; int main() { std::ofstream ofs("hi"); { boost::archive::binary_oarchive oa(ofs); oa << A::a; } } /* 1>------ Build started: Project: 2k8test, Configuration: Release Win32 ------ 1>Compiling... 1>serialization_fun.cpp 1>C:\dev\boost-trunk\boost/serialization/extended_type_info_typeid.hpp(118) : error C2248: 'A::~A' : cannot access private member declared in class 'A' 1> .\serialization_fun.cpp(18) : compiler has generated 'A::~A' here 1> .\serialization_fun.cpp(7) : see declaration of 'A' 1> C:\dev\boost-trunk\boost/serialization/extended_type_info_typeid.hpp(117) : while compiling class template member function 'void boost::serialization::extended_type_info_typeid<T>::destroy(const void *const ) const' 1> with 1> [ 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(110) : see reference to class template instantiation 'boost::serialization::extended_type_info_typeid<T>' being compiled 1> with 1> [ 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(107) : while compiling class template member function 'boost::archive::detail::oserializer<Archive,T>::oserializer(void)' 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(234) : see reference to class template instantiation 'boost::archive::detail::oserializer<Archive,T>' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(228) : while compiling class template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard::invoke(Archive &,const T &)' 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(292) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(280) : while compiling class template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::invoke(Archive &,const T &)' 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/oserializer.hpp(498) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/common_oarchive.hpp(64) : see reference to function template instantiation 'void boost::archive::save<Archive,const T>(Archive &,const T &)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/array/oarchive.hpp(118) : see reference to function template instantiation 'void boost::archive::detail::common_oarchive<Archive>::save_override<const T>(T &,int)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/basic_binary_oarchive.hpp(64) : see reference to function template instantiation 'void boost::archive::array::oarchive<Archive>::save_override<T>(const T &,unsigned int)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/binary_oarchive_impl.hpp(45) : see reference to function template instantiation 'void boost::archive::basic_binary_oarchive<Archive>::save_override<T>(const T &,int)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1> C:\dev\boost-trunk\boost/archive/detail/interface_oarchive.hpp(63) : see reference to function template instantiation 'void boost::archive::binary_oarchive_impl<Archive,Elem,Tr>::save_override<T>(T &,int)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> Elem=char, 1> Tr=std::char_traits<char>, 1> T=A 1> ] 1> .\serialization_fun.cpp(27) : see reference to function template instantiation 'Archive &boost::archive::detail::interface_oarchive<Archive>::operator <<<A>(T &)' being compiled 1> with 1> [ 1> Archive=boost::archive::binary_oarchive, 1> T=A 1> ] 1>Build log was saved at "file://c:\dev\work\2k8test\Release\BuildLog.htm" 1>2k8test - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== */

2 3

GSOC Project : Number Theory and Tree Libraries for Boost.
by Sykora 23 Mar '08

23 Mar '08

Hello all, I have a few ideas for a contribution to Boost during Google Summer of Code, and I would appreciate any advice/feedback/criticism. My ideas consist of the following parts : 1. Building a Boost Number Theory Library I've noticed that in all the mathematics and algorithms libraries, there is no Boost Library for basic Number Theory. I will try to remedy this by implementing those functions common in a number theory library, and interfacing them with other boost libraries. Proposed features of the Number Theory Library : -- GCD -- LCM -- Extended GCD -- Modular Inverse -- Modular Exponentiation -- Primality Tests : -- Deterministic -- Probabilistic -- Factorization -- Prime Number Generation -- Support for GMP More functionality can be provided, this is just the tip of the iceberg (and the most commonly used) 2. Building a Boost Tree Library : The idea here to is write a Tree Library to complement the already existing Graph library. One of the goals of this library would be to interface with the Graph library where necessary, such as the Minimum Spanning Tree functions, etc. Proposed Features of the Tree Library : -- Binary Search Trees -- Red-Black Trees and/or AVL Trees -- Operations on these trees, including insert/delete, balancing, I/O, etc. Possible follow-up activity : -- Expose the above modules to python using the Boost.Python However, as far as I can see, the Boost.Python library was last updated in 2005, and should be updated to the current Python/C API, possibly to the anticipated API of python's impending landmark 3.0 release. Any comments regarding the community's views on these ideas (such as feasibility, modifications, etc) will be appreciated and mulled over :). Cheers, P.C. Shyamshankar.

2 3

[proto] design rationale for expr<proto::function, argsN<Fun, Args...> >?
by Markus Werle 23 Mar '08

23 Mar '08

Hi! I may have overlooked something, but while thinking about proto's design I was surprised by some asymmetry. I'd like to know why this was done the way it is. Consider two objects (type A and B are proto terminals) A a; B b; The expression a + b is considered equivalent to a function call operator+(a, b). The corresponding type representation approximately is expr<tag::binary_plus // I will vote for this ;-) ,args2<expr<tag::terminal, A> ,expr<tag::terminal, B> > > This is done according to the rationale that what binary_plus really means is domain specific. Therefore the expression is simply tagged by the name of the function call, while the second argument is the typelist containing the parameters in the same order as they appear in the expression. Important: any information about what the function call means is stored *outside* the expression. Up to here I appreciate the design and IMHO this is the most appropriate way to represent an expression (I said that before, I know). Now we introduce another function call - not an operator this time, but in C++ these are equivalent. struct fun_t {}; terminal<fun_t>::type const fun = {{}}; fun(a, b); This is represented by something similar to expr< tag::function ,args3< ref_<expr<tag::terminal, args0<fun_tag> > const> ,expr<tag::terminal, args0<> > ,expr<tag::terminal, args0<> > > > This is suprising. In contrast to operator+, the function fun is treated as if it was an *operand*, not an *operator*. The expression is not tagged by _the_ function call, but by a global this-is-a-function-tag and the function is stored in the argument typelist. What fun means is context dependent, I would expect the context to take care about what fun_t might mean, so if we want symmetry first I'd expect a type representation similar to expr< tag::function<fun_t> ,args2< ,expr<tag::terminal, args0<...ommitted...> > ,expr<tag::terminal, args0<...ommitted...> > > > So I wonder whether this asymmetry was introduced due to the fact that function objects could have a state which makes them an in-between between operator and operand ... Can we save state in tag::function<T> then? expr< tag::function<expr<tag::terminal, args0<fun_t> > > ,args2< ,expr<tag::terminal, args0<...ommitted...> > ,expr<tag::terminal, args0<...ommitted...> > > > I do not like that one either ... I ask because ripping the function off the argument list via fusion magic still looks odd to me and makes me feel uncomfortable: Any compile time algorithm has to fork for function calls if it is to apply an operation to the operands. Shed some light on this, please. Markus

4 3

[Boost] Compile-time power of a run-time base
by Bruno Lalande 23 Mar '08

23 Mar '08

Hello, I have written for the need of a coworker a function template that computes the compile-time power of a base that is known only at runtime. The original need was just to avoid having to write things like "value*value*value*value*value". Before doing this, I've been searching for such a thing in the Boost documentation and mailing lists, but could only find discussions about an entierely compile-time version (compile-time exponent of compile-time base) intended for use in metaprograms. Is there any reason why the "semi-compile-time" version I describe here hasn't been discussed? Even though it can be viewed as a mere syntactic sugar, it can be very practical when it comes to write by hand a power with a big exponent. In case of interest, here is my code : template <int N> struct positive_power { template <typename T> static float result(T base) { return base*positive_power<N-1>::result(base); } }; template <> struct positive_power<0> { template <typename T> static float result(T) { return 1; } }; template <int N, bool> struct power_if_positive { template <typename T> static float result(T base) { return positive_power<N>::result(base); } }; template <int N> struct power_if_positive<N, false> { template <typename T> static float result(T base) { return 1/positive_power<-N>::result(base); } }; template <int N, typename T> float power(T base) { return power_if_positive < N, boost::mpl::greater_equal < boost::mpl::int_<N>, boost::mpl::int_<0> >::type::value >::result(base); } It supports positive, null and negative integer exponents. Some improvements can surely be done, like allowing to specify the desired return type. Examples of use : power<3>(myValue); power<0>(myValue); power<-5>(myValue); Thanks Bruno

8 37

[Feature Request :: Boost][MultiArray] Creating Boost Multi.Array in shared memory
by sankar lingam 23 Mar '08

23 Mar '08

I was working with Boost Multi Array and I find it really useful in my project.. But I would also want to create multi array in shared memory.But currently Boost Multi Array is not compatible with shared memory allocators provided by Boost Interprocess.I raised a question in the boost users list and I got to know that it is an adaptation that Boost Multi Array developers would have to do.. I would love to see an added feature in Boost Multi Array which would be compatible with Boost Interprocess allowing Boost MultiArray to be created in shared memory( just like how Boost MultiIndex in the 1.35 release would be).As I understand the MultiArray adaptation would require using allocator::pointer instead of raw pointers as member pointers. I would want to suggest this request to Boost Multi Array developers as it would be a very useful feature for a Boost user like me..Can this feature be added into the Boost 1.35 release..? Regards, Sankar

1 0

Re: [boost] [shared_ptr] gcc 3.2 build broken with current trunk
by Ralf W. Grosse-Kunstleve 23 Mar '08

23 Mar '08

Hi Frank, Your solution works perfectly on all our platforms, in addition to being nicer than the type holder trick. Thanks for the quick fix! Ralf ----- Original Message ---- From: Frank Mori Hess <fmhess(a)speakeasy.net> To: boost(a)lists.boost.org Sent: Friday, March 21, 2008 5:11:52 PM Subject: Re: [boost] [shared_ptr] gcc 3.2 build broken with current trunk On Friday 21 March 2008 18:53, Ralf W. Grosse-Kunstleve wrote: > Hi Frank, > > Your patch resolves the error I posted before, but there are still > other, similar errors while compiling other Boost.Python sources. I > think this is the problem: > > shared_ptr.hpp: > if(del_wrapper) del = del_wrapper->get_deleter<D>(); > ^^^ > ^^^ > I think gcc 3.2 doesn't support this syntax. In the old days this was a > common problem. The usual workaround is to use a type holder. See the > patch below, which resolves all my compilation errors. I put a different workaround in svn a little while ago (fully qualified the get_deleter call) which allowed get_deleter to compile with gcc 2.95. Is the type holder solution more effective? -- Frank

1 0

Executable files, and SVN.
by Rene Rivera 22 Mar '08

22 Mar '08

As mentioned in the Boost RC thread there was a problem with the archives stemming from the svn::execute property being set in many files that make no sense as executables. To fix it at the source I went through, with initial help from Jens S., and removed the svn:execute property as needed. I made the changes to "branches/release" and to "trunk". It would very neighborly if other went through and fixed their own code in branches as needed. WARNING: This means the next update for Unix users might be rather large as SVN resets permissions on files. Additionally incremental testers will likely see a long cycle. I used a combination of the "find" utility and the "svn" command: find . \ -type f \ -not -regex ".*[/][.]svn[/].*" \ -not -regex ".*\([.]bat\|[.]cmd\|[.]com\|[.]csh\|[.]m4\|[.]pl\|[.]py\|[.]sh\|configure\|rst2latex\)" \ -exec svn propdel "svn:executable" "{}" ";" Then doing a commit with whatever SVN tool you use normally. For Windows users you can still use the above command but you will need to either run something like the Cygwin shell, or MSYS shell. Or you can download a the standalone GnuWin32 port of find <http://gnuwin32.sourceforge.net/packages/findutils.htm> and the standard Windows SVN install. Lastly, please be careful about adding files that may be executable. And make sure the SVN properties are set correctly. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

cpp-netlib & pion-net
by Michael Dickey 22 Mar '08

22 Mar '08

I started writing the Pion Network Library (first called "libpion") almost a year ago to start learning Boost and to help fill a need I've repeatedly encountered over the past decade. There are several good third-party networking libraries available for C++, but none that took advantage of Boost and the new ASIO library that will be included in version 1.35. I have a lot of experience working with HTTP, and needed to develop (for the third time in my career) a lightweight HTTP server interface. Although I planned to release libpion as open source, I never gave much thought to submitting it for review to be included in Boost. Over time, and with support and encouragement from the community, my desire to do this grew. I've also been keeping up with the cpp-netlib project on SourceForge, which shares the same goal. For several months we've been kicking around the idea of merging our efforts. Today, I've decided to commit to winding down the Pion Network Library as an independent project, and merging all the code (about 15,000 lines) into the cpp-netlib project. This is going to be a gradual conversion and refactoring of code, adopting it into the framework and styles that have been established by the cpp-netlib folks. My goals will be to enhance cpp-netlib so that it is functionally equivalent to the current Pion Network Library (with asynchronous and synchronous HTTP 1.0 and 1.1 client and server-side support), and to help prepare cpp-netlib for inclusion in the next major Boost release. I expect that the transition will take at least 3 to 6 months. Because there are several entities actively using the Pion Network Library (including my own company, Atomic Labs), I plan to continue developing and enhancing it as an independent project at least until the transition has been fully completed. Dean, Glyn and I are excited about merging the two projects and developer communities, and I am happy to be part of what is now the definitive candidate for a Boost networking protocol library. Take care, -Mike

2 1

Release 1_35_0_RC2: Boost Python hello tutorial
by Johannes Brunen 22 Mar '08

22 Mar '08

Hi, today I have tried the boost python tutorial with the 1_35 release candidate 2. Unfortunately it didn't worked as expected. Especially, I'm missing the hello.pyd file after building the jamroot file. Below I describe what I have done in detail. I'm working on the windows platform with the msvc-7.1 compiler. First I build the bjam.exe from the tools/jam folder with the build_dist.bat script. Next I used this one to build all the boost libraries by running bjam --toolset=msvc-7.1 release debug stage from the command line. I then swichted to the libs/python/example/tutorial directory and called bjam --toolset=msvc-7.1 release debug from the command line. This failed with this output F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:307: in load-jamfile F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:63: in load F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:167: in project.find F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2\build-system.ja m:516: in load F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\..\..\..\t ools\build\v2/kernel\modules.jam:267: in import F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\..\..\..\t ools\build\v2/kernel/bootstrap.jam:132: in boost-build F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\boost-buil d.jam:7: in module scope I then added the following line at the beginning of the jamroot file: import python ; After running the bjam again I found the following files in the bin/msvc-7.1/release/threading-multi subdirectory. hello.obj hello.obj.rsp hello_ext.exp hello_ext.lib hello_ext.pyd.rsp As you can see. The hello.pyd (or hello_ext.pyd) file is missing. In order to confirm that I didn't fool myself, I tried exactly the same procedure with the current boost release 1_34_1. Here I found these files in the threading-multi subdirectory. hello.exp hello.lib hello.obj hello.obj.rsp hello.pyd hello.pyd.rsp With the hello.pyd file I was able to run the import from within the python interpreter. Is this a known problem? Is my procedure correct? Any tips what I can do? Johannes Brunen DataSolid GmbH

2 1