August 2004 - Boost - lists.boost.org

Two issues with the IBM xlC compiler
by Matthias Troyer 11 Sep '04

11 Sep '04

Dear Boosters, I've got a patch to report for the IBM Viisual Age C++ compiler xlC, and one other problem to discuss. The patch we found necessary for version 6.0 of the compiler is: diff -u -r1.26 filtered_graph.hpp --- boost/graph/filtered_graph.hpp 22 Nov 2003 01:18:37 -0000 1.26 +++ boost/graph/filtered_graph.hpp 1 Jul 2004 14:11:27 -0000 @@ -208,8 +208,8 @@ > edge_iterator; typedef typename Traits::edges_size_type edges_size_type; - typedef typename edge_property_type<Graph>::type edge_property_type; - typedef typename vertex_property_type<Graph>::type vertex_property_type; + typedef typename ::boost::edge_property_type<Graph>::type edge_property_type; + typedef typename ::boost::vertex_property_type<Graph>::type vertex_property_type; typedef filtered_graph_tag graph_tag; //private: The original version just gives compiler errors, probably incorrectly but it does. The second problem is in the configure files. Who is responsible for maintaining them? The issue is the following patch I found necessary: --- boost/config/compiler/vacpp.hpp 22 Jun 2004 12:33:06 -0000 1.16 +++ boost/config/compiler/vacpp.hpp 1 Jul 2004 14:11:23 -0000 @@ -26,7 +26,7 @@ #endif #if (__IBMCPP__ <= 600) || !defined(BOOST_STRICT_CONFIG) -# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION +//# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif in-class member initializtions seem to work flawlessly on this compiler, so I wonder why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined. Having it defined causes problems with the Boost random library, which then tries to initializes values of an enum tto a 64-bit integer, which fails. Is there a reason why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined for this compiler or is this a bug? Best regards, Matthias

3 7

Re: [boost] Re: static sized strings
by Reece Dunn 10 Sep '04

10 Sep '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > [1] How do I pass the buffer and capacity to the implementation while > > allowing both fixed_string_base and fixed_string access to the >basic_string > > interface? I have chosen to route the data through one of the >basic_string > > constructors, requiring a const_cast. This is the best approach AFAICS. > >I haven't looked at your recent implementation, and I don't >presently have the time, so I really don't know what you're >talking about. If you can explain the dependencies to which you >refer, I'd appreciate it. I think it has bearing on the swap() >discussion. I have a class called detail::fixed_string_impl that has three data members: size, capacity and a pointer to the data buffer (len, cap and str respectively). Doing this allows the virtual functions to be removed and the implementation moved out of fixed_string. The fixed_string class can then pass its buffer and the capacity template parameter to the implementation via a constructor. The problem is that fixed_string is derived from fixed_string_base, which itself is derived from detail::basic_string_impl. This is needed to allow both fixed_string and fixed_string_base to have access to the full basic_string interface (like was done in the old implementation). The solution I have taken is to use the basic_string_impl( const CharT * s, size_type l ) constructor and use this to pass the buffer (s) and capacity (l) to the string. This is not ideal since it requires a const_cast to extract the buffer. This required modifying the constructor implementation in basic_string_impl to forward the parameters to Base and not implement them using append. The old implementation had the same problem with swap as the current one, since the string would get clipped when it is copied. For now, I will leave the implementation of swap as is (i.e. clipping and not signalling an exception), but add a note on this issue in the docs so that users are aware of it. Another problem I can forsee is using a custom char_traits or format_policy class, e.g. boost::fixed_string< 20, char, std::char_traits< char > > s1; strcpy( s1, "Hello" ); // ok boost::fixed_string< 20, char, win_char_traits< char > > s2; strcpy( s2, "There" ); // error This is the problem shared with basic_string when implementing functions using std::string. I have also fixed the problems relating to using the strxxx functions with Borland: the compiler may set them as instrinsic and add a macros defining strxxx as __strxxx__. To get around this, I now detect if they are macros and the Borland compiler is being used, then create an inlined function to the __strxxx__ version. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Review schedule
by Miro Jurisic 08 Sep '04

08 Sep '04

