- Boost - lists.boost.org

[Survey] utf8_codecvt_facet::do_length parameter
by Marshall Clow 28 Jun '12

28 Jun '12

There's some confusion in boost (and in various standard libraries) as to the declaration of std::codecvt<>::do_length The '03 and '11 standards say: > template <class internT, class externT, class stateT> > class codecvt : public locale::facet, public codecvt_base { > // blah blah blah > virtual int do_length(stateT&, const externT* from, const externT* end, size_t max) const; > }; But some standard libraries (notably older Dinkumware libraries, and Visual C++ before Visual Studio11) say: > virtual int do_length(const stateT&, const externT* from, const externT* end, size_t max) const; (the first parameter is a const reference) There's some preprocessor stuff to deal with this in boost/detail/utf8_codecvt_facet.hpp, but it's wrong: > #if !defined(__MSL_CPP__) && !defined(__LIBCOMO__) \ > && !defined(_LIBCPP_VERSION) > #define BOOST_CODECVT_DO_LENGTH_CONST const > #else > #define BOOST_CODECVT_DO_LENGTH_CONST > #endif > > virtual int do_length( > BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &, > const char * from, > const char * from_end, > std::size_t max_limit > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > ) const throw(); > #else > ) const; > #endif I'm happy to fix this, but I'd like to be sure which systems actually have const parameters. I've checked gcc and libc++, and they match the standard. STL assures me that all versions of Visual Studio before VS11 do not match, but VS11 does. The #defines above suggest to me that LibCOMO has this problem as well. Does anyone have access to such an install? And if anyone's standard library (that I haven't listed) does define the first parameter to std::codecvt<>::do_length as a const reference, please let me know. Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[1.50.0] Release candidate 2 available for testing
by Beman Dawes 28 Jun '12

28 Jun '12

Release candidate 2 files for 1.50.0 are available at http://boost.cowic.de/rc/ RC 2 is supposed to fix the --layout build problems reported for RC 1. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

7 7

[chrono] chrono/config.hpp enforces that time.h defines CLOCK_REALTIME; should it?
by Krzysztof Czainski 28 Jun '12

28 Jun '12

Hello, Suppose I want to use durations, and time_points with a user defined clock. I don't want to use any clocks provided by Boost.Chrono. My compiler provides a <time.h>, which doesn't define CLOCK_REALTIME, which chrono/config.hpp reports as an error. This prevents me from using parts of Chrono, that I believe don't depend on anything from <time.h>. I am able to work around this by simply defining CLOCK_REALTIME. But I would like to ask: Could Boost.Chrono allow using duration.hpp and time_point.hpp in my case? Regards, Kris

2 3

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 27 Jun '12

27 Jun '12

Emil Dotchevski: > On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> Is there a penalty for single threaded applications here? There's >> been discussion of the support for transferring exceptions between >> threads; are there aspects of that support that are unneeded in a >> single threaded context? >> > > There are 3 aspects of boost::throw_exception: > > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, > 2) it enables boost::error_info, and > 3) it enables boost::exception_ptr. > > 1) and 2) have nothing to do with threads; 3) implements > std::exception_ptr, which mostly benefits multi-thread programs (until > compilers catch up with std::exception_ptr support.) > > The cost imposed by libraries that use boost::throw_exception to programs > that don't use boost::exception_ptr or boost::error_info is that sizeof() > the exception object grows a little. I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads." Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
by Leo Goodstadt 27 Jun '12

27 Jun '12

