- Boost - lists.boost.org

Re: [boost] [cstdint] uintptr_t and intptr_t are missing
by Martin Bonner 29 Sep '05

29 Sep '05

----Original Message---- From: Joaquin M Lopez Munoz [mailto:joaquin@tid.es] > Is BOOST_HAS_INTPTR_TYPES supposed to inform whether there > are vendor-provided ::intrptr_t/::uintrptr_t types? If so, I > fail to see its utility, since boost::intrptr_t/boost::untrptr_t > can be provided universally. Not if the compiler doesn't HAVE a integral type which can hold a pointer. For example, a compiler for Intel processors with 32 bit longs, no long long, and 16:32 pointers. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 3

[integer] Create (u)int_natural_t
by Daryle Walker 29 Sep '05

29 Sep '05

The "int" type was supposed to match the processor's natural built-in integer processor. That was easy to maintain in the 16- and 32-bit eras, but got screwed up when we started 64-bit computing. The C and C++ communities decided to expand its integer types by keeping the current types at their 32-bit-era sizes and extended the type system with a "long long" instead of moving "int" and "long" up and adding a "short short". Now we don't have a convenient way to name the best integer type in a portable fashion. I suggest we add a "int_natural_t" typedef to <boost/cstdint.hpp> to name the best integer type (and a corresponding "uint_natural_t"). We would have to research what that type is for each compiler and/or platform combination and use #conditionals. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[serialization] JSON: a potential archive format?
by Daryle Walker 29 Sep '05

29 Sep '05

I was wandering around the web and saw a specification page about JSON (JavaScript Object Notation). Maybe it could be used as a new archive format for the serialization library. I looked at "Introducing JSON" @ <http://www.crockford.com/JSON/>. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[asio] how detect deadline_timer expired state?
by BRIDGES Dick 29 Sep '05

29 Sep '05

I'm performing an async_wait() on a deadline_timer. Based upon some independent event (e.g., a keystroke) I want to [re]set the timer and, if it was expired, 'fire' an event indicating that the system has changed state from not_running to running. Maybe I'm missing something obvious, but it seems that deadline_timer should have a method to test whether or not the timer had expired (i.e., bool expired() ). BTW: This library is a joy. When does the review period start? ;) Regards, Dick Bridges

2 1

[review] results xpressive
by Thomas Witt 28 Sep '05

28 Sep '05

Hi All, I am happy to announce that xpressive has been accepted into boost. That being said I would like to thank Eric for writing such a high quality library and all the reviewers for the significant time they spent in reviewing the library. I have received some very detailed in depth reviews of the library. This has made my job really easy. Thanks! While xpressive is accepted without conditions I'd like to point out that the test coverage should be improved in the future. Thomas Review Manager xpressive Thomas Witt witt(a)acm.org

3 2

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 28 Sep '05

28 Sep '05

In-Reply-To: <200509261722.j8QHMRms015648(a)shannonhoon.balstatdev.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > > (e) is false, then the __assume tells us the sequence won't be > > executed at all, and both it and the BOOST_ASSERT can be optimised > > away. Whatever it > > If (e) is false, then BOOST_ASSERT takes some action, be it > invoking assert() or something else. Only if it's not optimised away. Here's my thinking. For clarity I'll write it like this, factoring out the common sub-expression: if (e) { BOOST_ASSERT( true ); __assume( true ); } else { BOOST_ASSERT( false ); __assume( false ); } The compiler knows that __assume(false) can never be reached so it can optimise away the whole "else" clause - provided it can prove that the BOOST_ASSERT always returns. In general it is dangerous to put other stuff in the same control block as __assume(false), because you don't know how clever the compiler will be about proving stuff like that. In this case you could argue that the compiler /cannot/ prove that BOOST_ASSERT will return; indeed in many cases it won't return. Even so I think it is a bit dangerous, but I suppose it doesn't really matter. -- Dave Harris, Nottingham, UK.

2 1

