- Boost - lists.boost.org

Re: [boost] Questions on Serialization
by Martin Bonner 24 Aug '05

24 Aug '05

----Original Message---- From: Christoph Ludwig [mailto:cludwig@cdc.informatik.tu-darmstadt.de] Sent: 23 August 2005 20:34 To: boost(a)lists.boost.org Subject: Re: [boost] Questions on Serialization > On Tue, Aug 23, 2005 at 08:44:15AM -0700, Robert Ramey wrote: >> Daryle Walker wrote: >>> Also, the Contents entries from "void_cast" to >>> "BOOST_STATIC_WARNING" need to be raised a level so they don't look >>> like child entries for "extended_type_info". >> >> It the current version of the manual I see: >> >> Miscelenaeous >> extended_type_info >> Motivation >> Runtime Interface >> Requirements >> Models >> void_cast >> utf8_code_cvt >> BOOST_STRONG_TYPE >> state_saver >> Datafow Iterators >> smart_cast >> BOOST_STATIC_WARNING >> Rationale >> >> That is, void_cast is not show as part of extended_type_info. > > I am sorry, but with Konqueror 3.4.2 and Firefox 1.0.6 on a Linux > machine void_cast through BOOST_STATIC_WARNING appear all one level > *under* extended_type_info. I am going to attach screenshots which > exhibit the problem. > <AOL>Me too</AOL> Add Firefox 1.0.6 on Windows XP to the list of problem browsers. Note that Internet Explorer 6.0.2900 on Windows XP DOES behave correctly. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[minmax] A link needs to be corrected
by Daryle Walker 24 Aug '05

24 Aug '05

This is for the top page for the min-max algorithms at <http://www.boost.org/libs/algorithm/minmax/>. The link reference for Alexandrescu's paper about std::min/max problems is no longer active. I think the new link is <http://www.cuj.com/documents/cujcexp1904alexandr/> (which got redirected to <http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm> on my browser). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Updated version history 3rd time
by Daryle Walker 24 Aug '05

24 Aug '05

I undid the last two changes I did, because I realized I didn't have to peruse the Mail archives for changes; I could use <http://www.archive.org> instead. Now I updated down to 1999-Sep-1. I still have to look at the old e-mails for earlier results. (I think Beman did all the pre-CVS website edits back then, so if he has a master list, then I don't have to guesstimate releases from reading _every_ old e-mail.) Between my first two changes and the redo, Rene Rivera changed the CSS to fix the table. The new listing doesn't use a table any longer, but the quick glimpse I had of the change (before I paved it over) didn't show any change to the table. Instead of adding CSS attributes to restore table functionality, maybe we should change whatever CSS took it away in the first place. Why was the "...remainder..." paragraph moved inward? I deliberately did _not_ have it within the history list. And what's with the extra "-body" and/or "-DIGIT" sections? Are they for visual CSS layout, because they seem superfluous semantically? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

[multi_index][rfc] random access indices
by Joaquín Mª López Muñoz 24 Aug '05

24 Aug '05

Hello all, I'm considering whether to add to Boost.MultiIndex a new type of indices with random access semantics, somewhat similar to std::vectors. As I wouldn't like to keep adding things to the library without some actual feedback as of its suitability, I've written some preliminary notes about how these indices could look like, located at: http://195.235.93.150/rnd_indices_spec.html I'm very interested in knowing your opinion about this stuff, ways of improving the spec, and most of all whether it is really an interesting thing to have in Boost.MultiIndex 1.34. Please go ahead and throw your 2 cents. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport config patch
by François Dumont 24 Aug '05

24 Aug '05

