September 2009 - Boost - lists.boost.org

[BGL] read_graphviz()/read_graphml() and subgraphs
by Giuseppe Di Guglielmo 24 Sep '09

24 Sep '09

Dear all, I read on the 'read_graphviz()' page in BGL library doc http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/read_graphviz.html * read_graphviz treats subgraphs as syntactic sugar. It does not reflect subgraphs as actual entities in the BGL. Rather, they are used to shorten some edge definitions as well as to give a subset of all nodes or edges certain properties. For example, the DOT graphs digraph { a -> subgraph {b -> c} -> e } and digraph { a -> b -> e ; a -> c -> e ; b -> c} are equivalent. Is this actually true? Can I read sub-graph from DOT description and obtain a subgraph object? http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/subgraph.html Eventually are subgraph supported by 'read_graphml()' function? http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/read_graphml.html Thanks, G.

1 0

[multi_index] Missing mutex lock?
by Anatoly Pinchuk 23 Sep '09

23 Sep '09

Possible traversal and modifications of a safe container iterators list inside safe_mode::detach_equivalent_iterators function are not protected with locking like the following one in safe_iterator_base::detach function. #if defined(BOOST_HAS_THREADS) boost::detail::lightweight_mutex::scoped_lock lock(cont->mutex); #endif Unless some kind of synchronization is provided by callers of the safe_mode API, the list above can be traversed/modified and modified concurrently in BOOST_HAS_THREADS environment. It would be great if somebody can confirm or deny that there is the access synchronization problem. Regards, Anatoly

3 5

Re: [boost] scoped_ptr deleter
by Berserker 22 Sep '09

22 Sep '09

Stewart, Robert wrote: > That change creates multiple, distinct classes. > shared_ptr<T,boost::checked_deleter<T>> is not the same as shared_ptr<T,my_deleter<T>>. > By embedding the deleter in the shared_ptr with type erasure, > shared_ptr<T> is shared_ptr<T> is shared_ptr<T>, regardless of the deleter. Sure and that's the point :) As I wrote, since the "noncopyable nature" of scoped_ptr (shared_ptr is copiable by design), the creation of distinct classes isn't a problem. I think that the "real problem" here is to provide a solution that doesn't require extra memory overhead. _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

9 24

Re: [boost] [Boost-users] Parallel BGL status in Boost
by Craig Henderson 22 Sep '09

22 Sep '09