> On 22 June 2012 17:51, Vladimir Prus <ghost(a)cs.msu.su> wrote: > > > On 22.06.2012 11:33, Emil Dotchevski wrote: > > > >> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost(a)cs.msu.su> wrote: > >> > >> On 20.06.2012 07:44, Rowan James wrote: > >>> > >>> On a related note; is there interest in a patch set to use > >>>> BOOST_THROW_EXCEPTION to add this (yes, programmer-oriented) information > >>>> to > >>>> the exceptions thrown by Program Options and/or other Boost libraries? > >>>> > >>>> > >>> Sorry, but I kinda miss context here (and I did read your original post). > >>> What are advantages of > >>> using BOOST_THROW_EXCEPTION and what are drawbacks? Could you summarize > >>> those for me? > >>> > >>> > >> Allow me :- > >> > >> BOOST_THROW_EXCEPTION, being a macro, is able to record the file name, the > >> function name, and the line number of the throw, which is useful when > >> diagnosing unexpected exceptions: > >> > >> catch(...) > >> { > >> std::cerr<< "Unexpected exception caught. Diagnostic information > >> follows.\n"; > >> std::cerr<< boost::current_exception_**diagnostic_information(); > >> } > >> > >> The exception object is examined dynamically for any and all useful > >> information: type, what(), throw location, any stored boost::error_info > >> objects, etc. The location of the throw (if available) is formatted in a > >> way Visual Studio understands: double-clicking shows the throw location, > >> similarly to double-clicking compile errors. > >> > >> The downside is that when templates are involved, BOOST_CURRENT_FUNCTION > >> (invoked by BOOST_THROW_EXCEPTION) can bloat the code. There is a Trac > >> ticket for this. > >> > > > > Emil, > > > > thanks for explaining. Given the above, I am not sure I am interested in > > using > > BOOST_THROW_EXCEPTION for program_options, given that exceptions are used > > there to report > > user mistakes mostly, and so function name or file line is of limited > > interest. > > > > Thanks, > > Volodya > > > Thanks Emil. > > If I can make the case in favour of BOOST_THROW_EXCEPTION, it is for the > very reason that they are reporting user mistakes. The throw location for > an exception is typically accompanied by, or at least close to, the logic > that delineates such a user mistake from acceptable input. As such, it is > a useful remedy in itself; but also gives the user specific information for > finding documentation relevant to fixing the error. Without it, we have at > best the entry point into the library that; and often a lot less if the > exceptions are caught at a higher level. > > Documentation for valid inputs or states to a function can only say so much > about all the possible errors or exceptions that may occur. To elaborate on what Volodya said, program_options is unusual (for Boost) library in its use of exceptions: Most of the time, exceptions are there to inform the programmer of an error in the programme. However, the majority of exceptions in program_options are there to indicate a problem in the construction of the command line by the *end-user* (not the programmer). In other words, the program *is* working exactly as designed. The programmer has no interest in the provenance of these exceptions *except* that they can be used to inform the end-user how they should retype the command line and try again. So, for example, ten times a day, I will type something like ls --colour * and ls will tell me ls: unrecognized option '--colour' and I will know to retype the US spelling... ls --color * If "ls" were using program options, an unrecognised option exception message will be thrown which eventually allows this informative message to be displayed before exiting. It is entirely unhelpful for the end-user to have Exception XXX on line xxx of file yyy.... To make it easier to use program options *in English*, the exception messages have been recently rewritten to be maximally informative to the end-user rather than the programmers. Thus we can take e.what() and write it out to std::cerr without further ado. Of course, for localisation, these error messages have to be reconstructed in the appropriate language. Hopefully, there is enough data in each exception to allow this. Curiously, the current design of exceptions in program_options ended up try to mirror what Emil has done in BOOST_THROW_EXCEPTION. When the exception is thrown deep in the bowels of the command line parsing, it does not have the full context which would allow an informative message to be constructed. The exception has to be propagated up, and then "decorated" before being rethrown. The alternative was to pass the full context down the function call hierarchy to each point at which exceptions can be thrown. This made the code horribly convoluted and ugly, and provoked loud cries of anguish from Volodya. Leo

5 4

Interest in static multidimensional array.
by Brian Smith 27 Jun '12

27 Jun '12

Hi All, Some time ago I uploaded the maps folder, to Boost's sandbox, containing various multidimensional and mathematical arrays. The resulting discussion appeared to indicate some interest in the multidimensional arrays and that the overall design required some reworking. Having now had the opportunity to use a compiler supporting variadic templates, I have rewritten the static multidimensional array class using them. The class, documentation, and some tests are available at, https://github.com/BrianJSmith/Array All feedback would be welcome. Regards Brian -- www.maidsafe.net

2 2

[pool] Objects of varying sizes
by Robert Dailey 27 Jun '12

27 Jun '12

Is it possible to create a pool for polymorphic types? For example: class A; class B : public A; class C : public A; I want to create a pool of type A, but the allocation can be for B or C at any time. Will this work?

7 11

