September 2009 - Boost - lists.boost.org

[integer] Compilation failed in Visual Studio
by Adam Badura 28 Oct '09

28 Oct '09

Following simple program: #include <boost/integer_fwd.hpp> int main() { return 0; } does not compile in Visual Studio 2008 with Boost 1.40.0. Compilation errors are following: 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template Adam Badura

6 9

[BGL] Multithread problem inserting edges and exploring the same graph
by Cosimo Calabrese 21 Oct '09

21 Oct '09

Hi to all, I've a problem on BGL. My environment is WinXP, Visual Studio 2005, Boost 1.37. I'm trying to use BGL in the following way. I've a single graph in my application, that is an adjacency_list< vecS, vecS, ... >, and I've 2 kind of threads that work on the graph: - some "Explorer" threads, that executes a Dijkstra's algorithm repeatedly; - some "Integrator" thread, that call the add_edge() function repeatedly. The program often crashes, because it cannot dereference some graph elements, some auto_ptr... The crash isn't sistematic, so I think there's a concurrency problem. I think that the problem is in the use of the vectors in the implementation of the graph. In general, if I've an iterator 'it' that point on an vector's element A, and I insert another element B before A, then the iterator is now invalid. I suppose that it happens something of similar in the graph. If I read the out-edge list of a vertex at the same time that I add another out-edge to the same vertex, the reading may be inconsistent. So I've tried with an adjacency_list< listS, vecS, ... >, because if I add an element to a list, the previous reference are still valid, but I've experienced the same problem again. If what I've said is correct, then I think that with an adjacency_matrix I will not have problems, but I've approximately 5 millions of vertices, and the graph is sparse. I think that is a waste of memory. And what about the exploring time? Another question: if I launch *only* a set of Explorer thread, it seems that there aren't problems with EdgeList = listS and EdgeList = vecS too. Can someone confirm to me that the exploring algorithms, like Dijkstra, don't modify the graph structure? Are they read-only algorithms? Can I safely launch multiple exploration threads simultaneously? Can someone help me? Many thanks in advance, Cosimo Calabrese.

5 24

[utility] auto_buffer v2
by Thorsten Ottosen 07 Oct '09

07 Oct '09

Dear All, Hereby an updated class. Thanks to all who contributed with comments to the first try. I have made the following changes: 1. push_back() overloads are now growing 2. added swap() (boy, was this nasty to implement). I assume the allocator can be wapped without throwing. How do other people copy with this problem? 3. added copy-constructor + copy-assignment 4. made the min capacity equal to N, the number of elements in the stack buffer 5. the size of the internal buffer is now controlled via two policies: template< unsigned N > struct store_n_objects; template< unsigned N > struct store_n_bytes; the default is store_n_objects<256>. The reason is that we don't want the capacity to change just because we compile on a different platform. 6. added comparison operators Comments most welcome! best regards -Thorsten

4 7

[rdb] 0.0.09
by Jean-Louis Leroy 04 Oct '09

04 Oct '09

In this version : * EXISTS * consistency check in INSERT...SELECT * DISTINCT, ALL * transactions The transaction stuff is pellicular. It simply maps to vendor calls. I am hesitating a bit, either make a common interface for the most common operations (like execute) directly in each backend (aside with vendor-specifc calls) or put them in a separate wrapper or even decide that it's not in the scope. There's more redesign in the select from which I think I can get an elegant implementation of vendor-specific features (like LIMIT). The idea is to pass all the data in a fusion map, allowing vendor specific parts of the statement to slip their own data inside it. In fact this also is how DISTINCT works. I dropped the composition of lists via chained calls to operator (). It's all preprocessor-based now. The () chain system was limited by FUSION_MAX_VECTOR_SIZE anyway. I have installed MySQL on my computer. I am still accessing it via ODBC but I'll probably start the native support soon. Yesterday I tried to upload and just when I pushed the upload button the vault server crashed. I suspect that it was my upload that triggered it. J-L

6 15

[Fusion] port to c++0x
by Christopher Schmidt 04 Oct '09

04 Oct '09

