- Boost - lists.boost.org

[v2]command line argument feature treated as target
by Larry Evans 04 Sep '04

04 Sep '04

Based on the following example: borland/<runtime-link>static located at: http://boost.org/boost-build2/doc/html/bbv2.reference.commandline.html I tried the following: bjam --v2 gcc/\<link-runtime\>static error: Unable to find file or target named error: 'gcc/<link-runtime>static' error: referred from project at error: '.' I also tried <runtime-link> without success. I guessed <link-runtime> from looking at: tools/build/v2/tools/gcc.jam which contains: flags gcc.link OPTIONS <link-runtime>static : -static ; What am I doing wrong? TIA. Regards, Larry

1 1

Re: [boost.thread] Experimental alternative TLS implementation
by Tony Juricic 04 Sep '04

04 Sep '04

I just downloaded Roland's implementation and I quite like it. By the way, congrats Roland on resolving TLS callback issues for static link library for VC6 and VC7; after digging into it as I joined the group I was too busy but now I hope to have more time and, at least, help with more testing. While intentional TLS slot leak is not a big issue (one expects that OS will do proper cleanup on program exit) it may be confusing to the first-time reader who may have a hard time understanding the motivation for protecting programmers from some leaks, while leaving other leaks to the OS. Reference counting makes it quite clear to the reader what is intended by the code. I wonder what are current plans for the future of threads libray, after a lot of discussion about rewrite? My own perspecitive is colored by everyday practical use: for example, I never encountered any need for thread-specific pointer but I often had to pass a boolean to thread proc to make a thread stop. Consequently, and as I would like to use boost threads instead of my own concotion, I would like to see "thread stopping pattern", lacking better term and just for example, as the part of the interface. I understand these are difficult issues but after quite a few years of using threads I am not sure that I still find 'older' Java-like thread(s) interface particularly useful. Tony

2 2

[bbv1] MkDir rule broken on Win32!?
by Bertolt Mildner 04 Sep '04

04 Sep '04

When started form a Windows Commandline (cmd.exe) bjam tries to create existing directories and of curse failes to do so! For example when building boost::thread: ------------------------------------ ...found 205 targets... ...updating 20 targets... MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading-multi Ein Unterverzeichnis oder eine Datei mit dem Namen "..\..\..\bin\boost\libs\thre ad\build\boost_thread.dll\cw\\threading-multi" existiert bereits. mkdir "..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading- multi" ...failed MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threa ding-multi... ------------------------------------ (the german error-msg means "directory or file "..." allready exists") As this causes targets to be skipped this is getting pretty annoying ... As far as i understand the root of the problem is that the nativ "mkdir" on Win32 does not take any options to be quiet if the directory exists ("-p" on Unix). It looks like allyourbase.jam tries to address this in the MkDir rule, but fails to. Bertolt PS: I have tried to post this in gmane.comp.lib.boost.build but i always got mail that i should join <jamboost(a)yahoogroups.com>!

2 3

[utility] value_init fails on CW*
by Stefan Slapeta 04 Sep '04

04 Sep '04

see http://tinyurl.com/5639d Has anybody a solution for this? Seems that all CWs have problems with casts in combination with conversion functions. Stefan

4 4

Boost serialization: release configuration linker errors
by Robert Ramey 04 Sep '04

04 Sep '04