[Boost-bugs] [ boost-Bugs-1307179 ] c_local_adjustor is not thread-safe due to using localtime()
by SourceForge.net 28 Sep '05

28 Sep '05

Bugs item #1307179, was opened at 2005-09-28 19:59 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=1307179&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: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Krzysztof Lichota (klichota) Assigned to: Jeff Garland (az_sw_dude) Summary: c_local_adjustor is not thread-safe due to using localtime() Initial Comment: c_local_adjustor is not thread-safe due to using localtime(). It should be changed to use localtime_r() or, at least, docs should mention that it is not thread-safe. The same applies to all other boost units using localtime(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1307179&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

28 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-28T14:11:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 76 failures in 7 libraries: bind (1) foreach (1) graph (4) iostreams (11) random (1) range (3) serialization (55) |bind| bind_cv_test: gcc-4_0-darwin |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |iostreams| gzip_test: cw-9_5-darwin gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux vc-7_1 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5

1 0

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

28 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-28T05:00:20Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 124 failures in 11 libraries: concept_check (12) graph (2) mpl (1) parameter (12) python (3) serialization (30) spirit (8) thread (4) tuple (1) typeof (50) wave (1) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-4_0-darwin macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| back_reference: vc-7_1 slice: vc-7_1 virtual_functions: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: 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: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: 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 |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ptr_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ref_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 lvalue_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 member_function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 noncopyable_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 std_emulation: cw-9_4 std_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_dependent_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_enum_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_multiword_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_tpl_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 |wave| testwave: gcc-3.3.6-linux

1 0

[Boost-bugs] [ boost-Bugs-1307106 ] extended_type_info crash on global dtors (arm)
by SourceForge.net 28 Sep '05

28 Sep '05

Bugs item #1307106, was opened at 2005-09-28 09:47 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=1307106&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: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: extended_type_info crash on global dtors (arm) Initial Comment: Hello, i'm struggling with boost::serialization lib again ... I am using RC0_1.33 which has fixed some serialization stuff for me (1.33 was totally unusable for me due to that bugs). Now i seem to have encountered another problem... I am using the boost framework in cross platform projects: gcc 3.4.4: cygwin (win32), linux x86, linux arm gcc 4.0.1: cygwin (win32), linux x86, linux arm msvc 7.1: win32 After upgrading to 1.33/RC0 i get crashes on linux "ARM" processor platform (binaries). "pure virtual function call " -> SIGABRT The cross compiler is verified to work fine (3.4.4). After endless hours of debugging (thanks to that gdb/gdbserver 6.3 trash) i tracked it down to a specific serialization problem? Attached is a shortened gdb/server session (target = arm7tdmi)... It only occurs on arm platform (little endian), the same compiler on x86 (gcc 3.4.4) produces valid code. No crashes. Boost 1.32 worked flawlessly on all platforms with same compilers but it doesnt count because serialization has changed much between 1.32 and 1.33 (= could be anything) >From what i can see, the "return less_than(rhs); " operation is called on"boost::serialization::extended_type_info" object, resulting in pure virtual function call. I have no clue where to search/begin for error ... i can only debug on target (arm processor bord) with gdbserver which make it a mess (global dtors). I verified the "extended_type_info_typeid.cpp" code is linked in and the function: BOOST_SERIALIZATION_DECL(bool) extended_type_info_typeid_0::less_than(const extended_type_info &rhs) const { return 0 != get_eti().before( static_cast<const extended_type_info_typeid_0 &>(rhs).get_eti() ); } does exist in code. This is the offending snippet: ------------------------------------------------- BOOST_SERIALIZATION_DECL(bool) extended_type_info::operator<(const extended_type_info &rhs) const { int i = type_info_key_cmp(rhs); if(i < 0) return true; if(i > 0) return false; return less_than(rhs); <---- pure virtual function call !!! } ------------------------------------------------- The object instance itself seems ok, though i dont know how to validate vtable stuff because im not gdb expert. What gives? Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1307106&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0