October 2009 - Boost - lists.preview.boost.org

[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

Re: [boost] threads: how to remotely kill a thread?
by David M. Cotter 10 Oct '09

10 Oct '09

yes i have seen the error of my ways, and am now using thread.interrupt () and i sprinkle interruption_point() in my inner loops of the thread thanks for the feedback. -dave On Oct 9, 2009, at 9:20 PM, Yigong Liu wrote: > It is kind of dangerous for one thread to kill another thread > forcefully or directly, since the 2nd thread may be in the middle of > holding a system resource or changing some state. Killing it may > left the system in corrupted state. better using "cooperative" > shutdown, the 1st thread sends the 2nd thread some notification, > either thru shared state or interrupt. For similar reasons, java > deprecated many thread api (http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.h… > ). > > On Fri, Oct 2, 2009 at 9:16 AM, Andrey Semashev <andrey.semashev(a)gmail.com > > wrote: > David M. Cotter wrote: > say i'm on the main thread, and i've got a thread::id of some other > preemptive thread. i do not have the actual boost::thread object > any more. > > and i want to unceremoniously kill that thread. like right now. > > how do i kill it? i don't see a way to recover the actual > boost::thread from the thread::id. but even if i could, and then > call thread.interrupt(), that's more of a polite request which is > free to be ignored, rather than a you_must_die_now() thing. > > The main problem with killing threads is that it doesn't unwind the > stack and thus breaks RAII. Therefore the best "official" way to > terminate the thread in C++ is to interrupt it. If you want to do it > the hard way, you're in C world with pthread_kill and alikes.

1 0

[fusion] accumulate vs. std::accumulate
by Christoph Heindl 10 Oct '09

10 Oct '09

Hi, I'm currently confronted with an issue raised before [1] on this list: boost::fusion::accumulate takes its arguments in reverse order compared to std::accumulate. The issue is still marked as 'new' on trac [2]. What are the chances to have this issue fixed for the next release? Kind regards, Christoph [1] http://lists.boost.org/Archives/boost/2008/09/142490.php [2] https://svn.boost.org/trac/boost/ticket/2355

1 0