- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1272315 ] boost.range and "const char[]".
by SourceForge.net 25 Aug '05

25 Aug '05

Bugs item #1272315, was opened at 2005-08-26 00:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1272315&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Shandar (sergey_shandar) Assigned to: Nobody/Anonymous (nobody) Summary: boost.range and "const char[]". Initial Comment: // Both boost::end(...) and boost::size(...) return wrong values. // Compilers: GCC 3.3.4 and VC 7.1. // A simple example: #include <boost/range/size.hpp> #include <boost/test/minimal.hpp> int test_main(int, char *[]) { const char A[] = "\0A"; BOOST_CHECK(boost::size(A)==2); // failed. return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1272315&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] stlport config patch
by François Dumont 25 Aug '05

25 Aug '05

Sorry for the mistake, here is the patch file. Bests *** stlport.hpp.orig Tue Aug 23 19:06:41 2005 --- stlport.hpp Mon Aug 22 21:15:14 2005 *************** *** 74,80 **** // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR ! #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) # define BOOST_NO_STD_ALLOCATOR #endif --- 74,80 ---- // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR ! #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) || defined(_STLP_DONT_SUPPORT_REBIND_MEMBER_TEMPLATE) # define BOOST_NO_STD_ALLOCATOR #endif

2 1

Re: [boost] undefined behaviour in tuple_io.hpp (bug)(patch)
by Martin Bonner 25 Aug '05

25 Aug '05

