- Boost - lists.boost.org

Formal Review Request: Generic Geometry Library (GGL).
by Barend Gehrels 14 Oct '09

14 Oct '09

Hi, We would like to ask for a formal review for the Generic Geometry Library (GGL). The GGL defines concepts for geometries and implements some algorithms on such geometries. GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. GGL contains instantiable geometry classes, but library users can also use their own. Using registration macros or traits classes their geometries can be adapted to fulfil the GGL-concepts. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. We propose the extension model, the same way as GIL also applies it. So we are going to help to organize development of GGL extensions, where an extension is (mostly) something more specific to domains like mentioned above. The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. The last preview was in February '09. Since then the design of the library is stable and the library contains a variety of coherent functionality. So we feel that the library is matured enough for formal review. Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request We have a review manager. Regards, Barend Gehrels, Bruno Lalande, Mateusz Loskot

7 15

[test] compile-fail tests with precise output
by Jean-Louis Leroy 14 Oct '09

14 Oct '09

I would like to create tests that check, not only that a file will not compile, but that the errors contain specific strings. More precisely, I want to make sure that wrong code fails on a MPL assertion and not deep inside the template instantiations. Is that feasible? Thanks, Jean-Louis

3 2

[1.41.0] Beta planned for next week
by Beman Dawes 13 Oct '09

13 Oct '09

Looks like we are on schedule for a 1.41.0 beta next week. Now would be a good time for developers to: * Merge any stable changes from trunk to release. You can tell if there are unmerged trunk changes with the svn diff command, or use trunk/tools/release/unmerged.bat. * Check http://beta.boost.org/development/tests/release/developer/summary.html to make sure your library's tests are clean. Thanks, --Beman

2 3

Name of namespace detail
by Mateusz Loskot 13 Oct '09

13 Oct '09

Hi, Inspired by Jean-Louis question about what to put to namespace detail, I would be interested learning about rationale of name of the namespace detail (sometimes details or impl too). Recently, I've participated in a very interesting discussion, on ACCU members mailing list, about prefixes and suffixes like Base or _base nad Impl or _impl, as misused, irrelevant and confusing, meaningless, etc. For example, how to properly name elements of PIMPL idiom and similar. During the discussion I suggested that 'detail' is a good name for namespace dedicated to implementation details being not a part of public interface of a component. I got answer that it as the same issues (it's meaningless) as Impl etc. It raised some questions for myself, being interested in improving my craft, I would like to learn better about the name of namespace detail. I use detail name myself. Any better names for bucket with implementation details? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

10 20

[signals2] combiner + groups -> topmost only (missing code)
by Oliver Kowalke 13 Oct '09

13 Oct '09

Hello, I need a combiner which executes only the slots within the highest group. How to access to group in the combiner? What happens with the input iterators if signal::disconnect_all_slots() gest called within the combiner? someting like this: struct combiner { template< typename It > void operator( It i, It e) const { // iterate over slots // execute only slots of highest group } }; signal< void(), combiner, int, greater< int > > sig; sig.connect( 0, slot1); sig.connect( 1, slot2); sig(); // only slot2 gets called regards, Oliver -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

Deciding what to put in `namespace detail`
by Jean-Louis Leroy 13 Oct '09

13 Oct '09

For my future Boost.RDB submission, I feel tempted to put everything except the names that are in the public (documented) interface in a nested `namespace detail`. Why not even put *everything* there and copy selected names in the public namespace by means of using-declarations. Has it been already done ? And what about having three namespaces : a "public" one for the user, a "protected" one for those extending the lib, and a "private" one for undocumented internals? Opinions and advise welcome... J-L

3 2

Workaround request: boost::shared_ptr & Intel C++ Compiler
by Marat Abrarov 13 Oct '09

13 Oct '09

Hi! I wrote about my problem before (Boost-users Digest, Vol 2116, Issue 1: "boost::options, boost::shared_ptr with Intel C++ Compiler 11.x") but didn't received any response yet. So here's a copy: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I use boost 1.40. I have a project at http://sourceforge.net/projects/asio-samples/ (only SVN trunk is available now) It uses MS C++ Compiler (9.0 SP1 - MS Visual Studio 2008 SP1) and boost::program_options (+ boost::asio + boost::...). When I switched that project (I mean "echo_server") to Intel C++ Compiler 11.1.038 (I tried all 11.1.x) and built debug version (Debug Win32) (with addition of option /vmg to compiler command line - stupid Intel :) it works fine except shared_ptr-to-bool cast (for example: include/ma/echo/server/session_manager.hpp: 319). This issue I found only at "Debug Win32" build mode - at "Debug x64" all is fine and the built executable (echo_server.exe) works right. When I build "Release Win32" or "Release x64", the built executable don't work at all - it fails somewhere at the boost::program_options (I think at std::vector<std::string>::operator= or std::vector<std::string> copy-constructor). Does anybody: 1) tried to use boost::shared_ptr 2) tried to use boost::prorgam_options with Intel C++ Compiler 11.1.x? P.S. If I change boost_1_40_0\boost\smart_ptr\detail\operator_bool.hpp: 9 - add "|| defined (BOOST_INTEL)" - then shared_ptr-to-bool cast works fine (Win32/x64 Debug/Release) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Does anybody has similar problems with Intel C++ Compiler and boost::shared_ptr? Is anybody from boost community interested for Intel C++ Compiler support? Regards, Marat Abrarov.

1 0

[signals2] combiner + groups -> topmost only
by Oliver Kowalke 12 Oct '09

12 Oct '09

Hello, I need a combiner which executes only the slots within the highest group. How to access to group in the combiner? What happens with the input iterators if signal::disconnect_all_slots() gest called within the combiner? someting like this: struct combiner { }; -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02

1 0

[rdb] 0.1.00 - prepared statements
by Jean-Louis Leroy 11 Oct '09

11 Oct '09

I have uploaded version 0.1.0 to the vault. It introduces prepared statements and placeholders. No doc on this yet but it's easy to use, e.g. BOOST_AUTO(st, db.prepare(insert_into(p)(p.id, p.first_name, p.name, p.age).values(_, _, _, _))); st.execute(3, "Bart", "Simpson", 9); st.execute(4, "Lisa", "Simpson", 7); st.execute(5, "Maggie", "Simpson", 0); It also works with update, delete and select. Placeholders are allowed in predicates as well. Parameters are type-safe, if they don't agree with the type of their corresponding placeholder (as deduced by the context in which it is used), you will get a compilation error. More examples in the test file here : http://code.google.com/p/boost-rdb/source/browse/libs/rdb/test/test_odbc.cpp J-L

1 0

[wave] 1.40.0 build problem on recent intel
by troy d. straszheim 10 Oct '09

10 Oct '09

Over on the boost-cmake Justin Holewinski pointed out that wave doesn't build on recent intel compilers. Details and fix here: http://software.intel.com/en-us/articles/error-409-when-building-boost-libr… -t

2 1