Could we keep the review schedule more up-to-date? I went there expecting to find a handy like to the library currently under review, rather than grovelling through the mail archive, but alas, it's 10 months out of date. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

7 11

[request] Sun and IBM users...
by Paul Mensonides 06 Sep '04

06 Sep '04

Can someone test the following preprocessor code on the Sun and IBM preprocessors: #include <boost/preprocessor/detail/split.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #include <boost/preprocessor/punctuation/paren.hpp> #include <boost/preprocessor/tuple/eat.hpp> #define IS_NULLARY(x) \ BOOST_PP_SPLIT(1, IS_NULLARY_C x BOOST_PP_COMMA() 0) \ /**/ #define IS_NULLARY_C() \ ~, 1 BOOST_PP_RPAREN() \ BOOST_PP_TUPLE_EAT(2) BOOST_PP_LPAREN() ~ \ /**/ IS_NULLARY(()) // 1 IS_NULLARY(()abc) // 1 IS_NULLARY(+) // 0 IS_NULLARY(xyz) // 0 #define IS_UNARY(x) IS_NULLARY(IS_UNARY_C x) #define IS_UNARY_C(a) () IS_UNARY((a)) // 1 IS_UNARY((a)abc) // 1 IS_UNARY(+) // 0 IS_UNARY(xyz) // 0 Regards and thanks, Paul Mensonides

3 12

Another patch for long long in gcc -std=c++98
by Aaron W. LaFramboise 04 Sep '04

04 Sep '04