Hello In order to prepare STLport 5.0 release here is a patch for the stlport.hpp boost config file. It is really limited, only introduction of a new macro to distinguish between different kind of support of nested template classes. It is backward compatible with previous STLport version. Bests // (C) Copyright John Maddock 2001 - 2002. // (C) Copyright Darin Adler 2001. // (C) Copyright Jens Maurer 2001. // Use, modification and distribution are subject to the // Boost Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org for most recent version. // STLPort standard library config: #if !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) # include <utility> # if !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) # error "This is not STLPort!" # endif #endif // // __STL_STATIC_CONST_INIT_BUG implies BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS // for versions prior to 4.1(beta) // #if (defined(__STL_STATIC_CONST_INIT_BUG) || defined(_STLP_STATIC_CONST_INIT_BUG)) && (__SGI_STL_PORT <= 0x400) # define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif // // If STLport thinks that there is no partial specialisation, then there is no // std::iterator traits: // #if !(defined(_STLP_CLASS_PARTIAL_SPECIALIZATION) || defined(__STL_CLASS_PARTIAL_SPECIALIZATION)) # define BOOST_NO_STD_ITERATOR_TRAITS #endif // // No new style iostreams on GCC without STLport's iostreams enabled: // #if (defined(__GNUC__) && (__GNUC__ < 3)) && !(defined(__SGI_STL_OWN_IOSTREAMS) || defined(_STLP_OWN_IOSTREAMS)) # define BOOST_NO_STRINGSTREAM #endif // // No new iostreams implies no std::locale, and no std::stringstream: // #if defined(__STL_NO_IOSTREAMS) || defined(__STL_NO_NEW_IOSTREAMS) || defined(_STLP_NO_IOSTREAMS) || defined(_STLP_NO_NEW_IOSTREAMS) # define BOOST_NO_STD_LOCALE # define BOOST_NO_STRINGSTREAM #endif // // If the streams are not native, and we have a "using ::x" compiler bug // then the io stream facets are not available in namespace std:: // #ifdef _STLPORT_VERSION # if !defined(_STLP_OWN_IOSTREAMS) && defined(_STLP_USE_NAMESPACES) && defined(BOOST_NO_USING_TEMPLATE) && !defined(__BORLANDC__) # define BOOST_NO_STD_LOCALE # endif #else # if !defined(__SGI_STL_OWN_IOSTREAMS) && defined(__STL_USE_NAMESPACES) && defined(BOOST_NO_USING_TEMPLATE) && !defined(__BORLANDC__) # define BOOST_NO_STD_LOCALE # endif #endif // // Without member template support enabled, their are no template // iterate constructors, and no std::allocator: // #if !(defined(__STL_MEMBER_TEMPLATES) || defined(_STLP_MEMBER_TEMPLATES)) # define BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS # define BOOST_NO_STD_ALLOCATOR #endif // // however we always have at least a partial allocator: // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) # define BOOST_NO_STD_ALLOCATOR #endif #if defined(_STLP_NO_MEMBER_TEMPLATE_KEYWORD) && defined(BOOST_MSVC) && (BOOST_MSVC <= 1300) # define BOOST_NO_STD_ALLOCATOR #endif // // If STLport thinks there is no wchar_t at all, then we have to disable // the support for the relevant specilazations of std:: templates. // #if !defined(_STLP_HAS_WCHAR_T) && !defined(_STLP_WCHAR_T_IS_USHORT) # ifndef BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTRING # endif # ifndef BOOST_NO_STD_WSTREAMBUF # define BOOST_NO_STD_WSTREAMBUF # endif #endif // // We always have SGI style hash_set, hash_map, and slist: // #define BOOST_HAS_HASH #define BOOST_HAS_SLIST // // STLport does a good job of importing names into namespace std::, // but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since our // workaround does not conflict with STLports: // // // Harold Howe says: // Borland switched to STLport in BCB6. Defining BOOST_NO_STDC_NAMESPACE with // BCB6 does cause problems. If we detect C++ Builder, then don't define // BOOST_NO_STDC_NAMESPACE // #if !defined(__BORLANDC__) && !defined(__DMC__) // // If STLport is using it's own namespace, and the real names are in // the global namespace, then we duplicate STLport's using declarations // (by defining BOOST_NO_STDC_NAMESPACE), we do this because STLport doesn't // necessarily import all the names we need into namespace std:: // # if (defined(__STL_IMPORT_VENDOR_CSTD) \ || defined(__STL_USE_OWN_NAMESPACE) \ || defined(_STLP_IMPORT_VENDOR_CSTD) \ || defined(_STLP_USE_OWN_NAMESPACE)) \ && (defined(__STL_VENDOR_GLOBAL_CSTD) || defined (_STLP_VENDOR_GLOBAL_CSTD)) # define BOOST_NO_STDC_NAMESPACE # define BOOST_NO_EXCEPTION_STD_NAMESPACE # endif #elif defined(__BORLANDC__) && __BORLANDC__ < 0x560 // STLport doesn't import std::abs correctly: #include <stdlib.h> namespace std { using ::abs; } // and strcmp/strcpy don't get imported either ('cos they are macros) #include <string.h> #ifdef strcpy # undef strcpy #endif #ifdef strcmp # undef strcmp #endif #ifdef _STLP_VENDOR_CSTD namespace std{ using _STLP_VENDOR_CSTD::strcmp; using _STLP_VENDOR_CSTD::strcpy; } #endif #endif // // std::use_facet may be non-standard, uses a class instead: // #if defined(__STL_NO_EXPLICIT_FUNCTION_TMPL_ARGS) || defined(_STLP_NO_EXPLICIT_FUNCTION_TMPL_ARGS) # define BOOST_NO_STD_USE_FACET # define BOOST_HAS_STLP_USE_FACET #endif // // If STLport thinks there are no wide functions, <cwchar> etc. is not working; but // only if BOOST_NO_STDC_NAMESPACE is not defined (if it is then we do the import // into std:: ourselves). // #if defined(_STLP_NO_NATIVE_WIDE_FUNCTIONS) && !defined(BOOST_NO_STDC_NAMESPACE) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE #endif // // If STLport for some reason was configured so that it thinks that wchar_t // is not an intrinsic type, then we have to disable the support for it as // well (we would be missing required specializations otherwise). // #if !defined( _STLP_HAS_WCHAR_T) || defined(_STLP_WCHAR_T_IS_USHORT) # undef BOOST_NO_INTRINSIC_WCHAR_T # define BOOST_NO_INTRINSIC_WCHAR_T #endif // // Borland ships a version of STLport with C++ Builder 6 that lacks // hashtables and the like: // #if defined(__BORLANDC__) && (__BORLANDC__ == 0x560) # undef BOOST_HAS_HASH #endif // // gcc-2.95.3/STLPort does not like the using declarations we use to get ADL with std::min/max // #if defined(__GNUC__) && (__GNUC__ < 3) # include <algorithm> // for std::min and std::max # define BOOST_USING_STD_MIN() ((void)0) # define BOOST_USING_STD_MAX() ((void)0) namespace boost { using std::min; using std::max; } #endif #define BOOST_STDLIB "STLPort standard library version " BOOST_STRINGIZE(__SGI_STL_PORT)