----Original Message---- From: Jonathan Wakely [mailto:cow@compsoc.man.ac.uk] Sent: 25 August 2005 11:42 To: boost(a)lists.boost.org Subject: Re: [boost] undefined behaviour in tuple_io.hpp (bug)(patch) > Rupert Kittinger wrote: > >> In the tuple_io.hpp header, there seems to be a slight problem in >> extract_and_check_delimiter(). The following snippet is problematic: >> >> char c; >> if (is_delimiter) { >> is >> c; >> if (c!=d) { >> is.setstate(std::ios::failbit); >> } >> } >> >> If c cannot be read because is.eof(), the result of c!=d is >> undefined. > > IMHO the fix is neater as: > > if (is>>c && c!=d) > > basic_ios::operator void*() exists to support this syntax rather than > explicitly testing the state with good(), fail() etc. And IMveryHO, the original patch is neater. This is a religous issue; I think the only sensible approach is to require each individual library to be consistent, and let the library developer / maintainer make the decision. (Apologies if you /are/ the maintainer of Boost.Tuple - I looked, but couldn't find a list of library maintainers.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Link errors with wserialization on MSVC 7.1 (boost 1.33)
by Rodger Bernstein 25 Aug '05

25 Aug '05

I'm using VC 7.1 with MFC and boost 1.33 serialization. I'm getting these link errors. Any one have this problem? I had more link errors with 1.32 I just didn't use Unicode to get around the link errors. But I'd really really like to have Unicode XML files. Linking... libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : error LNK2005: _iswdigit already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : error LNK2005: _iswxdigit already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(basic_text_wiprimitive.obj) : error LNK2005: _iswspace already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : warning LNK4006: _iswdigit already defined in libcmtd.lib(_wctype.obj); second definition ignored libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : warning LNK4006: _iswxdigit already defined in libcmtd.lib(_wctype.obj); second definition ignored libboost_wserialization-vc71-mt-sgd-1_33.lib(basic_text_wiprimitive.obj) : warning LNK4006: _iswspace already defined in libcmtd.lib(_wctype.obj); second definition ignored

5 5

[iostreams] mapped_file trouble
by Dylan Trotter 25 Aug '05

25 Aug '05

Hi, I just wanted to point out a fairly major flaw with the Windows implementation of memory mapped files. In memory_mapped.cpp on line 205-207 a file mapping is created as follows: ::CreateFileMappingA( pimpl_->handle_, NULL, readonly ? PAGE_READONLY : PAGE_READWRITE, 0, 0, p.path.c_str() ); The problem with this is that if p.path.c_str() has any backslashes in it (very likely given that it's Windows), the call fails. From the MS documentation: "Windows NT: The name can contain any character except the backslash character. Windows Me/98/95: The name can contain any character except the backslash character. The empty string ("") is a valid object name." Also from the documentation: "If this parameter is NULL, the mapping object is created without a name." Given that there's no way to access named memory maps from the boost interface anyway, it seems pointless to name the mapping. My suggestion is to pass in NULL and avoid naming difficulties altogether. Thanks, Dylan Trotter

2 3

[statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 25 Aug '05

25 Aug '05

When compiling the examples (statechart library downloaded from sf 18 Aug), I get the following warnings: <warnings format=edited> /usr/local/boost_1_33_0/boost/statechart/detail/state_base.hpp: In instantiation of `boost::statechart::detail::state_base<std::allocator<void>, boost::statechart::detail::rtti_policy>': /usr/local/boost_1_33_0/boost/statechart/state_machine.hpp:443: instantiated from `boost::statechart::state_machine<Machine, Greeting, std::allocator<void>, boost::statechart::null_exception_translator>' ../main.cpp:12: instantiated from here /usr/local/boost_1_33_0/boost/statechart/detail/state_base.hpp:74: warning: `class boost::statechart::detail::state_base<std::allocator<void>, boost::statechart::detail::rtti_policy>' has virtual functions but non-virtual destructor [snip] /usr/local/boost_1_33_0/boost/statechart/simple_state.hpp:189: instantiated from `boost::statechart::simple_state<Greeting, Machine, boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, has_no_history>' ../main.cpp:14: instantiated from here /usr/local/boost_1_33_0/boost/statechart/detail/leaf_state.hpp:27: warning: `class boost::statechart::detail::leaf_state<std::allocator<void>, boost::statechart::detail::rtti_policy>' has virtual functions but non-virtual destructor </warnings> I changed ~simple_State() and ~state_base() to virtual and the warnings disappeared. However, ~state_base() contains the following annotation: // This destructor is not virtual for performance reasons. The library // ensures that a state object is never deleted through a state_base // pointer but only through a pointer to the most-derived type. ~state_base() {} As a quick, not-definitive check, I built PingPong* with both the virtual and non-virtual dtorS using gcc 3.4.2 on an old i386-redhat-linux machine. The results appear to be the reverse of what I would expect, but I checked to verify that I have the correct result/config correspendence. ..................non-virtual.....virtual PingPongSingle.... 4.08 ..... 3.71 PingPongMulti1.... 6.01997 ..... 5.85999 PingPongMulti2.... 19.53 ..... 19.55 Reminds me of the old joke: "I see fine. I just don't understand what I'm looking at." Two questions: 1) will making the dtorS virtual lead to adverse consequences I simply haven't encountered yet; and 2) can someone help me understand what I did wrong in setting up this test? <extra_credit ot=true my_understanding=faulty> With a well-developed pipelined architecture and a reasonably rich set of addressing operations, shouldn't there be little or no difference between direct and indirect access times - given that the bookeeping normally associated with virtual classes has already been paid for? </extra_credit> Thanks to any/all for help with this. Regards, Dick Bridges "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu

3 2

BOOST_PP_STRINGIZE with MSVC 7.1 broken in 1.33.0 library version
by Sergey Skorniakov 24 Aug '05

24 Aug '05

Test code: #define AAA const char bbb[] = BOOST_PP_STRINGIZE(prefix BOOST_PP_COMMA() postfix) AAA; Preprocessing of such a code is accompanied by warning C4002: too many actual parameters for macro 'BOOST_PP_STRINGIZE_I'. With 1.32.0 library version variable bbb value was "prefix, postfix". With new version it is just "prefix".

2 1

Boost regression notification (2005-08-24)
by Douglas Gregor 24 Aug '05

24 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-24T15:46:17Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 119 failures in 14 libraries: bind (1) function (10) functional/hash (1) graph (13) iostreams (1) parameter (4) program_options (14) property_map (1) python (23) regex (2) serialization (30) signals (5) thread (13) wave (1) |bind| bind_function_test: borland-5_6_4 |function| allocator_test: borland-5_6_4 contains2_test: borland-5_6_4 contains_test: borland-5_6_4 function_arith_portable: borland-5_6_4 function_n_test: borland-5_6_4 function_ref_portable: borland-5_6_4 mem_fun_portable: borland-5_6_4 stateless_test: borland-5_6_4 std_bind_portable: borland-5_6_4 sum_avg_portable: borland-5_6_4 |functional/hash| point: borland-5_6_4 |graph| cuthill_mckee_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dfs: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 king_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |iostreams| regex_filter_test: borland-5_6_4 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |program_options| cmdline_test: borland-5_6_4 cmdline_test_dll: borland-5_6_4 options_description_test: borland-5_6_4 options_description_test_dll: borland-5_6_4 parsers_test: borland-5_6_4 parsers_test_dll: borland-5_6_4 positional_options_test: borland-5_6_4 positional_options_test_dll: borland-5_6_4 unicode_test: borland-5_6_4 unicode_test_dll: borland-5_6_4 variable_map_test: borland-5_6_4 variable_map_test_dll: borland-5_6_4 winmain: borland-5_6_4 winmain_dll: borland-5_6_4 |property_map| dynamic_properties_test: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |regex| grep: borland-5_6_4 static_mutex_test: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos 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 |signals| dead_slot_test: borland-5_6_4 deletion_test: borland-5_6_4 ordering_test: borland-5_6_4 signal_n_test: borland-5_6_4 trackable_test: borland-5_6_4 |thread| test_barrier: borland-5_6_4 test_barrier_lib: borland-5_6_4 test_condition: borland-5_6_4 test_condition_lib: borland-5_6_4 test_mutex: borland-5_6_4 test_mutex_lib: borland-5_6_4 test_once: borland-5_6_4 test_once_lib: borland-5_6_4 test_read_write_mutex: borland-5_6_4 test_read_write_mutex_lib: borland-5_6_4 test_thread: borland-5_6_4 test_thread_lib: borland-5_6_4 test_tss: borland-5_6_4 |wave| testwave: gcc-3.3.6-linux

2 1

warning C4275 with VC++ (non dll-interface class...) (again)
by Luke Elliott 24 Aug '05

24 Aug '05

Hi I was wondering why boost libraries don't do something like: class positional_options_description { public: BOOST_PROGRAM_OPTIONS_DECL positional_options_description(); BOOST_PROGRAM_OPTIONS_DECL void add(const char* name, int max_count); ... }; instead of: class BOOST_PROGRAM_OPTIONS_DECL positional_options_description { public: max_count); ... }; in order to remove the irritating C4275 warning? i.e. only declspec public, protected members (and any private members invoked from inline methods). From searching the archives it looks like the usual suggestion is to disable the warning, I just wondered if the above had been considered (and if rejected, why)? Is it because this behaviour doesn't work with win32 builds of GCC if using the declspec functionality (instead of the export-all)? Thanks for any insight. Luke Elliott.

5 10

[TypeTraits] aligned_storage & type_with_alignment docs swapped
by Kim Barrett 24 Aug '05

24 Aug '05

In the type_traits library, the documentation for aligned_storage and type_with_alignment seem to be somewhat swapped. Certainly the documentation doesn't match the implementation. Swapping the documentation would make the names make much more sense wrto their documentation too.

2 1