August 2005 - Boost - lists.preview.boost.org

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

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

24 Aug '05

----Original Message---- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: 24 August 2005 16:19 To: boost(a)lists.boost.org Subject: Re: [boost] Questions on Serialization > I believe I've fixed this in the latest CVS. Let me know if its still > broken. > > Robert Ramey > >> 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. Sadly, http://www.boost.org/libs/serialization/doc/index.html is still broken - but that is probably because it isn't showing the latest CVS version! Do you have a URL where I can look at it (or instructions on what to download, so I can view it from a local copy - be gentle, I've never used CVS!). -- 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

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