This is a followup from prior threads: TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC in type_traits/is_convertable.hpp: http://thread.gmane.org/gmane.comp.lib.boost.devel/106708 long long support with GCC: http://thread.gmane.org/gmane.comp.lib.boost.user/6693 The following patch is another attempt to get long long support working, in a manner acceptable with Boost, even when -std=c++98 and -pedantic are specified. In particular, GCC supports long long in all modes, but __extension__ is required to quiet errors and warnings. It is possible that other C++ compilers with a similar situation regarding long long might be able to use this patch constructively. In short, typedefs are added for long long and unsigned long long in cstdint.hpp, and all uses of these typenames in the headers are changed to use these new names. Aaron W. LaFramboise Index: boost/boost/cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/cast.hpp,v retrieving revision 1.22 diff -c -p -r1.22 cast.hpp *** boost/boost/cast.hpp 11 Aug 2004 10:59:33 -0000 1.22 --- boost/boost/cast.hpp 15 Aug 2004 08:25:07 -0000 *************** *** 45,50 **** --- 45,51 ---- # include <boost/config.hpp> # include <cassert> # include <typeinfo> + # include <boost/cstdint.hpp> # include <boost/type.hpp> # include <boost/limits.hpp> # include <boost/detail/select_type.hpp> *************** namespace boost *** 156,166 **** // long / unsigned long long. Not intended to be full // numeric_limits replacements, but good enough for numeric_cast<> template <> ! struct fixed_numeric_limits_base<long long, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = true); ! static long long max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MAX return LONGLONG_MAX; --- 157,167 ---- // long / unsigned long long. Not intended to be full // numeric_limits replacements, but good enough for numeric_cast<> template <> ! struct fixed_numeric_limits_base<longlong, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = true); ! static longlong max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MAX return LONGLONG_MAX; *************** namespace boost *** 169,175 **** # endif } ! static long long min BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MIN return LONGLONG_MIN; --- 170,176 ---- # endif } ! static longlong min BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MIN return LONGLONG_MIN; *************** namespace boost *** 180,190 **** }; template <> ! struct fixed_numeric_limits_base<unsigned long long, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = false); ! static unsigned long long max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef ULONGLONG_MAX return ULONGLONG_MAX; --- 181,191 ---- }; template <> ! struct fixed_numeric_limits_base<ulonglong, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = false); ! static ulonglong max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef ULONGLONG_MAX return ULONGLONG_MAX; *************** namespace boost *** 193,199 **** # endif } ! static unsigned long long min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } }; # endif } // namespace detail --- 194,200 ---- # endif } ! static ulonglong min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } }; # endif } // namespace detail Index: boost/boost/concept_check.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/concept_check.hpp,v retrieving revision 1.28 diff -c -p -r1.28 concept_check.hpp *** boost/boost/concept_check.hpp 26 Jul 2004 00:31:58 -0000 1.28 --- boost/boost/concept_check.hpp 15 Aug 2004 08:25:10 -0000 *************** *** 16,21 **** --- 16,22 ---- #define BOOST_CONCEPT_CHECKS_HPP #include <boost/config.hpp> + #include <boost/cstdint.hpp> #include <boost/iterator.hpp> #include <boost/type_traits/conversion_traits.hpp> #include <utility> *************** struct require_same { typedef T type; }; *** 179,185 **** template <> struct SignedIntegerConcept<int> { void constraints() {} }; template <> struct SignedIntegerConcept<long> { void constraints() {} }; # if defined(BOOST_HAS_LONG_LONG) ! template <> struct SignedIntegerConcept<long long> { void constraints() {} }; # endif // etc. #endif --- 180,186 ---- template <> struct SignedIntegerConcept<int> { void constraints() {} }; template <> struct SignedIntegerConcept<long> { void constraints() {} }; # if defined(BOOST_HAS_LONG_LONG) ! template <> struct SignedIntegerConcept<longlong> { void constraints() {} }; # endif // etc. #endif Index: boost/boost/cstdint.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/cstdint.hpp,v retrieving revision 1.33 diff -c -p -r1.33 cstdint.hpp *** boost/boost/cstdint.hpp 10 Aug 2004 12:53:33 -0000 1.33 --- boost/boost/cstdint.hpp 15 Aug 2004 08:25:11 -0000 *************** namespace boost *** 278,283 **** --- 278,305 ---- #endif // BOOST_HAS_STDINT_H + + #ifdef BOOST_HAS_LONG_LONG + + namespace boost { + + # ifdef __GNUC__ + + __extension__ typedef long long longlong; + __extension__ typedef unsigned long long ulonglong; + + # else + + typedef long long longlong; + typedef unsigned long long ulonglong; + + # endif + + } // namespace boost + + # endif // BOOST_HAS_LONG_LONG + + #endif // BOOST_CSTDINT_HPP Index: boost/boost/integer_fwd.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/integer_fwd.hpp,v retrieving revision 1.3 diff -c -p -r1.3 integer_fwd.hpp *** boost/boost/integer_fwd.hpp 11 Aug 2004 10:59:33 -0000 1.3 --- boost/boost/integer_fwd.hpp 15 Aug 2004 08:25:11 -0000 *************** *** 12,19 **** #include <climits> // for UCHAR_MAX, etc. #include <cstddef> // for std::size_t ! #include <boost/config.hpp> // for BOOST_NO_INTRINSIC_WCHAR_T ! #include <boost/limits.hpp> // for std::numeric_limits namespace boost --- 12,20 ---- #include <climits> // for UCHAR_MAX, etc. #include <cstddef> // for std::size_t ! #include <boost/config.hpp> // for BOOST_NO_INTRINSIC_WCHAR_T ! #include <boost/cstdint.hpp> // for longlong ! #include <boost/limits.hpp> // for std::numeric_limits namespace boost *************** template < > *** 67,76 **** #ifdef ULLONG_MAX template < > ! class integer_traits< long long >; template < > ! class integer_traits< unsigned long long >; #endif --- 68,77 ---- #ifdef ULLONG_MAX template < > ! class integer_traits< longlong >; template < > ! class integer_traits< ulonglong >; #endif Index: boost/boost/limits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/limits.hpp,v retrieving revision 1.11 diff -c -p -r1.11 limits.hpp *** boost/boost/limits.hpp 10 Aug 2004 12:53:33 -0000 1.11 --- boost/boost/limits.hpp 15 Aug 2004 08:25:12 -0000 *************** *** 12,17 **** --- 12,18 ---- #define BOOST_LIMITS #include <boost/config.hpp> + #include <boost/cstdint.hpp> #ifdef BOOST_NO_LIMITS # include <boost/detail/limits.hpp> *************** *** 25,31 **** #ifdef BOOST_HAS_MS_INT64 # define BOOST_LLT __int64 #else ! # define BOOST_LLT long long #endif namespace std --- 26,32 ---- #ifdef BOOST_HAS_MS_INT64 # define BOOST_LLT __int64 #else ! # define BOOST_LLT longlong #endif namespace std Index: boost/boost/iterator/counting_iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/counting_iterator.hpp,v retrieving revision 1.5 diff -c -p -r1.5 counting_iterator.hpp *** boost/boost/iterator/counting_iterator.hpp 26 Jul 2004 00:31:59 -0000 1.5 --- boost/boost/iterator/counting_iterator.hpp 15 Aug 2004 08:25:14 -0000 *************** *** 6,11 **** --- 6,12 ---- # define COUNTING_ITERATOR_DWA200348_HPP # include <boost/iterator/iterator_adaptor.hpp> + # include <boost/cstdint.hpp> # include <boost/detail/numeric_traits.hpp> # include <boost/mpl/bool.hpp> # include <boost/mpl/if.hpp> *************** namespace detail *** 57,67 **** # if defined(BOOST_HAS_LONG_LONG) template <> ! struct is_numeric<long long> : mpl::true_ {}; template <> ! struct is_numeric<unsigned long long> : mpl::true_ {}; # endif --- 58,68 ---- # if defined(BOOST_HAS_LONG_LONG) template <> ! struct is_numeric<longlong> : mpl::true_ {}; template <> ! struct is_numeric<ulonglong> : mpl::true_ {}; # endif Index: boost/boost/numeric/interval/detail/ppc_rounding_control.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/interval/detail/ppc_rounding_control.hpp,v retrieving revision 1.3 diff -c -p -r1.3 ppc_rounding_control.hpp *** boost/boost/numeric/interval/detail/ppc_rounding_control.hpp 19 Jul 2004 21:38:06 -0000 1.3 --- boost/boost/numeric/interval/detail/ppc_rounding_control.hpp 15 Aug 2004 08:25:18 -0000 *************** namespace interval_lib { *** 25,31 **** namespace detail { typedef union { ! long long int imode; double dmode; } rounding_mode_struct; --- 25,31 ---- namespace detail { typedef union { ! __extension__ long long int imode; double dmode; } rounding_mode_struct; Index: boost/boost/python/type_id.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/type_id.hpp,v retrieving revision 1.15 diff -c -p -r1.15 type_id.hpp *** boost/boost/python/type_id.hpp 26 Jul 2004 00:32:05 -0000 1.15 --- boost/boost/python/type_id.hpp 15 Aug 2004 08:25:20 -0000 *************** *** 11,16 **** --- 11,17 ---- # include <boost/operators.hpp> # include <typeinfo> # include <cstring> + # include <boost/cstdint.hpp> # include <boost/static_assert.hpp> # include <boost/detail/workaround.hpp> # include <boost/type_traits/same_traits.hpp> *************** BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(lon *** 100,106 **** // using Python's macro instead of Boost's - we don't seem to get the // config right all the time. # ifdef HAVE_LONG_LONG ! BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(long long) # endif # undef BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID # endif --- 101,107 ---- // using Python's macro instead of Boost's - we don't seem to get the // config right all the time. # ifdef HAVE_LONG_LONG ! BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(longlong) # endif # undef BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID # endif Index: boost/boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.18 diff -c -p -r1.18 wrap_python.hpp *** boost/boost/python/detail/wrap_python.hpp 26 Jul 2004 00:32:07 -0000 1.18 --- boost/boost/python/detail/wrap_python.hpp 15 Aug 2004 08:25:21 -0000 *************** *** 25,30 **** --- 25,31 ---- // which confuses Boost's config // #include <limits.h> + #include <boost/cstdint.hpp> #ifndef ULONG_MAX # define BOOST_PYTHON_ULONG_MAX_UNDEFINED #endif *************** typedef int pid_t; *** 86,92 **** # endif # define HAVE_LONG_LONG 1 ! # define LONG_LONG long long # endif # elif defined(__MWERKS__) --- 87,93 ---- # endif # define HAVE_LONG_LONG 1 ! # define LONG_LONG longlong # endif # elif defined(__MWERKS__) Index: boost/boost/spirit/phoenix/operators.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/spirit/phoenix/operators.hpp,v retrieving revision 1.7 diff -c -p -r1.7 operators.hpp *** boost/boost/spirit/phoenix/operators.hpp 28 Jul 2004 01:57:45 -0000 1.7 --- boost/boost/spirit/phoenix/operators.hpp 15 Aug 2004 08:25:27 -0000 *************** *** 23,28 **** --- 23,29 ---- #include <boost/spirit/phoenix/actor.hpp> #include <boost/spirit/phoenix/composite.hpp> #include <boost/config.hpp> + #include <boost/cstdint.hpp> /////////////////////////////////////////////////////////////////////////////// namespace phoenix { *************** template <> struct rank<long> *** 373,380 **** template <> struct rank<unsigned long> { static int const value = 100; }; #ifdef BOOST_HAS_LONG_LONG ! template <> struct rank<long long> { static int const value = 110; }; ! template <> struct rank<unsigned long long> { static int const value = 120; }; #endif template <> struct rank<float> { static int const value = 130; }; --- 374,381 ---- template <> struct rank<unsigned long> { static int const value = 100; }; #ifdef BOOST_HAS_LONG_LONG ! template <> struct rank<boost::longlong> { static int const value = 110; }; ! template <> struct rank<boost::ulonglong> { static int const value = 120; }; #endif template <> struct rank<float> { static int const value = 130; }; Index: boost/boost/spirit/utility/chset.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/spirit/utility/chset.hpp,v retrieving revision 1.6 diff -c -p -r1.6 chset.hpp *** boost/boost/spirit/utility/chset.hpp 9 Jul 2004 08:28:06 -0000 1.6 --- boost/boost/spirit/utility/chset.hpp 15 Aug 2004 08:25:27 -0000 *************** *** 14,19 **** --- 14,20 ---- #include <boost/shared_ptr.hpp> #include <boost/spirit/core/primitives/primitives.hpp> #include <boost/spirit/utility/impl/chset/basic_chset.hpp> + #include <boost/cstdint.hpp> /////////////////////////////////////////////////////////////////////////////// namespace boost { namespace spirit { *************** chset_p(unsigned long ch) *** 164,177 **** #ifdef BOOST_HAS_LONG_LONG ////////////////////////////////// ! inline chset<long long> ! chset_p(long long ch) ! { return chset<long long>(ch); } ////////////////////////////////// ! inline chset<unsigned long long> ! chset_p(unsigned long long ch) ! { return chset<unsigned long long>(ch); } #endif /////////////////////////////////////////////////////////////////////////////// --- 165,178 ---- #ifdef BOOST_HAS_LONG_LONG ////////////////////////////////// ! inline chset<longlong> ! chset_p(longlong ch) ! { return chset<longlong>(ch); } ////////////////////////////////// ! inline chset<ulonglong> ! chset_p(ulonglong ch) ! { return chset<ulonglong>(ch); } #endif /////////////////////////////////////////////////////////////////////////////// Index: boost/boost/type_traits/is_convertible.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_convertible.hpp,v retrieving revision 1.25 diff -c -p -r1.25 is_convertible.hpp *** boost/boost/type_traits/is_convertible.hpp 6 Jan 2004 13:37:10 -0000 1.25 --- boost/boost/type_traits/is_convertible.hpp 15 Aug 2004 08:25:29 -0000 *************** *** 22,27 **** --- 22,29 ---- # include "boost/type_traits/is_void.hpp" #endif + #include "boost/cstdint.hpp" + // should be always the last #include directive #include "boost/type_traits/detail/bool_trait_def.hpp" *************** BOOST_TT_AUX_BOOL_TRAIT_DEF2(is_converti *** 260,266 **** TT_AUX_IS_CONVERTIBLE_SPEC_2(F,short) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,int) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long) \ ! TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long long) \ /**/ # define TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(F) \ --- 262,269 ---- TT_AUX_IS_CONVERTIBLE_SPEC_2(F,short) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,int) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long) \ ! TT_AUX_IS_CONVERTIBLE_SPEC(F,longlong) \ ! TT_AUX_IS_CONVERTIBLE_SPEC(F,ulonglong) \ /**/ # define TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(F) \ Index: boost/boost/type_traits/is_integral.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_integral.hpp,v retrieving revision 1.8 diff -c -p -r1.8 is_integral.hpp *** boost/boost/type_traits/is_integral.hpp 1 May 2004 10:32:58 -0000 1.8 --- boost/boost/type_traits/is_integral.hpp 15 Aug 2004 08:25:29 -0000 *************** *** 10,15 **** --- 10,16 ---- #define BOOST_TT_IS_INTEGRAL_HPP_INCLUDED #include "boost/config.hpp" + #include "boost/cstdint.hpp" // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" *************** BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_inte *** 57,64 **** #endif # if defined(BOOST_HAS_LONG_LONG) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned long long,true) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,long long,true) #elif defined(BOOST_HAS_MS_INT64) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned __int64,true) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,__int64,true) --- 58,65 ---- #endif # if defined(BOOST_HAS_LONG_LONG) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,ulonglong,true) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,longlong,true) #elif defined(BOOST_HAS_MS_INT64) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned __int64,true) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,__int64,true) Index: boost/boost/type_traits/type_with_alignment.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v retrieving revision 1.24 diff -c -p -r1.24 type_with_alignment.hpp *** boost/boost/type_traits/type_with_alignment.hpp 26 Jan 2004 12:20:03 -0000 1.24 --- boost/boost/type_traits/type_with_alignment.hpp 15 Aug 2004 08:25:30 -0000 *************** *** 8,13 **** --- 8,14 ---- #ifndef BOOST_TT_TYPE_WITH_ALIGNMENT_INCLUDED #define BOOST_TT_TYPE_WITH_ALIGNMENT_INCLUDED + #include "boost/cstdint.hpp" #include "boost/mpl/if.hpp" #include "boost/preprocessor/list/for_each_i.hpp" #include "boost/preprocessor/tuple/to_list.hpp" *************** typedef int (alignment_dummy::*member_fu *** 43,49 **** #ifdef BOOST_HAS_LONG_LONG #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ 12, ( \ ! char, short, int, long, long long, float, double, long double \ , void*, function_ptr, member_ptr, member_function_ptr)) #else #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ --- 44,50 ---- #ifdef BOOST_HAS_LONG_LONG #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ 12, ( \ ! char, short, int, long, longlong, float, double, long double \ , void*, function_ptr, member_ptr, member_function_ptr)) #else #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \

