May 2008 - Boost - lists.boost.org

[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

Help required in asynchronous I/O
by Suresh 02 May '08

02 May '08

Hello, I am working on incorporating async I/O in postgres. I had the foll. doubts in async operation. If I do for(i=0;i<MAX;i++){ bzero( (char *)&aiocb1[i], sizeof(struct aiocb) ); aiocb1[i].aio_fildes = fd; aiocb1[i].aio_nbytes = BUF_SIZE; aiocb1[i].aio_buf = malloc(BUF_SIZE+1); aiocb1[i].aio_offset = off+100; //next_offset; aiocb1[i].aio_lio_opcode = LIO_READ; sigemptyset(&sig_act[i].sa_mask); sig_act[i].sa_flags = SA_SIGINFO; sig_act[i].sa_sigaction = aio_completion_handler; aiocb1[i].aio_sigevent.sigev_notify = SIGEV_SIGNAL; aiocb1[i].aio_sigevent.sigev_signo = SIGIO; aiocb1[i].aio_sigevent.sigev_value.sival_ptr = &aiocb1[i]; ret = sigaction( SIGIO, &sig_act[i], NULL ); off+=100; list[i]=&aiocb1[i]; } void aio_completion_handler( int signo, siginfo_t *info, void *context ){ int i=0,ret; if (info->si_signo == SIGIO) { ..... } } It calls the aio_completion handler once when all the i/o requests are completed and we check the signal and proceed. The same method if I use for callback using threads, then it calls the aio_completion handler MAX times instead of calling it only once. aiocb1[i].aio_sigevent.sigev_notify = SIGEV_THREAD; aiocb1[i].aio_sigevent._sigev_un._sigev_thread._function = aio_completion_handler; .... void aio_completion_handler( sigval_t sigval ) { ... } How do I do something similar to signal mechanism whereing a check if the signal is mine and then only proceed. In short, how do I guarantee that aio_completion_handler is called only once in case of list AIO. Please help me out of this. Thanks and regards, Suresh --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

1 0

throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 02 May '08

02 May '08

SVN rev. 44954 from yesterday introduces new g++ warnings (several g++ versions, incl. 4.1.2 Fedora 8). See below. Would it make sense to add the virtual destructors g++ want's to have? Ralf include_te.cpp: #include <boost/throw_exception.hpp> % svn update -r44953 Updated to revision 44953. % g++ -Wall -c -I$hot/boost include_te.cpp % svn update -r44954 U boost/throw_exception.hpp Updated to revision 44954. % g++ -Wall -c -I$hot/boost include_te.cpp boost/exception/detail/counted_base.hpp:17: warning: 'class boost::exception_detail::counted_base' has virtual functions but non-virtual destructor boost/exception/detail/cloning_base.hpp:19: warning: 'class boost::exception_detail::cloning_base' has virtual functions but non-virtual destructor boost/exception/enable_current_exception.hpp:24: warning: 'class boost::exception_detail::clone_base' has virtual functions but non-virtual destructor boost/exception/exception.hpp:27: warning: 'struct boost::exception_detail::error_info_container' has virtual functions but non-virtual destructor

2 1

[exception] exception_ptr for GCC
by Sebastian Redl 01 May '08

01 May '08

Hi, My quest for a general exception_ptr for GCC has reached its end, in the sense of, "I can't make it any better without modifying GCC." My current code is extremely fragile regarding code generation (it depends on the layout of the functions in the file) and there is one circumstance under which it leaks the exception object, but in general it works quite well. The header file, source file, and a file containing test cases are attached. Even though this can obviously not be used in production code, it's an interesting study of absurd things you can do in order to get around the limitations of a fixed ABI. Sebastian

2 2

[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

Build Issue in Sandbox
by Jared McIntyre 01 May '08

01 May '08

Were trying to get the explore library tests in the sandbox to build against 1.35, and are having issues in MSVC not being able to find libboost_unit_test_framework-vc80-mt-gd-1_35.lib at link time. Everything is fine in 1.35. I've tried building both as bjam --v2 and bjam --v2 -a --build-type=complete. We're trying to get this ready for BoostCon, so if anyone has any ideas, I'd really appreciate the help. Thanks, Jared This is the jamfile # Boost.Explore Library # Copyright Jared McIntyre 2007. Use, modification and # distribution is subject to the Boost Software License, Version # 1.0. (See accompanying file LICENSE_1_0.txt or copy at # http://www.boost.org/LICENSE_1_0.txt) # For more information, see http://www.boost.org # bring in rules for testing import testing ; project : source-location . : requirements ; { test-suite explore_stream : [ run is_assoc_iter.cpp ] [ run simple_types.cpp ] [ run c_array.cpp ] [ run user_defined_container.cpp ] [ run std_vector.cpp ] [ run std_deque.cpp ] [ run std_list.cpp ] [ run std_map.cpp ] [ run std_set.cpp ] [ run std_pair.cpp ] [ run boost_array.cpp ] [ run boost_tuple.cpp ] [ run boost_variant.cpp ] [ run boost_range.cpp ] [ run custom_format_simple.cpp ] [ run html_table_output.cpp ] [ run multi_dim_test.cpp ] [ run columnated.cpp ] ; }

1 0

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