I assume you're using the version currently in the main CVS tree. Or are you using the version 1.31? I've always had this problem. It manifests itself differently with different compiliers. In often related to linkers removing "dead code" that really isn't dead - the linker isn't smart enough to see that in fact the code is used. One of the ways I've found to address this is to mark certain templates for export (dllexport). Unfortunately, the way of doing this varies from compiler to compiler. So, I occasionally re-run all tests in release mode to detect these problems. Usually this is enough. Recently, I've fixed up export to work regardless of idiosyncrasies of various compilers and I may have broken something. I'll retest and recheck this. Robert Ramey >Ive been using Boosts serialization library with MSVC 7.1 (the first time >that Ive used it). For most of my project I put the load / save function >declaration in the class header (the .h file) and the definitions in the >.cpp file VC 7.1 allows this for templated functions, unlike some older >compilers. In debug mode this compiled and linked fine except for abstract >base classes through trial and error I found that for abstract classes >the functions had to be defined in the .h file to avoid linker errors. >My project built fine in Debug mode and I then tried to compile / link it >in Release mode this threw up quite a few LNK2001 errors relating to just >a few of the serialization load / save functions in just some of the >classes most of the classes that declared the load / save functions >evidently linked fine (as they all did in Debug mode). After much double >checking of the compile / link project configurations I tried the >following: >1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the >.h files in which the load / save functions were not linking. On >recompiling / linking most of the linker errors were gone, but a few >remained. >2. For the remaining classes that were not still not linking, I moved the >load / save functions from the .cpp file into the .h file (these were not >abstract classes). This fixed the remaining linker errors and my >application compiled / linked / ran fine. >I can't see why this occurred. I havent checked yet (its very time >consuming to rebuild this application) but possibly option (2) would have >worked for all the affected classes. For most of this project, the load / >save functions remain defined in the .cpp file and clearly link fine in >both debug and release configurations. Before someone asks, I did complete >clean / rebuilds for both configurations anybody any ideas?

1 0

Porting to SCO Unix
by Davlet Panech 04 Sep '04

04 Sep '04

