- Boost - lists.boost.org

Re: [boost] GUI coordinate units (Was: GUI foundations)
by brangdon＠cix.compulink.co.uk 10 Oct '05

10 Oct '05

In-Reply-To: <dic90t$l4e$1(a)sea.gmane.org> joel(a)boost-consulting.com (Joel de Guzman) wrote (abridged): > Sure they do text. I didn't say they didn't. I just said I didn't find any documentation on it. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] Interest in dimension/unit-checking library?
by Schrom, Brian T 10 Oct '05

10 Oct '05

I also agree. I find that I was starting to invent some of this in my chart library and a generic, complete solution would be wonderful to use in that context. > <big snip> > >Please to learn that work is still done - IMO we still badly need a good solution to the ubiquitous (but hard) problem of units & dimensions. > >Paul

1 0

serialization problem with binary archives on v1.33
by Keith McNeill 10 Oct '05

10 Oct '05

We are trying to upgrade from boost 1.31 (+ compaitable serialization) to boost v1.33. We have one particular test that is failing with what looks like serialization deserialing a bad pointer. In particular the bad pointer is the 3rd instance reference of a particular object. The 1st & 2nd deserialize fine the 3rd is bogus. This is code that works fine on 1.31 both binary & text mode. It works in 1.33 text mode, but fails in 1.33 binary mode. What is the best way to debug this problem? Is there anyway to inspect the binary archive to printout the contents...at least the pointers/addresses contained in the archive? I haven't been able to get it down to a simple test case (it is part of a large system). I could send out the binary and text archive if that would help. This is using g++ 3.3.4 on FC3 (32bit) & Also 3.3.4 on Red Hat Enterprise v3 on a 64bit platform. Keith mcneill(a)streambase.com

2 3

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

10 Oct '05

In-Reply-To: <4343103A.6010007(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > I think it is fair to assume people don't have assert(false) in code > that is ready for release - it is just used temporarily during > debugging. No, it isn't fair to assume that. I have: if (e) { assert(false); throw "can't happen"; } or similar in release code. > But just to be sure OKAY_TO_USE_ASSUME should be off by default. A single monolithic switch isn't practical. There is no way to switch OKAY_TO_USE_ASSUME on without first checking whether every piece of code in the program is OK with it. > > If that is the behavior of __assume(false), or at least given > > that it is a reasonable interpretation of what it could do, then > > including __assume() in BOOST_ASSERT() seems a little dangerous. > > Which brings up back to the start of this thread :-). Quite so. I find I am repeating myself. -- Dave Harris, Nottingham, UK.

5 7

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

10 Oct '05

In-Reply-To: <4349965D.5030005(a)ezequal.com> chaos(a)ezequal.com (Jason Hise) wrote (abridged): > Isn't that an abuse of assert? No. The behaviour is well defined. > Why do you need both types of checks in the same place? To repeat what I said in my first post in this thread: Although I sympathise with the view that a failed assert should be considered undefined behaviour, I personally find the current documented behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] About timedlock....
by Jon Kalb 10 Oct '05

10 Oct '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Arkadiy Vertleyb > Sent: Friday, October 07, 2005 8:52 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] About timedlock.... > > "David Abrahams" <dave(a)boost-consulting.com> wrote > > > "Boost" <u0086000(a)cc.ncu.edu.tw> writes: > > > > > Hi, > > > > Please identify yourself appropriately. You do not represent Boost. > > If you insist on it, a different pseudonym is acceptable if > you intend > > to use it consistently in this forum. In our culture, though, > > individuals are generally known by their real names. > > According to Yahoo, there are 33 people in just the US whose > last name is "Boost" (unfortunately the search by the first > name is not possible). What happens if one of them > subscribes to this mailing list? > > ;-) > > Regards > Arkadiy They'll be asked to identify themselves by their first and last names. This will work until one of them names their son (or daughter) Org (or Moderator :-). > Regards > Boost, Org -- Jon Kalb

1 0

[Preprocessor] How to get the size of a tuple using variadic macros
by Yao Zhen 10 Oct '05

10 Oct '05

I am aware that variadic macros are not in the current C++ standard. However, it is declared that "the C++ standardization committee is likely to adopt C99's preprocessor extensions for the next version of the C++ standard." So here is a question about it. I have though that with the help of variadic macros, it would be nolonger necessary for us to povide size of preprocessor tuples manually. For instance, in fact it is easy to implement the BOOST_PP_TUPLE_ELEM macro more clearly as: #define TUPLE_ELEM(i, tuple) TUPLE_ELEM_ ## i tuple #define TUPLE_ELEM_0(a0, ...) a0 #define TUPLE_ELEM_1(a0, a1, ...) a1 #define TUPLE_ELEM_2(a0, a1, a2, ...) a2 #define TUPLE_ELEM_3(a0, a1, a2, a3, ...) a3 However, I failed to think out a way to implement TUPLE_SIZE. Is there any way to do this? If the answer is yes, it will be possible to eliminate all the manually specified size argument of all tuple manipulation macros. That would be a great news for preprocessor metaprogramming. Best regards, Zhen -- USTC Alumni Email System

2 1

[program_options] gcc 4.0.2 (cygwin) DLL tests
by David Abrahams 10 Oct '05

10 Oct '05

positional_options_test_dll and cmdline_test_dll seem to run forever and use unlimited memory. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost regression notification (2005-10-10 [HEAD])
by Douglas Gregor 10 Oct '05

10 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-10T05:00:26Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 103 failures in 10 libraries: concept_check (13) foreach (1) graph (2) mpl (1) parameter (13) serialization (39) spirit (8) thread (4) tuple (1) typeof (21) |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 msvc vc-7_1 |foreach| user_defined: msvc |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 msvc 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 msvc unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux 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 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 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: vc-7_1 |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 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4

1 0

[spirit][1.33.1] regressions and a fix
by John Maddock 10 Oct '05

10 Oct '05

The new spirit regressions for 1.33.1 here: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… appear to be caused by a conflict between the Jamfile and the BUILD environment variable. They're easily fixed with the following patch (tested on Windows only): RCS file: /cvsroot/boost/boost/libs/spirit/test/Jamfile,v retrieving revision 1.35 diff -r1.35 Jamfile 78c78 < template multi-threading : : : --- > template multi-threading : : 85c85 < template multi-threading : <dll>@boost/libs/thread/build/boost_thread : : --- > template multi-threading : <dll>@boost/libs/thread/build/boost_thread > : 92c92 < template normal : : : --- > template normal : : OK to commit? John.

2 2