April 2008 - Boost - lists.boost.org

Another C++ puzzler
by Marco Costalba 02 May '08

02 May '08

After the great success of Eric's puzzle on the common type of a given types set here it is another puzzle for you C++ wizards. This one arise from the multi signature boost function implementation recently posted to this list. Let's have two boost.function objects, each one defined on a different function signature Sig_1, Sig_2 boost::function<Sig_1> boost_fun_1; boost::function<Sig_2> boost_fun_2; Then have two overloaded template functions called "set" to assign a function/functor to either one of the above boost.function objects template<typename Fun> void set(Fun const& fun, typename enable_if<is_compatible<Fun, Sig_1> >::type* = 0) { boost_fun_1 = fun; } template<typename Fun> void set(Fun const& fun, typename enable_if<is_compatible<Fun, Sig_2> >::type* = 0) { boost_fun_2 = fun; } To disambiguate between the two a SFINAE technique is used on the second (hidden) argument of "set" Where struct is_compatible is defined as: /* Check if a function/functor Fun has a given signature Sig */ template<typename Fun, typename Sig> struct is_compatible { /* Check for a function */ template<class U> static yes_type check(typename enable_if<is_same<U, Sig> >::type*); /* Check for a functor */ template<class U, Sig U::*> struct helper; template<class U> static yes_type check(helper<U, &U::operator()>*); /* Default */ template<class U> static no_type check(...); typedef typename boost::remove_pointer<Fun>::type F; static bool const value = (sizeof(check<F>(0)) == sizeof(yes_type)); }; Now the puzzle is: There is a way to remove struct is_compatible altogether ? or at least greatly simplify it ? Constrains are - Public API must be set(fun) where fun is any functor/function for which either expression "boost_fun_1 = fun" or "boost_fun_2 = fun" compiles. - If both "boost_fun_1 = fun" and "boost_fun_2 = fun" are not compilable then a compile error should raise Hint: an almost working solution could have been template<typename Fun> void set(Fun const& fun, bool = (boost::function<Sig_1>() == fun)) { boost_fun_1 = fun; } template<typename Fun> void set(Fun const& fun, bool = (boost::function<Sig_2>() == fun)) { boost_fun_2 = fun; } But unfortunately it is forbidden to refer to an argument (fun in this case) in the expression of the default value of another argument. Have fun Marco

4 7

[parameter][serialization] VC 8/9 regression test failures
by Richard Webb 02 May '08

02 May '08

The trunk regression tests are showing a large number of failures for Parameter and Serialization (and several other libraries that use them). These seem to have appeared as a result of some recent type_traits changes. -parameter- The parameter tests are failing with: ..\boost/parameter/aux_/tagged_argument.hpp(173) : error C2504: 'is_convertible' : base class undefined This can be fixed by adding # include <boost/type_traits/is_convertible.hpp> to tagged_argument.hpp -serialization- The serialization tests are failing with: ..\boost/serialization/is_abstract.hpp(43) : warning C4005: 'BOOST_IS_ABSTRACT' : macro redefinition ..\boost/type_traits/intrinsics.hpp(99) : see previous definition of 'BOOST_IS_ABSTRACT' Due to a BOOST_IS_ABSTRACT that was just added to type_traits conflicting with one that already existed in serializtion. Thanks, Richard Webb

4 4

[Concept Check] - Extending the BCCL with AllocatorConcept
by Michael Fawcett 01 May '08

01 May '08