6 16

Building Boost with PathScale compiler
by Richard Hadsell 03 Sep '04

03 Sep '04

I am trying to build the Boost 1.31.0 libraries on an AMD Opteron platform using PathScale C++ 1.2. There is no toolset for this compiler, which looks something like a MipsPro compiler and something like a g++ compiler. Has anyone created a toolset for it? If not, how do I build a new toolset, or is there an easier way to build and install the libraries? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 5

RE: [boost] Java style GUI in C++
by Hurd, Matthew 03 Sep '04

03 Sep '04

> Behalf Of David Turner > Sent: Friday, 20 August 2004 3:32 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Java style GUI in C++ > > > I am currently designing a GUI framework in C++ (initially > > targeting the > > Windows platform) that uses a model similar to that which > > Java uses in it's > > AWT and Swing libraries. Specifically: > > [snip] > > > I would appreciate comments and ideas as to what people would > > like out of a > > GUI framework, especially one that will be multi-platform. > > > > Boost-style C++ GUI library utilizing boost::signals and with a nice way > of handling message loops: > > http://cxxgui.sf.net/ Looks like a very nice conservative approach. I think you're wise to keep it simple and take a conservative c++ approach. Only trouble is it still feels like a lot of other things just shines a bit brighter and has cleaner lines. However I must say I've never seen a UI lib I've been happy with. Nor have I written one, or infrastructure that uses one, that I've been fond of. I find even 200 lines of code (not cxxgui) for a simple split windows file explorer-like interface scary, but the sad thing is that it is a great improvement over the norm. Some rambling thoughts on things I'd like to see are: 1. run-time and compile-time configurability, especially with some like compile time specification language like layout capability. There was some talk about this and some suggestions previously on this list. Marrying this to run-time would be interesting. Perhaps at compile time you can decide if there is an explicit handling method and if not call something with your source and event type that will dispatch. However this would lock you in at run-time if did this as a compile time metaprogramming thing that ending up optimizing to a function call equivalent but perhaps both options are appropriate... 2. reverse structural inheritance of events handler equivalents. Widgets are composed of other widgets. A window may handle the click, or prevent it, for a child. You can attach a handler for a named event at any point in the composition / structural hierarchy, it doesn't have to be the source, but is aware of it. Handling goes down the hierarchy to source. 3. get rid of the distinction between properties, events and methods. Consider a widget a functor with visual side affects. Consider it like a dataflow where properties being set, events and method calls are just messages coming into this node. Allows you to interpose handlers, recorders, do nice testing and all sorts. Draw backs are interoperability with initialization requirements of widgets. That is, some things are set at widget create time. But this might handled by avoiding by not changing such parameters and thus not needing to change, but if initialization only parameters of legacy components change, then destroy and recreate the component. 4. Structural context sensitivity, 4a inherit properties from your run-time structural parents, fonts, colours, whatever, perhaps from theme packages that are higher in the tree. The structural tree is used to find the appropriate handler for properties, events and methods (all one in the same) 4b Context sensitive addressing and sources. Just like event handling, property setting and method calls are sinks that are handled with structural sensitivity, sources, such as changing properties, data propagation flow out and can be addressed in a context sensitive manner. E.g. if you have a widget that is expecting an source for stock code, it should look up the structural hierarchy to find it, unless it is provided with an explicit mapping to a different source. Allow non UI components that can act as holders for properties (like a root blackboarding thingo (technical term) ) so that components can reflect context of non-parental nodes. 4c Context sensitive addressing. Want to be able to get the properties / sources of siblings, i.e. children of parents of yours. "Instrument" -> "maturity". You find the parent and then lock into its context for a piece of detail. 5. must be multiplatform, leveraging off something like wxwidgets like notus does for its implementation layer would probably be a good idea. 6. must have a wysiwyg designer (though I could live without it) (self hosting would be a neat goal) - integrating the compiler into this and being an ide would be nice - perhaps something like eclipse could help 6a Because of the run configurability of everything there is nothing to stop external descriptions of components, including the mapping of sources to sinks to capture most of the requirements. Obviously where code is needed you need code and an xml resource description will not help. 7. Should support run time type conversions to allow easy hooking up of stuff. Not sure how explicit or implicit this should be. A while ago I did something like this that also supported the dimensionality of the data so you could cut, slice and aggregate stuff easily between widgets. E.g. use the entire list, the selected items, etc... would take some kind of multidimensional iterator thing I guess. Allows some sophisticated run-time modelling capabilities. See the data in a grid, or a list control, a combo, .... With this kind of structure you should be able to compose widgets hierarchies that have awareness of the others around them and will have reasonable normal functionality without too much coding at all. Supporting this at run time as well allows you to have some nice drag / drop or otherwise dynamic configurability. Have some that get a list of strings, displays it in a list. Click on a list item and a chart and grid automatically updates. A detailed pane of items relevant to the first click docked at the side updates. The exit item in the menu does the default behaviour of shutting down the application. My goal is that this should be possible with out an enormous number of lines of code. Structurally specify it. Use context sensitivity, standardish workflows and data set handling / iterator capabilities to avoid code. Thwack custom events in where needed. Been thinking about this for years and have implemented various systems that do bits of this approach. Enough to know it works pretty well. It has always been too much work to chew on as a generic solution though... $0.005, Matt. Side issue: resizing / device independence. Problem with swing / wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen. This is often the issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel ( I really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize. Also for device independence you might be able to target a different device by using a capability set where controls map to other controls for that device, they just have to handle the same sources and sinks for their node, i.e. have the same conceptual support. Perhaps that be a nice level of indirection to solve problems. Use a tree control, grid or list or whatever, just don't specific which. The platform configuration maps in the explicit control. Is you use a more refined control that is not available on that specific platform, you can substitute a generic one based on a substitutability principle (like Liskov SP), or perhaps it is an error (perhaps the design can specific the functionality that must exist for the there to be no error). A thin client approach to this would be even nicer, separate the visual aspects from the data it refers to by protocol and/or method call so that interesting thin / thick / adaptive clients can be built. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