> Nick Edmonds wrote: > >> On Sat, Sep 12, 2009 at 9:42 PM, Nick Edmonds > <ngedmond(a)cs.indiana.edu> wrote: > >> > >>> yet). There's also a very nascent project to do multi-core/highly > >>> multi-threaded BGL, starting from the BGL sources as opposed to > PBGL. > >> > >> Any pointers ? It would be nice if they look at using the map-reduce > >> library (boost candidate) > >> > > It's very early stages so no, no docs/code yet, it's basically some > new PhD students in my lab with me and another post-doc mentoring > them. I would anticipate that map-reduce is too > coarse-grained/BSP-like to capture the fine grained dependencies we > need to capture to get good performance in a memory-bandwidth bound > domain like sparse graphs, but I'll mention it and see if they want to > write a sample algorithm with it and run some numbers. We're > investigating a few different options for organizing/parallelizing the > work, including starting from scratch. > > It would be nice to see how the map-reduce library performs though. > Do you have any performance data for using it on highly multi-threaded > architectures (Sun Niagara, Cray XMT, anything with >8 cores really)? > Hi Nick, the Map/Reduce library is available in the sandbox and in the vault. The performance is as much down to the implementation of the map and reduce tasks as the framework itself. Jose has compared performance of my library with Standford University's Pheonix implementation and the performance is comparable (http://lists.boost.org/Archives/boost/2009/08/155759.php) I have tested the library on MS Windows on servers with 16-cores and performance has scaled well - if you get the input's segregated sufficiently to avoid contention. I don't yet have any benchmarks, but am looking for some suitable algorithms if you're interested in contributing. Regards -- Craig

1 0

Creating a new toolset for System i *SRVPGMs
by Jon Brisbin 22 Sep '09

22 Sep '09

We're integrating our C++ development with our RPG/400 development and since we use Boost on the PC end, we'd really like to use Boost on the AS400/System i integration stuff. I can successfully compile service programs on the 400 that use boost header-only libraries (with some minor tweaking of the Boost source...I'm finding various things that have to be changed to accommodate the 400 compiler) using the "ixlc" compiler. I think what I need to do to use Boost.Build on the 400 is to create a new toolset that is like gcc, but uses the "ixlc" and "ixlclink" commands to compile *MODULEs and *SRVPGMs. I'm just not familiar enough with Boost.Build to figure out how to do this. I'm actually a Java programmer and not even very experienced in C++, though I've been a unix geek for a long time, so I'm very familiar with the build tools. Since the library/file(member) convention of working with these files on the 400 doesn't translate directly across to files on a unix-like filesystem, I'm thinking I'll have to have directories that correspond to libraries and the source file basename that corresponds to the object name. For example, source file: cpplib/mycpptest.cpp would be compiled using "ixlc" like: ixlc -ocpplib/mycpptest -qdbgview=all -qprint (other options) cpplib/ mycpptest.cpp this would create a *MODULE object called "MYCPPTEST" in library "CPPLIB". How would I translate this to a boost build toolset that I could use by writing a Jamfile like the following...? module cpplib/mycpptest : cpplib/mycpptest.cpp ; srvpgm cpplib/mycpptest : cpplib/mycpptest cpplib/myothrmod ; at some point, I'd probably like to specify a default library, but I can probably do that by using variables in my project's root file. Can anyone help me with this, even though you may not have direct experience with the AS400 (it would be great if there were boost developers who worked on or with 400's, though! ;)? Jon Brisbin Portal Webmaster NPC International, Inc.

1 0

[serialization] serialize shared_from_this() pointer
by Zoran Cvetkov 22 Sep '09

22 Sep '09

Does someone have experience serializing a class that inherits from a shared_from_this() pointer? If I just do nothing I am getting 0 pointer during deserialization. What would be the proper syntax for serializing it, if it's needed?

1 0

review request: addition to type_traits library of is_less_comparable<T> and others
by Frédéric Bron 22 Sep '09

22 Sep '09

Hi folks, I would like to propose to your review the following addition to the type_traits library. The addition is attached to this email and also available in the sandbox at https://svn.boost.org/trac/boost/browser/sandbox/type_traits The purpose of the addition is to add type traits to detect if type T is comparable in the sens of <, <=, >, >=, == or != operators, i.e. if t1<t2 has a sens when t1 and t2 are of type T (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T> is_greater_comparable<T> is_greater_equal_comparable<T> is_less_comparable<T> is_less_equal_comparable<T> is_not_equal_to_comparable<T> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The compilation has been tested with g++ 4.3.2 and icpc 10.0 on linux 64 bits, g++ 3.4.4 on cygwin, mingw32 3.4.4 on cygwin. I must add that I did not invent the code (I obtained some help from the boost mailing list) but I put it together in a form that should be acceptable to boost. Regards, Frédéric

8 23

Possible submission: Dynamic library policy loading library?
by Rob Meijer 22 Sep '09

22 Sep '09

In the Open Computer Forensics Architecture library ( http://sourceforge.net/projects/ocfa/ ), a simple template sub library is used for policy loading with shared libraries. This stuff is currently buried in a large library, and it would seem prety usefull to extract this sub library into an enviroment (like boost) where it can be used within a wider scope. To show apptoximately how this sub library is used, I've taken a few lines from a part of OcfaLib that uses this functionality: The below example is used to load an implementation of the abstract TreeGraphFactory class within a loadable library "libtesttreegraph.so" with a constructor function named "constructor" in it. std::string module="testtreegraph"; //Define a type for the constructor. typedef SinglePointerConstructor< TreeGraphFactory, std::map< std::string,misc::Scalar > > CTreegraphType; //Define a type for the policy loader. typedef PolicyLoader<CTreegraphType> PLTreeGraph; //Create a new policy loader object for a given module and constructor function name. PLTreeGraph *mPolicyLoader=new PolicyLoader<CTreegraphType>(module,"constructor"); //Fetch the constructor from the policy loader. CTreegraphType *constructor = mPolicyLoader->constructor(); //Construct an object using the constructor TreeGraphFactory * mActiveFileSystem =(*constructor)(attributes); For more info, the relevant headers in the ocfa source tree are: OcfaLib/inc/misc/PolicyLoader.hpp OcfaLib/inc/misc/VoidToFunction.hpp It probably needs some work on portability and needs more constuctor templates to be fully generically usable, but I feel this has the potential to be a very usefull extention to boost. Do you people feel this should be further explored and submitted as a possible extension for boost? Rob

1 0

Feed pointers to a container, however use the member of the data type which pointer refer to
by 路邓 22 Sep '09

22 Sep '09

Dear All: In the following codes, I feed the container with B*, however I user the member of B as the index. Can somebody explain to me how this work out? And It seems that if smart pointers are feeded into the container, it still works out. #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> #include <iostream> using namespace boost::multi_index; class B { public: int idx; }; typedef boost::multi_index_container< B*, indexed_by< ordered_unique< BOOST_MULTI_INDEX_MEMBER(B, int, idx) > > >Container; int main() { Container container; B* p1 = new B; B* p2 = new B; p1->idx = 2; p2->idx = 1; container.insert(p1); container.insert(p2); Container::iterator iter; for(iter=container.begin();iter!=container.end();iter++) { B* tmp = (*iter); std::cout << tmp->idx << std::endl; } return 0; } ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

2 1

Feed pointers to a container, however use the member of the data type which pointer refer to as an index
by 路邓 22 Sep '09

22 Sep '09

Dear All: In the following codes, I feed the container with B*, however I user the member of B as the index. Can somebody explain to me how this work out? And It seems that if smart pointers are feeded into the container, it still works out. #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> #include <iostream> using namespace boost::multi_index; class B { public: int idx; }; typedef boost::multi_index_container< B*, indexed_by< ordered_unique< BOOST_MULTI_INDEX_MEMBER(B, int, idx) > > >Container; int main() { Container container; B* p1 = new B; B* p2 = new B; p1->idx = 2; p2->idx = 1; container.insert(p1); container.insert(p2); Container::iterator iter; for(iter=container.begin();iter!=container.end();iter++) { B* tmp = (*iter); std::cout << tmp->idx << std::endl; } return 0; } 好玩贺卡等你发，邮箱贺卡全新上线！ ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

1 0

[variant]anyone working on variadic template version?
by Larry Evans 22 Sep '09

22 Sep '09

Is anyone working on a variadic template version of variant, i.e. one that defined as: template<typename... T>class variant; instead of: template < typename T0 = detail::variant::void_ , typename T1 = detail::variant::void_ ... , typename T19 = detail::variant::void_ > class variant; ? I'm thinking of attempting that, but I'd hate to waste time if someone else has already done it or made some progress on it. Although BoostCon09 did have a workshop on CXX0x: http://www.boostcon.com/community/wiki/show/Start/HandsOnCXX0x/ the sandbox directory for that: https://svn.boost.org/svn/boost/sandbox/boost0x didn't appear to use the variadic template feature in variant: https://svn.boost.org/svn/boost/sandbox/boost0x/boost/variant/variant_fwd.h… TIA. -regards, Larry

3 6

[rdb] 0.04
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

I have uploaded a new version of my relational database library to the vault. It implements the ideas I described in another thread. This time it even puts things in a real (odbc) database and retrieves them. I see that 12 have downloaded the previous versions. If you have time please send me feedback. Have you been able to compile it ? Has anybody tried on Unix or with other compilers ? Please note: * It's a work in progress ; for the curious only. * I develop on Windows with Visual Studio Express 2008. There is a solution file in the msvc dir. Nothing bjam works yet. * Currently the doc is the test suite Jean-Louis Leroy

3 8

[rdb] 0.05 - also a fusion problem
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

This upload is mostly for fixing an embarassing bug that the test suite would have detected if I had not put a "return 0" in the middle of it. In addition I have restructured the tests into suites and cases. Jam files begin to work, at least they allow me to build with bjam from the boost tree. While I'm at it, here's the bug, in case somebody has an idea. I have to initially create my fusion::list's of expressions and tables with `push_back(list<>(), val)' instead of just `make_list(val)', otherwise I get access violations. I see in the debugger that the first element of my list is damaged during the next function call, most probably because a reference to a temporary was created along the way. Has anybody had this kind of problem ? I use boost 1.39. J-L

1 0

Problems testing compiling on AS400/i5/whatever
by Jon Brisbin 21 Sep '09

21 Sep '09

I'm using the QSH environment on AS400 and the "ixlc" compiler (basically just CRTCPPMOD), trying to compile the following test program: #include <iostream> #include <boost/foreach.hpp> int main(int argc, char** argv) { std::string hello = "Hello, world!"; BOOST_FOREACH( char ch, hello ) { std::cout << ch << std::endl; } return (EXIT_SUCCESS); } Which results in the following errors: The compilation failed. /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000054 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 54.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const>" is alread ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000055 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 55.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* volatile>" is alr ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000056 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 56.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const volatile>" ERROR 1 001 2 000051 The full text of the error complains that these are already defined. Does anyone have pointers or tricks that could point me in the right direction to compile programs that use header-only Boost libs on the AS400? Any help would be appreciated! :) Jon Brisbin Portal Webmaster NPC International, Inc.

1 0

[PBGL] and [MTGL]
by Cosimo Calabrese 21 Sep '09

21 Sep '09

Hi to all, I open this discussion as a "branch" of "[BGL] Multithread problem inserting edges and exploring the same graph". Can someone tell me if the PBGL and MTGL can help me? I report my problem below, for sake of comfort. Thanks in advance, Cosimo Calabrese. ************************************************** 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. [...] **************************************************

2 1

Python 3 support has landed on boost trunk
by Stefan Seefeld 21 Sep '09

21 Sep '09

Hi there, as some of you may know, Haoyu Bai has worked over the summer on Python 3 support for Boost.Python. This work happened on a branch, which I merged back into trunk last night. Now we need to set up testers to run the testsuite with some Python 3 variant, as that is a new platform to track. I will see whether I can set one up on one of my machines. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[filesystem] Compatibility with STLPort
by Andrey Semashev 21 Sep '09

21 Sep '09

Hi, I've created ticket #3241 some time ago, with a patch attached. It's about Boost.Filesystem compatibility with STLPort expression templates feature. So far no activity has appeared on it, although the fix is trivial. Is it OK if I go ahead and commit the patch? PS: Ticket URL is https://svn.boost.org/trac/boost/ticket/3241

3 6

unsigned long vs unsigned int vs std::size_t (32b platform)
by Christoph Mathys 21 Sep '09

21 Sep '09

Hello! First: I'm working on 32b Linux (gcc 4.2.4) and 32b XP (Visual Studio 9 SP1). I tried to switch from stdint.h to boost/cstdint.hpp, but had to find out that this is not as straight forward as I thought. The compilers handle 'unsigned int' and 'unsigned long' as different types, even though on 32b it is AFAIK the same type. This by itself is OK, but gcc and VS9 seem to disagree in where it comes to defining std::size_t. The result is that the code at the end compiles on visual studio, but not on gcc: asdf.cpp: In function ‘void someFunc(size_t)’: asdf.cpp:6: error: redefinition of ‘void someFunc(size_t)’ asdf.cpp:5: error: ‘void someFunc(uint32_t)’ previously defined here asdf.cpp: In function ‘int main(int, char**)’: asdf.cpp:16: error: call of overloaded ‘someFunc(long unsigned int&)’ is ambiguous asdf.cpp:4: note: candidates are: void someFunc(uint16_t) asdf.cpp:5: note: void someFunc(uint32_t) In the stdint.h we used for visual studio previously, this error did not occur because uint32_t was typedefd to 'unsigned __int32'. Now, the questions are: - should boost::uint32_t be typedefed to the same thing that std::size_t is on 32b platforms? - Is the size of std::size_t fixed or dependant on the platform it is used on? - Did I do something wrong and there is a much better way of doing it avoiding those problems in the first place? #include <boost/static_assert.hpp> #include <boost/cstdint.hpp> void someFunc(boost::uint16_t) { } void someFunc(boost::uint32_t) { } void someFunc(std::size_t) { } int main(int, char**) { BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (unsigned int)); BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (std::size_t)); unsigned long ul = 42; unsigned int ui = 1337; std::size_t st = 2; someFunc(ul); someFunc(ui); someFunc(st); return 0; }

5 7

[repost][multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 21 Sep '09

21 Sep '09

Hi, my first attempt went unanswered, reposting in the hope it'll bring more attention this time around: Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2 ) What I find weird is the throwing of invalid_signature, a Boost.Serialization exception that, according to docs, indicates that the beginning of a serialization file is not correct. I can't see how a problem with serializing multi_index_containers can lead to a file signature error. Any clue? Maybe the toolset maintainer can run this manually and provide more info? Thank you in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Foreach] Proposal to simplify using Boost.Foreach with maps
by Chris Purcell 20 Sep '09

20 Sep '09

As documented in the manual ("Pitfalls"), BOOST_FOREACH is a little awkward to use with associative containers. I've used the following in the past to simplify my own code, and wondered if it was suitable to add to the Boost Foreach library proper. std::map<int, int> my_map; BOOST_FOREACH_PAIR(int key, int value, my_map) std::cout << key << " : " << value << "\n"; The BOOST_FOREACH_PAIR macro is a clone of the BOOST_FOREACH macro with an extra for loop in it to assign both first and second from each pair in the map. If either is not wanted, ignore from Boost.Tuples can be used: std::vector<int> values; BOOST_FOREACH(boost::tuples::ignore, int value, my_map) values.push_back(value); References can be used just as with BOOST_FOREACH, to create a modifying loop: BOOST_FOREACH_PAIR(int key, int& value, my_map) value += key; There are a few alternatives to my solution that I have seen: (1) Predeclare a pair and use it each time around the loop: std::pair<int, int> kv; BOOST_FOREACH(kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This adds overhead from copying pairs, and does not give meaningful names to the two halves of the pair. It also has no simple extension to a mutating loop that I am aware of. (2) Typedef the value type of the map before the loop, and use .first and .second: typedef std::pair<const int, int> KeyValue; BOOST_FOREACH(KeyValue const& kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This removes the copying overhead, and is easy to change to a mutating loop, but still does not meaningfully name the key and value (3) Use Boost.Tuple's tie to turn the single assignment of BOOST_FOREACH into a double assignment: int key, value; BOOST_FOREACH(boost::tie(key, value), my_map) std::cout << key << " : " << value << "\n" This gives meaningful names, but has copying overhead (albeit not in this simple example). It also has no simple extension to a mutating loop that I am aware of. The key objection to all of these alternatives, from my point of view, is simply that they are unnecessarily complicated. The new macro is much cleaner. Implementation of BOOST_FOREACH_PAIR is simple: turn the innermost assignment loop of BOOST_FOREACH into a pair of loops, one assigning key, one value. Cheers, Chris Purcell

6 11

[polygon] late review
by Gordon Woodhull 20 Sep '09

20 Sep '09

Hi all, Sorry this is late - I intended to participate in the discussion, but the review schedule happened to intersect with an offline vacation. (Plus day job, school starting, etc.) Thank you, Luke, for submitting what I think is a very good start toward a Boost geometry library. I do not think the library is ready for inclusion in Boost at this time, but I believe it will be with further improvements. I would almost vote for acceptance with conditions, but the list is long and I think the concepts merit more discussion. Unfortunately I have not had time to take an in-depth look at the library; I have read some of the documentation and examples and it looks useable. So this is mostly a non-technical review of the issues raised by others. Also I offer a bit of "meta-review" of the review process for libraries that will continue to evolve and merge with other libraries. My application domain is mainly graph drawing (network visualization) but I might also use this in 2D screen graphics and games. For these purposes, the restriction to two dimensions is acceptable, and even the restriction to integer coordinates is mostly acceptable. However, I think the library name should reflect these restrictions. It will be some time (if ever) before a library can claim to be The geometry or polygon library. Boost has no merge process (if that's even possible), and neither Polygon nor GGL subsumes the other, so I think they should eventually be accepted in parallel, and merge concepts and algorithms over time. As I see it, this library provides two major contributions: 1. A set of concepts for VLSI and other 45/90 degree applications which can in the future be extended or bridged to other geometric problem domains, e.g. GIS, 3D, n-dimensional. 2. An extremely robust and (I believe) efficient polygon intersection algorithm. The interface still needs some work, but the concepts are a valuable first pass at defining this domain. I want to see some system of libraries that supports rectangles through arcs all the way up to splinegons. This isn't that, but I am patient. I will be interested to compare the advantages of concepts for polygons with holes versus the runtime version in GGL. I don't agree that accepting a library where the concepts/interface are incomplete or even wrong will pollute a future generalized geometry library. This library will just have to improved over time, and influenced by libraries from other domains. To mention just one specific interface problem: I don't like rect - int meaning shrink the rectangle. I think that everyone is going to have strong opinions about what operators they like and dislike and I hope that some future geometry library will allow choosing different sets for different domains. The intersection algorithm is very, very cool and I hope the ideas can be extended someday by someone to provide robust intersection of arcs and splines. I don't yet understand whether this is possible. I agree with those who would like to see lazier evaluation to run the intersection algorithm on as much as possible. Luke and Barend, I'm sorry but I don't believe either of your benchmarks. I think you are choosing problems that suit each of your libraries. This is understandable, but we will need to build a comprehensive suite of examples from many different domains to learn which algorithms are actually faster in which situations. Meta-review I admire the Boost process for protecting authorial control over libraries. However, one consequence is that two very important requirements, maintenance and cooperation, are only ensured indirectly by vigorous debate. 1. Maintenance. This is not really addressed by the Boost rules or review process, except to remind authors that they will be responsible for maintenance or for finding a new maintainer. There is no way to compel authors to respond to their users except for the threat of library removal which IIUC has almost never happened. So one of my essential criteria in reviewing a library - I've only reviewed one other library but followed many other reviews closely - is the attitude of the author toward changes requested. Users are inevitably going to have new requirements. Luke definitely seems willing to make the changes that are needed to get this into Boost, and I trust that he'll continue to help it adapt. I am slightly concerned that Intel will not allow the library to depend on Boost because I think that will slow down improvement. In particular I think operator customization and lazy evaluation would be helped by using Proto. I hope Intel will allow this. Or maybe that's the scope of a different library. 2. Cooperation. Boost has no rules or process for making libraries work together, never mind merging them. Maybe there is some work to be done here. But people will naturally want to make their libraries compatible if they're under the same umbrella. Competition is also a healthy human drive, but it's especially productive when there is some basis of cooperation, as I think there is between Luke and Barend, despite how nerves may have frayed during this review. I hope that both libraries are accepted, when ready, and that the authors and others interested in a "universal" Boost geometry library work to find the commonalities and connections. Fervently waiting, Gordon

2 2

Formal Review: Boost.Polygon starts today August 24, 2009
by Fernando Cacciola 20 Sep '09

20 Sep '09

Dear Developers, The formal review of the Boost.Polygon library by Lucanus Simonson starts today, August 24, 2009 and will finish September 2, 2009. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The boost polygon library provides algorithms focused on manipulating planar polygon geometry data. Specific algorithms provided are the polygon set operations (intersection, union, difference, disjoint-union) and related algorithms such as polygon connectivity graph extraction, offsetting and map-overlay. These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library. The polygon library is not intended to cover all of computational geometry in its scope, and provides a set of capabilities for working with coordinates, points, intervals and rectangles that are needed to support implementing and interacting with polygon data structures and algorithms. Specifically, 3d and non-Cartesian/non-planar geometry is outside of the scope of the polygon library The design philosophy behind the polygon library was to create an API for invoking the library algorithms it provides on user geometry data types that is maximally intuitive, minimally error-prone and easy to integrate into pre-existing applications. C++-concepts based template meta-programming combined with generic operator overloading meets these design goals without sacrificing the runtime or memory efficiency of the underlying algorithms. This API makes the following code snippet that operates on non-library geometry types possible: void foo(list<CPolygon>& result, const list<CPolygon>& a, const list<CPolygon>& b, int deflateValue) { CBoundingBox domainExtent; using namespace boost::polygon::operators; boost::polygon::extents(domainExtent, a); result += (b & domainExtent) ^ (a - deflateValue); } The source is available at http://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Best Regards Fernando Cacciola Review Manager

30 142

SQL client library ?
by Jean-Louis Leroy 19 Sep '09

19 Sep '09

What's the situation with SQL client libraries (similar to Rogue Wave's DBTools.h++) ? I know that there's a boost_sql_cli in the Vault, but it doesn't seem to make much progress. I have also heard about plans to bring Soci into Boost. Thanks, Jean-Louis

19 42

Error building Boost.MPI on WinXP with MPICH2
by Craig Henderson 19 Sep '09

19 Sep '09

I am trying to build Boost.MPI for the first time. I've downloaded and installed MPICH2 on my Windows XP machine, and added "using mpi ;" to tools/build/v2/user-config.jam file, and the mpich2/bin to the path. When I run bjam, I get the following output. ------------------------------------------------------ C:\root\Development\Library\Boost\boost_1_39_0>..\bjam --with-mpi The system cannot find the path specified. The system cannot find the path specified. The system cannot find the path specified. MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. WARNING: No python installation configured and autoconfiguration failed. See http://www.boost.org/libs/python/doc/building.html for configuration instructions or pass --without-python to suppress this message and silently skip all Boost.Python targets Building C++ Boost. ------------------------------------------------------ The environment runs for building all other Boost libraries. Any ideas what's wrong or how to diagnose the problem? Thanks -- Craig Craig Henderson http://www.craighenderson.co.uk http://www.siteupdatenotification.com

1 0

cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime
by Dave Steffen 19 Sep '09

19 Sep '09

Hi Folks [ Sorry if this gets posted twice; my company email server changed my email address, and I think my first post got bounced. Argh.] Just tried to compile my project with GCC 4.3 and Boost 1.40. (It compiles and works just fine with Boost 1.38.) As part of a home-built thread-locking shared pointer thing, we have this code: /// Constructor from pointer to complete type template<class Y> explicit shared_locking_ptr( Y * p ): px( p ), pn( p ) // Y must be complete { boost::detail::sp_enable_shared_from_this( pn, p, p ); } which now produces this result: ../util/thread/shared_locking_ptr.hpp:57:9: warning: cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime In Boost 1.38, the relevent code in shared_ptr.hpp was this AFAICT: #ifdef _MANAGED [ ... ] #else // _MANAGED [...] inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } #endif // _MANAGED In 1.40, it's been changed to #ifdef _MANAGED [...] #else // _MANAGED inline void sp_enable_shared_from_this( ... ) { } #endif // _MANAGED Does anyone know why the change? Has anybody else seen this problem? It seems to me that GCC is correct, and that although it's an empty function so it doesn't matter anyway, the earlier version is preferable. Alternately, does anyone know of a way to silence GCC's warning? -- Dave Steffen, Ph.D - Software Engineer Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 direct (970) 612-2327 fax (970) 461-2004 Email: dave.steffen(a)numerica.us

4 4