2 1

Re: [boost] shared_ptr under OS X
by Steve Ramsey 24 Aug '05

24 Aug '05

On Sun, 21 Aug 2005, at 16:56, Howard Hinnant wrote: > On Aug 21, 2005, at 4:28 PM, Steve Ramsey wrote: > >> I've had a number of programs crash after recompiling with the 1.33.0 >> release and eventually tracked the problems down to shared_ptr, >> specifically the atomic_decrement function provided in >> sp_counted_base_cw_ppc.hpp. > > Try these: <snip> That seems to have done the trick. Presumably the return value was never making it out of the decrement function, eventually causing double deletes when circumstances were right. Thanks for the quick response; I'll send along another message if this turns out not to be a complete solution, though I don't foresee problems. Steve

6 8

shared_ptr under OS X
by Steve Ramsey 24 Aug '05

24 Aug '05

I've had a number of programs crash after recompiling with the 1.33.0 release and eventually tracked the problems down to shared_ptr, specifically the atomic_decrement function provided in sp_counted_base_cw_ppc.hpp. So far, I've only noted problems on a dual processor G5 running OS X 10.4.2, most often when a shared_ptr created as a temporary object goes out of scope and the destructor gets called. I was able to eliminate the problem by replacing the hand-rolled asm atomic routines with equivalent system routines from CarbonCore/DriverSychronization.h (except for atomic_conditional_increment, which I don't have an equivalent for). I'm not a PPC asm guru, or even a threading/mp guru, so I haven't been able to properly evaluate the boost functions. I do know that I was getting access exceptions upon execution of the sync instruction in the affected areas of the code. This was using CodeWarrior 9.5 to compile, with optimizations disabled, but inlining activated (the decrement was being inlined). In my (limited) research into the problem, I haven't been able to find any good examples of hand-rolled atomic ops that are mp-savvy, though I found plenty of dire warnings against making the attempt and numerous recommendations to use either the kernel-level or Carbon-level routines instead, depending on context. What additional information can I provide and who can I provide it to? I haven't spent enough time on this to conclude definitively that the problem is in the boost source, as it might be CodeWarrior's munging of it that causes the problem. It's unlikely to be an issue in my code, as I've seen the issue pop up in relation to several different constructs, all of which appear to be legal C++ to me. I won't be pursuing this independently, as the workaround I've found solves my immediate problem and lets me get back to work after killing a couple of days playing around with it. Steve

7 10

missing stdio.h include in thread lib
by François Dumont 23 Aug '05

23 Aug '05

Hello I am submitting once again this patch for the thread library as the issue still exist with 1.33.0. When building boost with msvc-stlport toolset the _snprintf function used at read_write_mutex.cpp:151 is undefined as stdio.h has not been included next to tchar.h include at line 38. In order to have this patch apply this time I have study why _snprintf _is_ defined when using msvc toolset. The conclusion is that the definition comes from the <utility> include in boost/config/select_stdlib_config.hpp which is used to guess what is the std lib. In VC6 utility header include a lot of headers indirectly like cstring, cwchar, xstddef and cstdio which give _snprintf. The STLport utility try to limit the includes, maybe it shouldn't ;-) For your info I discovered an other issue, some guy from boost will have perhaps to work on it. I have only check it with VC6, don't know if it is reproductible with .NET 2002 or 2003. Even if you set your INCLUDE env variable to use the latest PSDK rather than the one integrated in VC6 you are still include of windows.h from boost during build process are still referencing the VC6 windows.h rather than the one of the latest SDK. I thought it was coming from the #include "windows.h" that exists in many VC6 headers but it is not the case. Bests *** read_write_mutex.cpp.orig Tue Aug 23 07:46:00 2005 --- read_write_mutex.cpp Tue Aug 23 19:02:08 2005 *************** *** 36,41 **** --- 36,42 ---- #ifdef BOOST_HAS_WINTHREADS # include <windows.h> # include <tchar.h> + # include <stdio.h> # if !((_WIN32_WINNT >= 0x0400) || (_WIN32_WINDOWS > 0x0400)) inline bool IsDebuggerPresent(void)

1 0

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

23 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-23T14:59:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 67 failures in 6 libraries: functional/hash (4) graph (14) parameter (4) python (22) serialization (22) wave (1) |functional/hash| point: borland-5_6_4 portable: msvc vc-6_5 vc-6_5-stlport |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-3_4_3-sunos 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 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: 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_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 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: vc-7_1 test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

boost dll versions
by Neal Becker 23 Aug '05

23 Aug '05

I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have libboost.so.1.33.0 Let's assign this soname libboost.so.1. Then a symlink is created libboost.so.1 -> libboost.so.1.33.0. Now if a bugfix comes out that does not change the api, be can have libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink: libboost.so.1 -> libboost.so.1.33.1 OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.

11 24