I participated in Google's 'Summer of Code' for Boost this year. My project was to port Boost.Fusion to c++0x. The program is over now and I would like to give you a short report on my work and put my code up for comments. In a nutshell, there is rvalue support, native variadic templates are used if possible and the public classes and (meta-) functions are guarded by a set of static asserts that detect most invalid (template) arguments. I also added certain new functionality to provide an easier, faster and more intuitive programming interface. My implementation is pretty much backwards compatible and all test cases pass on gcc 3.4/4.4 and vc 9. Here is a short overview of the most striking changes besides the implementation of raw c++0x support. I removed the deque container and the extension-classes. The deque container is undocumented and, in my opinion, does not go well with the other container due to its intrinsic extension mechanism. There also should not be a performance gain compared to a regular fusion::joint_view in combination with two fusion::vector. The extension classes are pretty much Boost.Proto specific. At the moment they seem to be out of place, especially as they are undocumented, unmaintained and not even part of the regular file structure. I would like to see them either fully documented (with the underlying concept of segmented sequences) or in the detail namespace of Boost.Proto. I added support for associative iterators. An associative forward sequence shall provide an iterator type which implements the extension backend of the intrinsic (meta-)functions fusion::result_of::value_of_data, fusion::deref_data and fusion::result_of::key_of. This has the advantage that all view classes, even fusion::iterator_range, are able to adapt the underlying sequence's associative-ness. fusion::transform_view, as a special case, got an additional template parameter. This parameter specifies whether the view should model either the forward concept only or the associative and the forward concept. This design breaks consistency with Boost.MPL. Unfortunately these changes are crucial and I would rather risk this break with Boost.MPL than missing that important feature. Using the old implementation, there is no way to avoid explicitly converting from a view back to an associative sequence to preserve the associative-ness. This leads to a nasty runtime overhead due to evaluation of every element of the view and copy-/move-constructing it. Besides, other changes include: -If the compiler supports rvalue references, all fusion container have a template constructor (taking either const lvalue or 'templated' rvalue references). -If the compiler supports variadic templates, fusion::cons, fusion::pair and fusion::single_view have a variadic template constructor (taking either const lvalue or 'templated' rvalue references) that allows emplace construction. -The view classes adapt the full category of their underlying sequences. As mentioned above, the associative-ness is preserved, but also, if possible, the random-access or bidirectional trait. -The result_of::-metafunctions accept r- and lvalue references arguments. If an argument is not reference-qualified, it will be considered to be an lvalue reference. All existing extension implementations must be changed to adapt this new behaviour. -The algorithm functions now also take (and correctly forward) non-const reference arguments. -Fusion iterators (with reference compatible sequence types and a very same index) and views (with reference compatible sequence types) have a working operator= that correctly reassigns the underlying sequence references. -Fusion now also adapts MPL iterators. If, and only if, the <boost/fusion/adapted/mpl.hpp>-header is included, mpl sequences and iterators are recognized as fusion sequences and iterators. -There are new headers to adapt std::(tr1::)array or std::(tr1::)tuple. The overall compile-time performance of my code is satisfying. Compiling a compilation unit that includes all possible fusion headers takes on gcc 4.4 slightly more time than the official fusion implementation. If native variadic templates are present, the compilation is a lot faster (usually up to 3 to 6 times), regardless of the value of FUSION_MAX_xxx_SIZE. The compile-time performance of actual fusion code is mixed. The intrinsic container and iterator (meta-)functions compile a little bit slower compared to the official fusion implementation. This is due to explicit removal of the references on the arguments of all result_of::metafunctions and some additional abstraction layer. If the compiler support rvalue references, there has to be a rather ugly and slow type evaluation/transformation to avoid issues with rvalue references on non-array, non-class types (see /support/internal/ref.hpp and 8.5.3p5 of the current c++0x draft for more details). On the other hand, I added several optimizations (such as result preevaluation), and, if variadic templates are present, the actual instantiation of fusion containers is a lot faster. All in all, the compile-time performance is a little bit worse if c++0x features are not present. If c++0x features are present, the code should compile a little bit faster in most cases. For example, the lambda example of the Boost.Proto documentation, which internally heavily relies on Boost.Fusion, takes on my machine 2.6 seconds to compile with the 'old' fusion on gcc 4.4, 3 seconds with my port without -std=c++0x, and 2.1 seconds with c++0x features being present. The overall performance might be even better once Boost.MPL adapts native variadic templates and the compiler supports template aliases. There have been tons of other changes, mostly bugfixes, optimizations (in terms of compile time of course) and removals of redundancy. Whenever I had the choice, I tried to prefer clean, redundancy-free instead of heavily optimized code. The overall performance loss is not noticeable though, and most compile-time optimizations that go beyond the as-little-template-instantiations-as-possible paradigm are pretty much compiler dependent anyway. There is still some work to do. I did not add c++0x-specific test cases and there are several parts of the documentation which need to be updated. By the way, are there any official guidelines for documenting c++03/c++0x-specific differences? For now, I would like to hold off on implementing these changes until Boost.TypeTraits adapts c++0x. Right now I implemented missing or incorrectly behaving trait functions in the fusion::detail-namespace. I would rather like to use the official ones, at least in the documentation and in the test cases. Besides that, I think my implementation is trunk-ready. If there are no objections, I would like to finish the outstanding work as soon as possible, and then merge my code with the trunk. Of course I will provide long-term support for the project. In fact, I would love to become an official fusion maintainer. You can find the code in the boost sandbox (/sandbox/SOC/2009/fusion). If you test the code with a compiler that has decltype support, please use the HEAD of the trunk rather than the official 1.40 distribution package to compile your code. Best regards Christopher

