September 2005 - Boost - lists.boost.org

Boost.Python and slightly more tricky inheritance
by Vladimir Pozdyayev 05 Sep '05

05 Sep '05

Greetings. 1. First, about a bug (Boost 1.33.0, MSVC 7.1): After exporting void test1( const char * ) { } void test2( std::string ) { } we get an assertion failure _BLOCK_TYPE_IS_VALID( ... ) on std::strings longer than a dozen of characters: test1( 'hello' ) # OK test2( 'hello' ) # OK test1( 'how do you do, tell me please' ) # OK test2( 'how do you do, tell me please' ) # failure 2a. From `Exposing Classes' tutorial section: "If Base is polymorphic, Derived objects which have been passed to Python via a pointer or reference to Base can be passed where a pointer or reference to Derived is expected." Now, that's a great feature, but I couldn't help noticing that what Boost.Python actually does, is even more useful: not only such pointers can be passed instead of Derived ones, but their Python counterparts _are_ fully qualified Derived representations, with all the methods and everything. Probably worth mentioning in dox that way. 2b. Now, suppose we have one more derived class: class Base { ... }; class Derived: public Base { ... }; class HiddenImplementation: public Derived { ... }; with Derived being no more than an interface. Naturally, we don't want to export HiddenImplementation to Python, but still want to retain automatic conversions from Base* to Derived* whenever pointer to HiddenImplementation object is passed to Python. Any way to do this? Without hack-ins? I was able to trick the system by defining the fake empty implemetation class class HiddenImplementation: public Derived { }; right before the BOOST_PYTHON_MODULE and exporting it out there, but this kind of `solution' really annoys me. And I don't understand why it works, either :) . Oh, and it's only a partial solution, too: we do not have to access the real implementation class, but we still have to export something. Comments? -- TIA, Vladimir mailto:ardatur@mail.ru

3 6

[metamath] Plans for compile time double
by Chris Weed 05 Sep '05

05 Sep '05

Hi, I was wonder what the plans are for the compile time double library, metamath. Is there a plan to develop compile time versions of the functions in math.h, such as sin, cos, pow, abs, etc.? Thanks, Chris

3 7

C++ Committee pre-meeting papers available
by Beman Dawes 05 Sep '05

05 Sep '05

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/#mailing2005-08 There are several proposals for TR2 additions based on Boost libraries. Filesystem, Interval Arithmetic, Range, String Algorithms, Optional, Numeric Conversion, etc. --Beman

5 6

Boost regression notification (2005-09-04 [HEAD])
by Douglas Gregor 05 Sep '05

05 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-04T05:02:17Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 88 failures in 12 libraries: foreach (6) graph (4) math (6) mpl (2) multi_index (5) parameter (4) serialization (40) spirit (2) thread (9) type_traits (2) typeof (4) wave (4) |foreach| user_defined: cw-8_3 cw-9_4 msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |multi_index| test_capacity: gcc-4_0-darwin test_list_ops: gcc-4_0-darwin test_modifiers: gcc-4_0-darwin test_safe_mode: gcc-4_0-darwin test_update: gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux vc-7_1 test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |type_traits| add_const_test: vc-7_1 add_volatile_test: vc-7_1 |typeof| type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

2 1

Re: [boost] another question about asio
by Roland Schwarz 05 Sep '05

05 Sep '05

Sorry for quoting that much, but I am moving a private conversation back to the list. The question was about a small test: int main() { asio::demuxer d; { printer p(d); } d.run(); return 0; } which exited with access violation, and I wanted to know whether cancelation in the destructor would help. Christopher Kohlhoff schrieb: >--- Roland Schwarz <roland.schwarz(a)chello.at> wrote: > > >>I you prefer and if you think others also could benefit from my >>questions, I also can continue on the list. >> >> > >I don't mind either way :) > > > >>So embedding the cancel into printers destructor would help? >> >> > >No, that's not actually the problem. In fact, the deadline_timer >destructor already cancels the operation. > >The problem is that the completion handler (whether cancelled or not) >won't get called until inside demuxer::run() (that's a guarantee that >asio makes). Since the handler refers to the printer object you will >have a problem if the printer is destroyed before the handler gets a >chance to run. > >Basically you must ensure that any object referred to by a completion >handler is alive until the handler is called. > > > >>I assume your asio library is made up along the reactor pattern isn't >>it? >> >> > >No, it's more like proactor (and the win32 implementation uses IO >completion ports for most socket operations). > > > >>What I alsways tried to find out how a reactor is meant to be >>shutdown. Can you shed some light on this? >> >> > >The demuxer shuts down (i.e. the demuxer::run function exits) when >there is no more work to do. "Work" means unfinished asynchronous >operations. > >The cleanest way to shut down an app (unfortunately not shown in any of >my current examples yet) is to cancel all of your operations. The >completion handlers for those operations will be called with an error >code result, and once they have all finished the run() will exit. > > > >>So does the cancel call give me this guarantee? What if another >>callback is scheduled in midst of cancellation? >> >> > >As i mentioned above, cancel doesn't cause the callback to be invoked >immediately. It just causes the operation to finish early, with an >error code. > >There is no problem with callbacks running while doing a cancellation, >provided you respect thread safety rules (e.g. do not access a timer >object from multiple threads simultaneously). > > > >>I hope you don't mind if I put another few lines: >> >>As many others on the list I am eagerly looking to a network library. >>And I like asio as I can tell so far. >> >>But I have a basic question that bothers me: >>Will it be compatible with >>boost::mutex and boost::conditions? >>I.e.: Can I wait on networking events _and_ some conditions >>the same time? >> >> > >This is perhaps an area that needs more investigation. However, in my >and others' experience with asio, once an application is designed to >use an asynchronous programming paradigm, it often has no more need for >mutexes or condition variables at all! > >Instead, everything can be accomplished using a combination of async >operations, demuxer::post() and locking_dispatcher to synchronise >handlers across threads. This is more like a message passing style of >programming. > > > So basically the asio also needs a change in paradigm? It won't be of much use in the traditional threading sense? Regards, Roland