Good day, I'm trying to port Boost to SCO Unix using STLport and GNU Pth (a user-space Pthreads library), and gcc 2.95 controlled by a customized compiler driver (so some of the following observations may not be applicable to stock gcc users on this platform). Anyway, I've had a few problems that I'd like to report; I think at least some of them are worth correcting in future Boost releases: The following tests in libs/config/configure produce incorrect results: ** checking for pthread_exit in -lpthread... no This test tries to compile a C source file that prototypes "pthread_exit" as "char pthread_exit();". But my compiler driver always adds "-include <...>/pthread.h" to the command line, which includes a different, conflicting prototype for this function. I think the test ought to include <pthread.h> instead. ** checking pthread_yield... no This is correct, but I do have a pthread_yield_np() function, maybe we should look for it, too. ** checking std::basic_streambuf<wchar_t> ... OK I think this should fail if _STLP_NO_WCHAR_T is defined, which it is in my STLport configuration headers. This macro does not prevent one from instantiating basic_string<>, etc. with wchar_t, but it does disable explicit instantiations of these in STLport binaries. So basic_string<char> ends up being compiled into libstlport.so, while basic_string<wchar_t> doesn't. The macro also disables the typedefs (wstring, wcout, etc) and the wide char - related C headers (<cwchar>, <cwctype>). I really think Boost should disable all wide char stuff in this case. I also discovered some problems with Jamfiles (BTW what is Jamfile.v2? Is it useable? How does one use it?): tools/build/v1/allyourbase.jam, near line 574): rule CcMv is called but never defined. What does variable "RELOCATE" do in allyourbase.jam? It seems to indicate that the compiler doesn't support the -o switch, shouldn't this be defined in compiler-specific toolset files? Why is there no static version of Boost.Threads? I know this is required in Windows, but not if it's compiled on top of Pthreads on any platform (I'm using pthreads-win32 from Redhat, on Windows), right? The documentation (http://www.boost.org/more/getting_started.html#Build_Install) states that "[...] For toolsets that support it in Unix they will also have a full version extension (for example ".so.1.31.0")". But this does not seem to be the case. I ended up with "libboost_thread-gcc-mt-1_31.so" etc. using gcc toolset on SCO. Where are the ".so.1.31.0" versions? Maybe I'm missing some toolset settings. Also it seems that some of the .so files generated ought to be symbolic links, but are instead copies of one another. Where is this controlled? Do I need to edit/create some toolset file to replace "cp" with "ln -s"? If I pass -DNDEBUG to my source files that #include Boost headers, do I have to link with non-debug version of boost libs? How about multithreaded vs single-threaded configurations? For example, is it safe to link with MT Boost libs with non-MT programs using gcc/Linux? I know it makes a difference in Windows, but it should not matter on platforms where compiler runtimes don't differentiate between MT/non-MT, IMHO. That is, unless the Boost headers provide different declarations depending on the presence of some "MT" macro. This would be very unfortunate, because it's very easy to link with the wrong library and the compiler won't complain about it. It would be nice to have an option of not using the long "mangled" library names while installing. As a user I would expect a more customary convention for library names on UNIX-like systems, with only two variants, something like the following: libboost_foo.a libboost_foo.so.1.31.0 libboost_foo.so (symbolic link to libbost_foo.so.1.31.0) (... possibly more links depending on binary compatibility guarantees between the releases) both compiled with MT/non-debug configurations. Comments/suggestions? Thanks, D.

5 7

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

[boost] my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, & boost
by Thomas Xkey 04 Sep '04

04 Sep '04

my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, boost -------------------- Review Periods I would prefer to see a review period of 10-12 days [i like 12 days from a sunday thru the following weeks friday perspective.] The present period is just to short. Most of us are overworked, underpaid, and dont always care to look at works in progress of others until things are a bit more "finalized" and "stable" so to speak. Hence we may not peek early enough at a library to provide good guiding input but we can toss our 2 cents in during the final review melee lol :) ---------------------- Documentation !!! Please utilize & include more diagrams & examples in your library documentation!!!! Compare & contrast with existing implementations that are lacking, State why they are lacking, what they are lacking, with what the proposed library implementation presents to fill the missing pieces, how it is better in some respects to anything it "replaces", and why it replaces some typical library code currently in widespread use or fills a gaping hole. --------------------- moreIO & IOstreams Daryls rationales and motivations are completely lacking in depth and sharpness. The summarys are so general and non-delineated that they are no help to me in discerning the clarity of what he proposes as benefits and properties of his library. an example :: this snippet is from the wrapping streams rationale "The Standard stream base class templates are designed to use stream buffers with an independent lifetime, and include functionality for switching what stream buffer is used." Yes, but are you just reiterating something everyone already knew, do you feel that is a bad thing or a good thing? There are no "supporting" remarks no remarks of impact laden with design criteria or shortcomings. Not coming from a circle where I/O is the most important aspect of my development I am not an "expert" on streams. So reading the documentation which purports to support and sing the praises of this libary was completely useless to me. I had better luck just looking at the code. When i think rationale and motivation i think objectivity must be forefront. Even a simple outline or summary of design criteria clearly delineated and put forth makes it easier to read an overall document of this nature. Project managers and others working on a project need to see clarity of thought, clear cut guidelines, inputs, outputs, and the design that goes in the middle. I am sure as most have laid out the design of their libraries they have ad-hoc flowcharts, points pro & against certain features. You may wish to bring some of those out and flesh them into the documentation so that others can understand the motivations behind your design. It would surely make life easier for anyone reviewing the code to speak to the issues addressed and/or generated by the code. It would elevate the efficiency of the process. Now that isnt to say some fluff isnt nice *grin* null_stream yes. something missing that is necessary. would prefer though to see it constructed using the concept of sinks & sources from the turkanis IO library up for review. streambuf_wrapping I would vote no on this until it is cleaned up and a better rationale presented to me. array_stream maybe. you would have to convince me this buys something appreciable in an efficiency concern over the way the standard streams presently operate. perhaps give me 2 examples a non-I/O expert such as myself could "grasp" concretely. pointer_stream no. the concept would be better implemented again using turkanis IO lib up for review. value_stream no. this specialized stream doesnt seem all that beneficial to stuff it in to a library. if the appl programmer wishes to he can easily fabricate his own. [u have a value_stream for just a char, what about for just a user_type, for just a "string" etc why not a "pair_stream" that would return a pair of values etc ad nauseum] now that isnt to say such a stream cannot be useful on rare occasion but again it would be fairly easy to implement using an appropiate set of "sources/sinks" that could be implemented in turkanis IO lib. -------- Now having said that it may seem like i'm being a pita and trying to tear your hard work into pieces, but i think you have some good "ideas" but perhaps the implementation should come off differently. I think if you perhaps had looked into the other IO lib that jason was developing at the time you 2 coudl have had a meeting of the minds and come up with some great ideas and both done some things differently. This library is a software community and with scales ever growing great ideas shouldnt necessarily be pondered on by lone rocket scientists squirreled away with their code and not picking their heads up to look around and talk (though we all do accept input i'm sure, and even act upon some of it, it seems more often than not we do not communicate as much as we should in the "early stages" and leave it all for the end-game) Perhaps you 2 should get together and collaborate. [now there's a concept] --------- Now my rationale : We all agree a layered/tiered approach to complex software is the best way to go. It allows more degrees of freedom, greater re-user, greater specialization as well, and greater replacement of parts. It does push or mutate the complexity more from a particular piece of complex code into the complexity of "simpler components" with more complex entanglement, more complex communication and cooperation at times. This is why i would much prefer with some efficiency clean-ups & improvements that the turkanis library be used as a basis(implementation-wise) for any of the moreIO features accepted. I like the small raw nature & flexibility of the simpler "building pieces" at the bottom of this IO pyramid I can then compose my complex streams on these "sinks & sources" As to the turkanis library, I have not had as much time to examine it. I am not sure the merit of Carlo Woods remarks but from a 1st perusing I think i agree with him. I also partly agree with Daryl about some efficiency concerns and bloat concerns but i think with everyones assistance those can be hammered out or down in size. ---------------- 2 cents on names for manipulators & readability These comments are due to the disagreement some seem to have over things like newl versus newlines and proliferation of manipulators and whether some should be placed in the library and others left to appl developers to produce on their own. A) Do not have both a singular and plural version instead just opt for the plural version - the singular use could be the default and is typically understood as much by viewing code as well. that is to say dont have a skipline & skiplines instead just opt for skiplines skiplines(x) would skip x lines [thus for one line x==1] B) The use of underscores to break up and make names more readable for classes, vars & funcs is a good thing. Someone tried to bring up the point that the standard streams library was such n such a way well that doesnt just mean it was the best way in terms of its naming schema C) I prefer slightly longer more meaningful names getting away from obfuscation so when it comes to newl or nl i'd really prefer newline. i think most of us can type sufficiently fast and we are thinking "newline" in our heads we can type it with barely any speed difference nor loss in efficiency but it makes for a lot better readability than "nl" (my cognitive web sees "nl" as netherlands these days lol) now that isnt to say this should be taken to the maximum in the opposite direction!! macros/functions like "min" & "max" are plenty self-explanatory. Ok, so that was more like 3 cents on this topic :) ---------------- fsm This library seems & acts more like a "simulator" than an "efficient finite state machine". There is a very high level functionality tied into (possibly) a bare-bones base... not properly tiered or layered approach. Functionality is wrapped into one library rather than separated into add-on libraries with additional functionality. It doesn't seem to scale well even according to the author(s)? (most fsms a computer scientist would deal with encompass 100s to 1000s of states with as many different transitions possible) I would strongly urge something more efficient and bare bones along the lines of http://www.research.att.com/sw/tools/fsm/ take on the mantle of an "fsm" library in boost upon which coarse-grained objects can be simulated from above. would prefer this 'currently proposed' fsm to take on its true stance perhaps attaching the nomenclature of "hlfsm" --> "high level fsm". Due to its greater abstractions, fluffy aggregations and bulk in nature it isnt "efficient". If a library isnt efficient for its purpose or intended purposes then it will be under-utilized. I could never use this one as it is evolving away from an efficient fsm into more of a large coarse simulator. [now if i had need of that it would be great] This library seems more intended for simulation at a higher level than at a more simplistic state/event transition approach. Yes i am biased coming from an algorithms and mathematical background; I am more of a computer scientist who practices softare engineering than most application programmers who just want a product out the door and efficiency goes out the window. Can we adjust this library conceptually into a cleaner bare-bones fsm at one layer and then interject the higher level simulation aspects along with the ability to automatically produce code etc. [Canned automatically generated code is usually not so hot. In fact it rather bites. Any decent programmer can still out-optimize todays compilers based on intimate knowledge of their code & algorithms even on todays complex processors. Given that compilers have thousands of man-years of code & know-how how does one expect this fsm library to generate decent code or is it intended for someone who cannot program?] ------------------ On the subject of move_ptr How about self_consistent_ptr invar_postmove_ptr I must be a freak because "selfish_ptr" grows on me it instantly says "mine mine all mine i can move through proustian circles but it is still my object" moveptr is something i've seen in untold reams of computational code along with leftptr, rightptr, and currptr & variants thereof; so i'm really hoping someone comes up with better nomenclature to settle on :) -------------------- Lastly an area where I dont want to get into because no one manages software well lol The topic of boost - releases, the GABB (gawd almighty boost book), documentation & structure 1) is it possible to go with both a long-term more flexible scheme for release-dates along with a more rigid short-term window as we slide forward into the future? Note the famous M$ vaporware long-term software & release info is not the approach i'm talking about lmao more like "tentative" long range plans [the reiser boys(release 4 is out now) have done a good job with their long term feature & release targets] but sticking to your guns short term with branches rather than how it has been this "special circumstance" time I think most are of the opinion from the app & devel point of view that more "dot" releases are better rather than fewer. (of course within reason!) Presently it seems haphazard with cvs patch check-ins and outs and then fudging jam files, regression test failures and ... seems like by waiting so long between "dot" releases is NOT buying you any more efficiency or salvation from bug issues any more than having more frequent releases would but some of the libs within would be able to rev and get feedback faster. The compilation (syntax) issues are one thing but seems like some of the libs would benefit from hitting the streets when the developers have stomped most of their bugs. It becomes time the hapless consumer of the lib can play their guinea pig role and dive into their playground with much zeal. So i dont see any "good solid" argument as to why releases are so far apart rather than a bit more "reasonably timely" [ok well integration testing when a MAJOR lib-wide wholescale change occurs is one reason why a particular release would take forever :)] NOW if it was an end-user , we all know how psychologically important keeping the release #s down and only coming out with a major rev every few millenia(hic sarcasm hic) is great for business [hmm IE 6 hmmm how many years b4 IE 7? lolol] We devels are made of more sterner stuff though :) 2) Is the flippin book going to be available as ps or pdf since I dont feel the need to kill more trees just to have another book about programming yada yada yada collecting dust on my bookshelves? most programming books are so light on substance and full of wasted verbiage they could do without it isnt funny. [my fave c++ book was the annotated reference can ya tell? lol] If not, would at least the chapter summaries along with toc, glossary, and appendices be available for d/l? I much prefer cutting to the chase to get to information 3) Can someone get the documentation into a more consistent format along with the information at boost.org /boost-consulting site? as someone else pointed out the review information at boost.org was shall we say "slightly dated" 4) Structure ... oh forget it i've rambled enough on this random walk C++ya, xkey

4 3

C++ Random Container
by Joel Young 04 Sep '04

04 Sep '04

I would be very interested in such a container. Even more, I would be interested in a priority queue which allows one to specify a distribution based on either the order statistic or the priority. The head/front/pop operator would then select based on the distribution. Joel

2 3

Re:[boost] Re: IOStreams review
by Robert Ramey 04 Sep '04

04 Sep '04

>"Dietmar Kuehl" <dietmar_kuehl(a)yahoo.com> wrote in message >news:200409031908.13053.dietmar_kuehl@yahoo.com... >|On the ACCU 2003 conference JC (I can figure out the full name if >|necessary...) presented the idea for creating filters which I really >|liked. It looked something like this: >|filter_stream out(tee(std::cout) | encode | gzip | file("some file")); >|This would create a stream which writes everything to 'std::cout' >|and also encodes the stuff before sending it on to compress it and >|finally write it to the file. I like this notation... >I second that FWIW - I do NOT like this idea. I concede its mostly a matter of taste but I think it adds another layer of syntax. I think the original .. push, etc is ok. But my preference would be for filter_stream out( tee( std::out, encode( gzip( file("somefile") ) ) ) ) I'm sure people are going to love this idea. Robert Ramey

3 2