6 17

compile-time variables
by Goran Mitrovic 03 Sep '04

03 Sep '04

I've got a question. Is a compile-time variables concept known? It would be a set of macros that would allow assigning and changing a number assigned to a variable's name. Such variable would be considered as a constant from template argument's perspective, for example. One of the usage for such classes I have in mind would be the painless type registration of typeof macro, for example...

6 8

An alternative typeof macro
by Daniel James 03 Sep '04

03 Sep '04

I've come up with an alternative way to invoke the typeof emulations that have been posted. It basically works by defining an iterator over the encoded type. Unfortunately, it can't be used inside a function, and is awkward to use in general, but has the advantage is that it only has to define the call to foo once, which might result in faster compile times. It could possibly also remove the limit on the complexity of the type. Arkadiy's version would require a some changes to do this, but I think Peder's could quite easily. Although I'm not sure as I've only had a brief look at his version. I've implemented it as a sort of typedef, which seems like the easiest way to use it. It's probably easier to understand the code than my explanation, so here it is. It's based on Arkadiy's version in the yahoo groups file section. #define BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) \ BOOST_PP_CAT(BOOST_TYPEOF_TYPEDEF_ITERATOR_##Name##_, __LINE__) #define BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ struct BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) { \ template <int pos> \ struct iterator { \ typedef boost::mpl::int_< \ sizeof(boost::type_of::foo<pos>(Expr))> type; \ typedef iterator<pos+1> next; \ }; \ }; #define BOOST_TYPEOF_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; #define BOOST_TYPEOF_TPL_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef typename boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; Here is an example of it's use: template <class Op> struct result_of_nullary_functor { static Op op; BOOST_TYPEOF_TPL_TYPEDEF(op(), type); }; struct g { int operator()(); }; BOOST_MPL_ASSERT_IS_SAME(result_of_nullary_functor<g>::type, int); I've only tested on the intel linux compiler. Daniel

