- Boost - lists.boost.org

[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

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

26 Jun '12

Pete Bartlett: < snip > > Cons for 1) and 2): > - Always paying for the cost of #including <boost/throw_exception.hpp> > - All libraries are dependent on - and therefore become vulnerable to any > future breakages (if any) in - Boost.Exception. 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? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] Interest in a "breadth first" algorithm?
by Brian Wood 26 Jun '12

26 Jun '12

Gary Powell: > > A while ago I needed to serialize and de-serialize a std::map and I > realized that the only interface was begin(), end() which of course meant > that re-creating this same map was the least efficient way possible, as all > the elements were added in sorted order. Because I wrote them out using > begin() -> end() So I wrote a breadth first template which takes a > container, a template to use as the core of a queue, a template for the > allocator, the container and a function to apply to the elements. > It doesn't quite do a true breadth first traversal because I don't look at > the inner data structure of the map, (works with sets as well) but instead > does a middle, then right, left push until it's hit all of the nodes. And > it doesn't copy the elements, it pushes the iterators, and calls the > function on that iterator when the length is 1. > It ended up speeding up my map recreation by about 20% (because I start > with a center enough node that it should never have to be rebalanced) at a > cost of about 5% to write it this way (It's more expensive to create the > queue, and traverse the map from center on out), for a roughly 15% gain in > speed. > Is there any interest this for boost? I've got working code but not any > documentation. And rather than spend a huge amount of time on that I'm > looking to see if anyone else has an interest in this. I'm interested. If you like I'll give you an investment in Ebenezer Enterprises [1]. If you post it here or send it to me, I'll probably use it in the archive available here -- http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> . [1] Past performance is not a guarantee of future results. > > "Come gather 'round people wherever you roam. And admit that the waters > around you have grown. And accept it that soon you'll be drenched to the > bone. If your time to you is worth savin'. Ahh you better start swimmin' or > you'll sink like a stone. For the times they are a-changin'" Bob Dylan Huh. Bob Dylan is from the Hibbing/Duluth part of Minnesota. In the days after you posted, that area received a summer's worth of rain in 36 hours. An 8 year old boy nearly died in the flooding when he was swept down a culvert. Thankfully he popped up a mile down the system and has been giving interviews since. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 1

Re: [boost] Boost and exceptions
by Stewart, Robert 26 Jun '12

26 Jun '12

Robert Ramey wrote: > Dave Abrahams wrote: > >> I mean, if there is a problem with boost::throw_exception or > >> any other part of Boost Exception, I'd like to know about > >> it. > > > > It seems clear to me from his posts that Robert wants to > > talk about the process and has forgotten any specifics about > > actual problems. > > > The problem was the gratuitious inclusion of a new dependency. Emil has described repeatedly why the change was not gratuitous. That you fail to recognize the value in the change does not make it gratuitous. I looked at a recent boost/throw_exception.hpp. It includes boost/exception/detail/attribute_noreturn.hpp. That creates a dependency inversion that is unfortunate. That is, a top-level header file depends upon a header file of a library's files. That header is very short and has nothing Boost.Exception specific, so the code could be moved into boost/throw_exception.hpp or boost/detail/attribute_noreturn.hpp, for example. The header also conditionally includes the non-trivial boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions: boost::exception_detail::refcount_ptr boost:: error_info boost::exception boost::exception_detail::error_info_base boost::exception_detail::type_info_ boost::exception_detail::error_info_container boost::exception_detail::get_info boost::exception_detail::get_diagnostic_information() boost::exception_detail::copy_boost_exception() boost::exception_detail::set_info() boost::exception_detail::error_info_injector boost::enable_error_info() boost::exception_detail::clone_base boost::exception_detail::clone_impl boost::enable_current_exception() If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown. This is a non-trivial set of changes to make to the top-level header. I didn't follow the discussion at the time, but I'll presume there was a lot of discussion about the type and extent of these changes and that it was considered a good idea. In hindsight, I agree with Robert's assertion that there should have been a replacement function, boost::exception::throw_exception() or similar, to introduce the new functionality. Whether the existing function needed to be deprecated is a separate issue. The result is that libraries could knowingly choose the new version, and a dependency on Boost.Exception, or, if warranted, stick with the old. As things now stand, if there is good reason to avoid the new version, it can only be done by defining BOOST_EXCEPTION_DISABLE, which affects an entire build. > The extent/nature of any problem it created or didn't create is > not relevant here. Just the injection of a new body of code > which replaced two lines and added no functionality used/needed > by the serialization library makes the any library which used > boost::throw_exception "bigger" for no reason. The issue you're raising, as I understand it, is dependency inversion: the top-level header brings a dependency on Boost.Exception. > It makes the library more "fragil". It means I have I a new > place to look if something needs looking into. etc.etc. As Nevin pointed out, your code will always be subject to the changes in those libraries on which it depends. The more dependencies you introduce, the more fragile your code becomes, but there's a great deal of benefit to reuse, too. The only issue in this case is that one can reasonably expect a top-level header to avoid dependencies on libraries. > So we'll just move on as Vicente suggested. That will be > satisfactory from my standpoint. That is the only way forward, if there is good reason to avoid the now longstanding changes to boost::throw_exception(). However, you should work with Emil to be sure you correctly and fully understand the issues before deciding that you cannot accept boost::throw_exception() as is. (I don't pretend to know what your concerns are. I just don't want to see a new throw_exception() variant if there isn't a compelling reason, and I don't consider your fragility argument compelling in this case.) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

20 91

[contract] relaxing preconditions in subcontracting
by Andrzej Krzemienski 26 Jun '12

26 Jun '12

Hi Lorenzo, I am trying to understand how the feature of relaxing preconditions in overridden functions work or should work. Given the situation, where I call an overridden function via base class reference: *struct Base { virtual void fun(bool b) = 0 precondition{ b == true }; }; struct Deriv : Base { void fun(bool b) override precondition{ true }; }; void test( Base & b ) { b.fun(false); **// broken contract or not?** }* Should this be treated as a broken contract or not? My reading of the documentation says that contract is not broken (because the "logic-or<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…>" logic applies), but I feel that whoever implemented function *test *made a mistake: he cannot assume what type will be implementing "interface" *Base*, so he cannot rely on the precondition being relaxed (even if he gets away with it this time). Regards, &rzej

2 7

boost with cxxflags=-Zc:wchar_t-
by Renato Tegon Forti 25 Jun '12

25 Jun '12

Hi All, I'm mixing QT and boost and noticed problems with wchar_t! I need to compile boost: cxxflags =-Zc: wchar_t- Would like to know what problems I can find! anyone ever had to use 'wchar_t-"? Libs that I am using: boost_mpi boost_serialization boost_system boost_filesystem boost_thread boost_iostreams Thanks

3 2

library dependencies and boost modularization [ was Boost and Exceptions]
by Robert Ramey 25 Jun '12

25 Jun '12

Boost has now close to 100 libraries. In addition there are hundreds of smaller but necessary facilities which aren't technically libraries but they add a lot to the "surface area" that one's brain has to be familiar with to take best advantage of boost facilities. There is also a lot of interconnectedness which makes it an even larger task. This wasn't a big deal when boost was 15 libraries - but now it's different. I would like to propose a classification of boost libraries and guidelines for future libraries. a) Layering of libraries =============== 0) C++ standard library 1) "boost core" libaries 2) "boost utility" libraries 3) "boost user" libraries b) Guidelines ========= 1) a library in a given layer shall include code from libraries in a higher layer 2) boost core libraries are in namespace "boost" 3) boost user libraries are in the name space boost::<name of user library> 4) there is a special user library named "utility" for small libraries which are widely used. 5) boost header directory structures should match namespace structure. example, a library named boost.range should have all it's code in namespace boost::range and in the directory boost/range. 6) exception to 5) above, a user library might have a "convenience header" in directory "boost" which includes all the header directories of that user library. c) Rationale ======== 1) it diminishes the possibility of namespace conflicts as boost/C++ grows 2) it diminishes the possibility of importing a lot more code and depencies than one expected. 3) a library can control its depencies. Often a library will rely only on "boost core". This means that users of the library can know that code is dependent only on that library. 4) It more easily supports the concept of "boost modularization" where by deployment of a subset of boost libraries is can be supported. It's often mentioned how other languages like java, C#, perl have HUGE number of libraries in comparison to C++. I believe these languages have reached their peak and are in fact in decline somwhat. It is possible that this huge number of libraries make them less attractive rather than more? Perhaps a little more formal structure applied to our work might be agood thing. Robert Ramey

1 0