2 1

[Everyone!] VC 7.1: "'detail' : ambiguous symbol"
by Douglas Gregor 05 Sep '05

05 Sep '05

I've been doing battle with VC 7.1 and its "'detail' : ambiguous symbol" error messages for a while. The basic problem is that we have a file with, essentially, "using namespace boost; using namespace boost::spirit;" in it. Since VC 7.1 resolves namespace names a bit strangely, these using directives end up being resolved late in the compilation process, so they make lookups of names like "detail" ambiguous. The most recent of these problems shows up here: http://tinyurl.com/a4d6p Using directives from some Graph code that #includes spirit and shared_ptr has the using directives I mentioned above. All should be well, but somehow VC 7.1 is using these directives later on, so shared_ptr's reference to "detail::" becomes ambiguous. I've been whacking these problems by providing full qualification (::boost::detail) where it concerns my libraries, but now that it's hit shared_ptr I think we might need to fix this another way. A few options come to mind: 1) Make me fix the graph library with a bunch of using declarations instead of the blanket "using namespace boost::spirit;" that causes the problem. But, users might still run into this issue. 2) Keep on qualifying "detail" references until it stops causing problems 3) Stop using "detail" and instead use "[lib]_detail" that is different for each lib. Preferences? Doug

4 3

Boost regression notification (2005-09-04 [RC_1_33_0])
by Douglas Gregor 04 Sep '05

04 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (building archive index, done in approximately 5 seconds), please wait...</p> </body> </html>

2 2

Re: [boost] [intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADLand__EDG_ VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Domingo, Septiembre 4, 2005 11:18 am Asunto: Re: [boost] [intel-9.0] --arg_dep_lookup,BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADLand__EDG_ VERSION__=304 > > John, it'd be great if this change is also merged > > to the RC_1_33_0 branch for the 1.33.1 release. > > I believe it should be already? Well, that's no what I see: MAIN branch: http://tinyurl.com/dxxev RC_1_33_0 branch: http://tinyurl.com/9mjlj ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[range] Documentation errors
by Matthias Troyer 04 Sep '05

04 Sep '05

Hi Thorsten, Reading through the Boost.Range documentation in libs/range/doc/ range.html I consistently found refernces to rboost::begin and rboost::end. Since I don't think we have a reverse Boost yet :-) I believe these should be spelled boost::rbegin and boost::rend? Matthias

2 1

[intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL and __EDG_VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

A bit of context: * Intel 9.0 has __EDG_VERSION__==304 (under Win32/Linux), whereas prior versions of the compiler have lower values of this macro. * BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is defined for __EDG_VERSION__<=303, that is, for all Intel compilers up to (and including) 8.1, under Win32/Linux. * Under Win32, all Intel toolset .jams define the compiler option --arg_dep_lookup, which explicitly enables ADL (disabled by default.) I don't know what the situation of ADL is for Intel under Linux, but in any case this switch is *not* used for that OS. Current RC tests for Intel 9.0 under Linux show the problem listed at http://tinyurl.com/8f5g6 One piece of code where the error pops up is like this #if defined(BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL) ::boost::multi_index::detail::swap(i1,get<1>(es2)); #else using std::swap; swap(i1,get<1>(es2)); #endif Given the __EDG_VERSION__ number of this compiler, it is the second preprocessor branch that is compiled, and it fails to use the user-supplied global swap() in favor of std::swap(), hence the error. However, this same tests succesfully passes for Intel 9.0 under Win32 (same __EDG_VERSION__ as the Linux case)!! My conclusions: * The fact that the test passes under Intel 9.0 for Win32, for which BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is *not* defined, suggests that __EDG_VERSION__<=303 is the right check for setting this macro. * But the same test fails under Intel 9.0 for Linux, which hints at an ADL problem other than that controlled by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. Could it be that Intel compilers under Linux also necessitate the --arg_dep_lookup compiler switch (which is currently not set)? This looks like the only sensible conslusion from the facts described. Thanks and sorry for the long post, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5