5 38

Re: IOStreams formal review start
by Michel Decima 03 Sep '04

03 Sep '04

>The latest package can be found at the following >> locations: >> >>http://home.comcast.net/~jturkanis/iostreams/ The package avalaible on this page doesn't build with gcc-3.3 on linux and darwin. There are some compilation-time warnings and errors: boost/libs/io/src/file_descriptor.cpp: In member function `void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode, std::_Ios_Openmode)': boost/libs/io/src/file_descriptor.cpp:91: error: no matching function for call to `boost::io::file_descriptor_resource::open( const char*, int&, mode_t&)' boost/libs/io/src/file_descriptor.cpp:47: error: candidates are: void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16), std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16)) boost/libs/io/src/file_descriptor.cpp:68: warning: enumeration value `_M_ios_openmode_end' not handled in switch boost/libs/io/src/file_descriptor.cpp:68: warning: case value `8' not in enumerated type `_Ios_Openmode' /boost/libs/io/src/file_descriptor.cpp:68: warning: case value `16' not in enumerated type `_Ios_Openmode' boost/libs/io/src/file_descriptor.cpp:68: warning: case value `24' not in enumerated type `_Ios_Openmode' ... you may apply the patch file_descriptor-cpp.patch to solve the problem. The link of the shared libraries fails too, because the gzip and bzip2 libraries names are wrong in the file compression.jam (the common names are libz.so and libbz2.so on unix/darwin/solaris...): darwin-Link-DyLib-action bin/boost/libs/io/build/libboost_io.dylib/darwin/debug/shared-linkable-true/libboost_io-d-1_32.dylib ld: can't locate file for: -lzlib ld: can't locate file for: -llibbz2 The patch compression-jam.patch solves the problem, but it may break your build system on other platforms (I'm not a jam file expert yet ;) MD. Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

4 11