I recently had the need to code up an AllocatorConcept, and it occurred to me that it might fit well within the BCCL. I noticed that Intrusive also had an allocator concept and wondered if other libraries did too (perhaps under a different name). Would this be of interest as an extension to BCCL? A quick Google search of boost.org shows that dynamic_bitset, multi_index, function, regex, shared_ptr (and I'm sure more) all have Allocator template parameters where it might make sense. For very generic concepts such as Allocator, do they belong in BCCL rather than coded in each library? I've pasted the code below. --Michael Fawcett -- code -- namespace boost { template <typename T> struct AllocatorConcept { typedef typename T::const_pointer const_pointer; typedef typename T::const_reference const_reference; typedef typename T::difference_type difference_type; typedef typename T::pointer pointer; typedef typename T::reference reference; typedef typename T::size_type size_type; typedef typename T::value_type value_type; // TODO: Do we need to do more here, e.g. char_allocator_type::rebind<value_type>::other == T? typedef typename T::template rebind<char>::other char_allocator_type; BOOST_CLASS_REQUIRE(T, boost, DefaultConstructibleConcept); BOOST_CLASS_REQUIRE(T, boost, CopyConstructibleConcept); BOOST_CLASS_REQUIRE(T, boost, EqualityComparableConcept); void constraints() { pointer p = 0; reference ref = *p; const_reference cref = *p; p = value.address(ref); const_pointer cp = value.address(cref); p = value.allocate(1); p = value.allocate(1, 0); value.construct(p, *p); value.deallocate(p, 1); value.destroy(p); size_type s = value.max_size(); } private: T value; }; }

2 3

Boost.Python: Build and Install with Python 2.4 and 2.5?
by Steve M. Robbins 01 May '08

01 May '08

Hi, I'm part of the Debian Boost packaging team, seeking some guidance on how to build and install Boost.Python so that it is usable with all Python versions shipped in Debian. Debian currently ships Python 2.4 and 2.5. When reading the following, keep in mind that Boost.Python is not a Python extension but, rather, a library that eases writing an extension in C++. So it is necessary that the compiled libraries be visible to be linked with user-written C++ code. One idea is to use a user-config.jam file containing using python : 2.4 : /usr ; using python : 2.5 : /usr ; Then run jam twice bjam variant= ... bjam variant= ... python python=2.5 This produces pairs of library files such as bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a (and similar pairs for shared libraries and all other variants). The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib. The question, then, is how to distinguish them once installed? Should we: 1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a 2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g. libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a 3. Put the libraries in different subdirectories, e.g. /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a 4. Put the default version directly in /usr/lib and the others in subdirectories, e.g. /usr/lib/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a The drawback to all these approaches is that client code has to be adjusted to build on Debian. Linking against Boost (for non-bjam projects) is already hard enough with the decorated library names that I fear making the situation worse. The attraction of #4 is that at least the variants for the default python version are found in a natural manner. This has some appeal to me, personally, but I worry that it is too easy to build an extension to python 2.5 and link in the wrong Boost.Python library. In contrast, the other options have the advantage that it forces the user to declare which version of Python is being used. I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing? In principle, it would be nice to have the Boost libraries named the same across distributions. Thanks, -Steve

3 5

Re: [boost] Release 1_35_0_RC2: Boost Python hello tutorial
by Johannes Brunen 01 May '08

01 May '08

Beman Dawes wrote: > In the meantime, have you tried a more modern version of VC++? > The free download of VC++ 2008 Express Edition, for example. Ok, I just tried the same procedure with the VC++ 2005 (i.e. 8.0) compiler with the same result. It does not generate the .pyd files, neither in release mode nor in debug mode. Thanks, for adding it to the issus list Best, Johannes

8 15

Please let's avoid sending mails containing HTML parts
by Jens Seidel 01 May '08

01 May '08

Hi, I noticed that Boost's mailing list rules don't forbid sending useless HTML attachments which is not a good idea for discussion lists. Please let's extent http://www.boost.org/more/discussion_policy.htm to avoid this. Advantages: * Smaller messages * Faster opening (difference between text and HTML parts can be factor 10 and more!) * More consistent display formatting (no differences between text and HTML can occur without HTML) * There is absolutely no need to send HTML stuff. If one really depends on pictures or similar stuff the person should use normal attachments or even better upload the data to a remote site Omitting HTML parts is just a common rule for many lists, strange that Boost didn't enforce it yet. Jens

5 4

Status of property_tree library
by Marcin Kalicinski 01 May '08

01 May '08

I'll try to shed some light on what has happened to property_tree since review and why it's been dragging. Since review I had some feedback about the library. The issue raised most frequently was unsatisfactory performance. Ptree does too many memory allocations, and thus is fairly slow and unsuitable for many users. Plus some of the original parsers (XML parser specifically) were really slow and took ages to compile, especially on gcc. Because this is headers only library that is supposed to be lightweight, this was a serious problem. To solve it I spent some months implementing a very fast in-situ XML parser for the library (called rapidxml - see rapidxml project on sourceforge). This was finished in August last year and integrated with property tree. It works very well and is so fast that time to parse XML is now totally insignificant compared to the time it takes to build a ptree from the parsed data. The allocations problem remains. I have been unable to come up with a scheme that would reduce the number of allocations without compromising simplicty of the library. The key point is that I want to maintain validity of iterators in presence of insertions/erases. This rules out array based containers. The best I can think of is a custom list implementation. That has potential to reduce number of allocations by roughly 30%, which is not enough IMO. On top of that I'm not sure whether the heavy type-parametrization of the library (i.e. lots of template parameters everywhere) is a good thing. It definitely makes it harder to document, use and understand. In all the the feedback I got there is no evidence of anyone actually using these template parameters. So IMO these should be reduced to just the character type. Otherwise the library pretends to be a generic tree container, which it wasn't supposed to be. Finally, probably the main reason the library is dragging is docs. The original docs (still available at http://kaalus.atspace.com/ptree/doc/index.html) were written in a gargantuan effort manually in HTML. This was a horrible experience that I do not wish to repeat. Some sort of automated docs generation is needed. I know about QuickBook and I like its wiki syntax. About a year ago I even managed to setup the toolchain correctly (including doxygen). The output of [code->doxygen->quickbook->boostbook->xml->xslt->html] pipe was not very satisfactory though, the reference entries were badly formatted and scattered all over the place in a disorganized fashion. I wouldn't like to give up the library because I still work on it occasionally. But as I wasn't able to solve major problems (docs tools, performance) satisfactorily, the work towards the release has ground to a halt. IMO the issues that should be addressed before release are: - Simplification by removing some of the template arguments (arguable - maybe someone is using that?) - Figure out which parsers are unneccessary and get rid of them (cmdline parser?) - Get some docs toolchain to work properly and provide up-to-date docs. Lots of the text can be ported over (and my monkey english corrected :-) from the original docs. - Speedup through use of a custom container (to replace std::list, needs some profiling work if it's even worth it) If someone could help with the docs toolchain (Quickbook experts? Any alternatives?) I'm happy to do the rest. I should probably give up on trying to speed it up further and concentrate on getting it into releasable state. thanks, Marcin

9 12

Review Requests: shifted_ptr, list, stack & roofof
by Phil Bouchard 01 May '08

01 May '08

Greetings Boost: I am happy re-submitting after 4 years my final design and implementation proposal of "shifted_ptr" which includes very useful tools named "list", "stack" and "roofof". The new containers consisting of STL-like ones but offering external access to the nodes, removing the need of dynamically allocated nodes and thus offers multi-dimensional control over their elements. "roofof" is a one line helper function used in conjunction with the mentionned containers to find the root address of the class housing the member used by the container in question. In contrast with its previous submission, "shifted_ptr" now relates to a memory manager of constant complexity and of size: sizeof(void *) * 2. It take advantage of the low-memory consuption, fast execution and very versatile interface. It proposes a very different concept, removes the need of current functions such as: "enable_shared_from_this", destroys the "cyclic pointer" problem and is now perfectly type-safe. The former reference counted smart pointer was renamed to "shifted_ptr_base" and merged properly with Boost standards. Morever "shiifted_ptr" is closely tied to the current "shared_ptr" that uses objects derived from "sp_counted_base". This was extended to objects deriving from "owned_base", which includes the necessary information that is handled by the smart pointer plus a smart destructer that differentiates arrays from standard objects and destroys the object accordingly. I have not yet written entirely its documentation but I have included a well documented reference to its API. I would like to schedule a review for now and by then the documentation shall be completed. I am also aware the library doesn't yet handle multi-threaded applications but I would like to start with getting the library better known. The theory behind is perfectly reliable but I can't say I forgot technical issues. The library is located at: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Thank you, Phil Bouchard

4 19

[shifted_ptr][3.0] Important bugs fixes
by Phil Bouchard 01 May '08

01 May '08

Greetings: I have made many bug fixes to the library and it now runs properly a previous example requested. The code is much more robust and I would like requesting everyone to replace any 2.x series with this one. There is unfortunately a situation on MSVC when shifted_ptr<> is used with arrays. I believe there is an array to pointer to array convertion problem at runtime (inside new_sh) but this issue needs to be further investigated. I disabled array functionality for MSVC until it can be fixed. Everything works fine under GCC. Regards, -Phil

2 9

Boost Exception integrated with throw_exception.hpp
by Emil Dotchevski 30 Apr '08

30 Apr '08

I've committed the change to throw_exception.hpp which enables the support for exception_ptr and other Boost Exception features for all exceptions emitted from boost::throw_exception(). Boost Exception has been tested on a variety of platforms and compilers, but the throw_exception() function is used by many different Boost libraries, some of which work even on compilers that are not officially supported by Boost today; so the new throw_exception() behavior can be disabled using #define BOOST_EXCEPTION_DISABLE. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0