6 17

Review Request: Boost.Itl; The Interval Template Library
by Joachim Faulhaber 03 Oct '09

03 Oct '09

Dear developers, the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well. To decide, whether it's design, implementation and overall usefulness is sufficient to be accepted in the boost libraries collection is now up to you. In the last round of refactoring I concentrated on efficiency and optimization issues. The implementation of the itl's interval containers is still based on std::set and std::map, but algorithms are now exploiting hinted insert and are manipulating intervals and values in place instead of copying in many instances. This way, it has been possible to improve performance significantly. Along the way of implementing optimizations I have documented the complexity guarantees for all important functions of the library's interface. Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part is submitted for review: itl : Core library, interval containers, SUBMITTED FOR REVIEW Additional parts are: itl_xt : Extensions like histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. *itl* is a complete library containing all required ingredients particularly a separate test suite (NOT using LaBatea) and the quickbook documentation. The code is successfully compiled and tested with gcc-3.4.4, 4.1.0, 4.3.2 and msvc-8.0, 9.0. I have uploaded the review version as itl_3_1_0.zip to the vault in section containers. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… Another file itl_plus_3_1_0.zip contains all three parts (itl, itl_xt and validate). http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… Reviewers interested in the law based testing part may have to refer to this file to examine those tests. The law base testing examples compile and run with gcc-4.3.2, msvc-8.0 and 9.0. LaBatea does not compile with gcc-4.1.0 or older. The quickbook generated documentation is included in the zip files and is also available online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ To close my request for review, let me take the opportunity to do some advertisement ;-) focusing on some of the itl's highlights. * The Itl emerged out of real world software development extracting generic functionality from numerous use cases of the date time problem domain. (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex…) But the need for the same data structures occurs in other fields as well. E.g. Zachary Turner uses a compressed_bitmap similar to an itl::interval_set to manage very large file system allocation bitmaps and gives more use cases here (http://lists.boost.org/Archives/boost/2009/06/152817.php) * Aggregation on overlap not only provides a useful feature to compute aggregation results on interval_maps like statistics, it also leads to a generalized addition operation on maps that exhibits interesting semantical properties. E.g. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semant…) * The itl's design is based on sets of laws (aka axioms) that are described in the documentation. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semant…) These law sets not only are giving a formal specification of the library. Using the law based testing tool (LaBatea) (https://svn.boost.org/svn/boost/sandbox/itl/boost/validate) allows to validate the library code for every specified law. * For the itl, 18 laws have been validated on the 7 container templates with varying instantiation types for template parameters, running a total of 719 different law instances (each of them for large numbers of randomly generated test data). (https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/) This gives everyone a method to check semantical properties of the library in a way that is more powerful than traditional unit tests. To get the 'complete picture' of the library's interface you may want to refer to the synoptic function table first (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/in…) before looking at more specific topics. Hoping to have quickened your appetite to take a closer look at this library before and during the review process. best regards Joachim Faulhaber

6 28

Hello and a quick question.
by S. Brad Daughdrill 02 Oct '09

02 Oct '09

Hello to all, I first want to say hello to all the members. I recently ran across your project, and I am really interested in working with you all. My question is are there an example that use forms? The example I found all seem to be console applications and while they are helpful, I really want my students to start programming with forms (initially at least). They will be using Visual C++ 2008 Express. Thank you for everything ahead of time. Brad *----- S. Brad Daughdrill The University of Alabama B.S. Management Information Systems M.S. Operations/Project Management M.B.A. Financial Risk M.A. Economics (Candidate) 146 Lenora Drive Tuscaloosa, AL 35401 (o) 205.348.7591, Bidgood Hall - 351E (c) 251.510.3089 (e) S.Brad.Daughdrill(a)Gmail.com*

3 2

[rdb] 0.0.10 + documentation
by Jean-Louis Leroy 01 Oct '09

01 Oct '09

I have uploaded a new revision to the vault. The only /visible/ change in the API is the syntax for the insert...select statement. It was `insert_into(table)(cols)(select(...))`, it is now `insert_into(table)(cols).select(...). The syntax engine is beginning to look more and more like a compile-time finite state machine. And there is the beginning of a documentation ! you can view it here : http://www.yorel.be/boost/libs/rdb/doc/html/index.html The tutorial is 2/3 complete for this phase (i.e. sans prepared statements). The structure of the doc is strongly influenced by Fusion's - no wonder, I spent so much time in it ;-) While I like the overall structure, I wonder if the Fusion style is appropriate for a tool that is not so much into meta-programming (well at least on the outside). I documented insert_into in this fashion (see http://www.yorel.be/boost/libs/rdb/doc/html/rdb/sql_subsystem/statements/in…) for a test. If you have opinions, please voice them. J-L

2 2

Re: [boost] On the Road to Aspen (BoostCon 2010)
by pete＠pcbartlett.com 01 Oct '09

01 Oct '09

On Tue 29/09/09 12:22 , Joel de Guzman <joel(a)boost-consulting.com> wrote: > Edouard A. wrote: > > Hi Joel, > > > > You can also create a twitter account and link your Facebook page > to this > > twitter account, mirroring all your facebook status updates to > your twitter > > account. > > > > This increases visibility and give the possibility to your fans to > choose > > the medium they like to follow you. > Thanks, Edouard. Done. BoostCon Facebook Linked to > Twitter (@BoostCon) > http://www.twitter.com/BoostCon Many users of Boost are in corporate environments. Many corporate environments block access to Facebook and/or Twitter (mine blocks both) domains. It'd be great therefore if Boost didn't move too much content there if equivalent

4 4

Double free from UTF
by janm-boost-devel＠transactionware.com 01 Oct '09

01 Oct '09

Hi, I am seeing a double free when using boost-test on: - FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40 I don't see the problem on Windows XP with Visual C++ 2005 Express. A simple test case is below, just run. The _malloc_options is to make the system malloc() fill memory with 0xa5 on allocation and 0x5a on deallocation. #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> #include <stdlib.h> const char* _malloc_options = "J"; BOOST_AUTO_TEST_CASE(broken) { BOOST_CHECK(true); } Output: Running 1 test case... *** No errors detected zsh: bus error (core dumped) ./a.out Stack Trace: #0 0x0000000800b1bdee in free () from /lib/libc.so.7 #1 0x000000000043e51c in boost::unit_test::framework_impl::clear (this=0x55ad20) at framework.ipp:133 #2 0x000000000043e652 in ~framework_impl (this=0x55ad20) at framework.ipp:122 #3 0x00000000004110c6 in __tcf_1 () at framework.ipp:222 #4 0x0000000800b6dbb6 in __cxa_finalize () from /lib/libc.so.7 #5 0x0000000800b1f7c7 in exit () from /lib/libc.so.7 #6 0x0000000000404595 in _start () Any ideas? Thanks, Jan Mikkelsen

6 12