[build] Problem building boost libraries from trunk with layout versioned
by Thomas Heller 27 Jun '12

27 Jun '12

Hi, I am trying to build current trunk with layout versioned. Boost build is currently failing. This looks similar to the problem reported with the 1.50 RC. Here is the error: [heller@faui32m trunk]$ ./b2 toolset=intel --layout=versioned -j2 variant=debug Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>libboost_context-il-mt-d.so error: previous virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } error: created from ./stage-unversioned error: another virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { symlink%symlink.ln-libboost_context-il-mt-d-1_50.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } } error: created from ./stage-unversioned error: added properties: none error: removed properties: none /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:135: in object(file-target)(a)3737.actualize from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build-system.jam:750: in load from module build-system /home/heller/programming/boost/trunk/tools/build/v2/kernel/modules.jam:283: in import from module modules /home/heller/programming/boost/trunk/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /home/heller/programming/boost/trunk/boost-build.jam:17: in module scope from module It seems to work when using --layout=system Anyone knows a fix to this? FWIW, toolset=gcc has the same problem Thanks, Thomas

2 2

program options (consider using BOOST_THROW_EXCEPTION)
by Roger Martin 27 Jun '12

27 Jun '12

Hi boost, At version 1.49.0 In testing command line with known unknowns such as -V a location unknown exception is thrown from inside program_options recommending to use BOOST_THROW_EXCEPTION. I've been trying to find this and apply BOOST_THROW_EXCEPTION to eliminate the verbosity for users: ---- Command line incorrect: Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> > std::exception::what: unknown option -V ---- With this fixed then it'd be closer to: -------- Command line incorrect: unknown option -V -------- Yet I haven't found where. Baffled. Any hint?

6 12

[stl_ext_adv] array based B+ tree
by Vadim Stadnik 27 Jun '12

27 Jun '12

Hi all, First of all, I would like to thank all Boosters for previous useful discussion of dynamically allocated augmented B+ trees. The development of the new array based variant of a B+ tree has been significantly influenced by these comments and suggestions. The problem of the C++ standard sequences based on linear data structures is that every of them has at least one inefficiency, such as linear cost of insert(), erase() functions of std::vector or slow bidrectional iterators of std::list. These inefficiencies create performance bottlenecks and significantly complicate the development of efficient general algorithms based on STL sequences. The new variant of an array based B+ tree offers a solution to these problems of STL sequences by reducing the running time of inefficient operations from linear to logarithmic in the worst case. The array based B+ tree implements a simple partition of an array into a list of sub-arrays connected to a B-tree. Compared to dynamically allocated B+ trees the new tree requires less space and improves locality of reference. In some aspect the array based B+ tree represents an enhanced pool allocator. Performance of the new tree has been optimized for container operations with large numbers of elements. In a number of tests the improvement factor is about 10. A significant advantage of the array based B+ tree over standard sequences is the support of splice() functions with logarithmic running time in the worst case. The high efficiency of these functions extends move semantics for non-intrusive STL sequences, since they allow user algorithms to insert and remove any range of consecutive elements. This high efficiency is not available in standard containers of C++03 and C++11. The splice() function of std::list has linear running time in the worst case. For a discussion of this problem by Boost community, please have a look at this thread: http://boost.2283326.n4.nabble.com/Containers-How-about-a-list-with-O-1-spl… For associative containers the array based B+ tree offers random access iterators and improved efficiency of many container operations against dynamically allocated B+ trees. In the general case associative containers cannot benefit from the splice() functions. Nevertheless, they can be used in algorithms for efficient split operations, since these operations do not change the order of elements in obtained containers. I think that the array based variants of B+ trees are very important, since they offer a number of performance benefits and can be used in many areas from mobile applications to processing huge data sets. The new array based B+ tree is described in this document: http://dl.dropbox.com/u/51041088/stl_ext_adv_doc/doc/array_based_bp_trees.h… The project with source code and tests: https://github.com/vstadnik/stl_ext_adv The new file with implementation of the array based B+ tree: https://github.com/vstadnik/stl_ext_adv/blob/master/container/bp_tree_array… I will appreciate any comments, suggestions and ideas concerning augmented array based B+ trees and STL variants of containers using these data structures. Regards, Vadim Stadnik

1 0