July 2004 - Boost - lists.boost.org

multi_array: a patch for SGI MIPSpro
by Synge Todo 15 Jul '04

15 Jul '04

Dear Boosters, About two days ago, the following lines are added in boost/multi_array.hpp (in order to increase the overload resolution of the constructor???). *************** *** 93,98 **** --- 93,102 ---- #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING , typename detail::multi_array::disable_non_sub_array<ExtentList>::type* = 0 #endif + , typename + boost::disable_if_c< + boost::is_same<ExtentList,multi_array>::value + >::type* = 0 ) : super_type((T*)initial_base_,extents) { boost::function_requires< However, it breaks e.g. SGI MIPSpro, since it does not support SFINAE. (boost/config/compiler/common_edg.hpp defines BOOST_NO_SFINAE.) I'm very happy, as a workaround, if the lines could be wrapped "#ifndef BOOST_NO_SFINAE", like #ifndef BOOST_NO_SFINAE , typename boost::disable_if_c< boost::is_same<ExtentList,multi_array>::value >::type* = 0 #endif Any better idea? Synge

2 1

RE: [boost] Re: method deduction (on vc?)
by Max Khesin 15 Jul '04

15 Jul '04

> Max Khesin <MKhesin(a)liquidnet.com> writes: > > > But not (from your phrasing) function members? > > I don't know about those; I haven't tried to find workarounds > for that. > > FWIW, designs that depend on member detection are often flawed from a > generic programming POV. You can get accidental conformance, and > especially if there's no way to explicitly say what the member means > (e.g. with a traits specialization), you'll be out-of-luck. Well, this is my intent, just for the record, (perhaps there are other techniques that apply): I want a generic dispatch function that accepts some "Message", makes it into a concrete class and dispatches it to the overloaded handler function: // A, B, C, ... derived from some Base template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { h.onMsg(A(m)); }else if(m.getName()=="B") { h.onMsg(B(m)); } // etc } the handler class has to implement overloaded handler functions for the the classes it is interested in and (right now) a 'catch-all' handler for the Base& (to insure that the thing compiles). Ideally I would like to eliminate this requirement by detecting whether HandlerT has a onMsg(T&) and providing a no-op for that (via another level of indirection), some thing like: template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { dispatcher<HAS_METH(h, void, onMsg, A&)>::dispatch(A(m)); }else if(m.getName()=="B") { dispatcher<HAS_METH(h, void, onMsg, B&)>::dispatch(A(m)); } // etc } This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

[preprocessor] Sun Studio 9 Early Access regressions
by Christopher Currie 15 Jul '04

15 Jul '04

Can anyone lend assistance in debugging the Sun regressions for Boost Preprocessor? The early access edition of the Studio 9 compiler is failing on BOOST_PP code that compiles just fine under earlier versions. The code that's failing appears to relate to the expansion (or lack thereof) of the macros that implement BOOST_PP_WHILE. I'm continuing to investigate, but since I'm unfamiliar with what the macros are *supposed* to do, I'm hoping someone can spot the trouble more quickly than I can. I've attached the preprocessed code from libs/preprocessor/test/control.cpp. Thanks in advance, Christopher -- Christopher Currie <codemonkey(a)gmail.com> #1 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/add.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/dec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/config/config.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/inc.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/cat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/debug/error.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/auto_rec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/adt.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/is_binary.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/check.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/compl.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/eat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/reverse.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bitand.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/detail/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bool.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/elem.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/deduce_d.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_if.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/if.hpp" #1 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" #1 "/opt/SUNWspro/prod/include/CC/std/cstdio" #1 "/usr/include/sys/feature_tests.h" #13 "/usr/include/sys/feature_tests.h" #pragma ident "@(#)feature_tests.h 1.18 99/07/26 SMI" #1 "/usr/include/sys/isa_defs.h" #9 "/usr/include/sys/isa_defs.h" #pragma ident "@(#)isa_defs.h 1.20 99/05/04 SMI" #158 extern "C" { #380 } #18 "/usr/include/sys/feature_tests.h" extern "C" { #181 } #1 "/usr/include/iso/stdio_iso.h" #32 "/usr/include/iso/stdio_iso.h" #pragma ident "@(#)stdio_iso.h 1.2 99/10/25 SMI" #1 "/usr/include/sys/va_list.h" #9 "/usr/include/sys/va_list.h" #pragma ident "@(#)va_list.h 1.12 99/05/04 SMI" #22 extern "C" { typedef void * __va_list ; } #1 "/usr/include/stdio_tag.h" #9 "/usr/include/stdio_tag.h" #pragma ident "@(#)stdio_tag.h 1.3 98/04/20 SMI" extern "C" { #21 typedef struct __FILE __FILE ; } #1 "/usr/include/stdio_impl.h" #9 "/usr/include/stdio_impl.h" #pragma ident "@(#)stdio_impl.h 1.8 99/06/10 SMI" #14 extern "C" { #22 typedef int ssize_t ; #38 struct __FILE { ssize_t _cnt ; unsigned char * _ptr ; unsigned char * _base ; unsigned char _flag ; unsigned char _file ; unsigned __orientation : 2 ; unsigned __ionolock : 1 ; unsigned __filler : 5 ; } ; } #49 "/usr/include/iso/stdio_iso.h" extern "C" { #59 typedef long long __longlong_t ; #70 namespace std { typedef __FILE FILE ; #83 typedef unsigned int size_t ; typedef long fpos_t ; } #147 extern __FILE __iob [ 20 ] ; #159 namespace std { extern int remove ( const char * ) ; extern int rename ( const char * , const char * ) ; extern FILE * tmpfile ( void ) ; extern char * tmpnam ( char * ) ; extern int fclose ( FILE * ) ; extern int fflush ( FILE * ) ; extern FILE * fopen ( const char * , const char * ) ; extern FILE * freopen ( const char * , const char * , FILE * ) ; extern void setbuf ( FILE * , char * ) ; extern int setvbuf ( FILE * , char * , int , size_t ) ; extern int fprintf ( FILE * , const char * , ... ) ; extern int fscanf ( FILE * , const char * , ... ) ; extern int printf ( const char * , ... ) ; extern int scanf ( const char * , ... ) ; extern int sprintf ( char * , const char * , ... ) ; extern int sscanf ( const char * , const char * , ... ) ; extern int vfprintf ( FILE * , const char * , __va_list ) ; extern int vprintf ( const char * , __va_list ) ; extern int vsprintf ( char * , const char * , __va_list ) ; extern int fgetc ( FILE * ) ; extern char * fgets ( char * , int , FILE * ) ; extern int fputc ( int , FILE * ) ; extern int fputs ( const char * , FILE * ) ; #203 extern char * gets ( char * ) ; extern int puts ( const char * ) ; extern int ungetc ( int , FILE * ) ; extern size_t fread ( void * , size_t , size_t , FILE * ) ; extern size_t fwrite ( const void * , size_t , size_t , FILE * ) ; extern int fgetpos ( FILE * , fpos_t * ) ; extern int fseek ( FILE * , long , int ) ; extern int fsetpos ( FILE * , const fpos_t * ) ; extern long ftell ( FILE * ) ; extern void rewind ( FILE * ) ; #219 extern void perror ( const char * ) ; extern int __filbuf ( FILE * ) ; extern int __flsbuf ( int , FILE * ) ; #278 } #288 namespace std { inline int getc ( FILE * _p ) { return ( -- _p -> _cnt < 0 ? __filbuf ( _p ) : ( int ) * _p -> _ptr ++ ) ; } inline int putc ( int _x , FILE * _p ) { return ( -- _p -> _cnt < 0 ? __flsbuf ( _x , _p ) : ( int ) ( * _p -> _ptr ++ = ( unsigned char ) _x ) ) ; } } #308 namespace std { inline int getchar ( ) { return getc ( ( & __iob [ 0 ] ) ) ; } inline int putchar ( int _x ) { return putc ( _x , ( & __iob [ 1 ] ) ) ; } } #319 namespace std { inline void clearerr ( FILE * _p ) { _p -> _flag &= ~ ( 0040 | 0020 ) ; } inline int feof ( FILE * _p ) { return _p -> _flag & 0020 ; } inline int ferror ( FILE * _p ) { return _p -> _flag & 0040 ; } } #336 } #25 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" namespace std { } using namespace std ; int main ( void ) { printf ( "pass " "11:06:52" ) ; return 0 ; } #20 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" typedef int test_20 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_21 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_23 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_24 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_26 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_27 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_29 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_30 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_35 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #35 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #35 ) ( PRED , OP_1 , 50 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_40 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #40 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #40 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_41 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #41 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #41 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ;

3 5

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: > What I see is that the serialization library defines "std::wcslen" in > "wcslen.h", > even though there's a perfectly good one already available. This is > conditionalized > off of BOOST_NO_CWCHAR, which leads me to think that this flag is > wrong in the darwin config. > So, I moved it so that it is only set when building on GCC 2.95.x. Interesting. I examined the config files for macos and was left confused. It seemed to me that gcc 3.3 left BOOST_NO_CWHAR undefined while macos overrode that with a define. But then the regex test runs a config test whose results suggest that BOOST_NO_CWCHAR is not defined so I'm left absolutely and totally confused. On top of this I now have some doubts about my inclusion of my own definition of wcslen which I now suspect may have been the wrong response to some other question. I'm not sure if Darwin and macos are the same thing. So your observations and experiments are very opportune. I want to take a little time to check my usage/definition of wcslen ('til tomorrow). If you want to double check the config for gcc/macos/Darwin that would be good as well. I will also check the test results and make any other indicated corrections as these issues are orthogonal to this current wcslen one. Thanks for all your help. Robert Ramey

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 15 Jul '04

15 Jul '04

Mike, IMHO your comments below justifying different mutex types make sense. However, I feel that you look at the problem from the *implementor* point of view that is drastically different from the view of the library *user*. And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by. I feel that for the user having different types of mutexes is inconvenient and unnecessary restricting. It is because when I create a mutex, I identify a resource that I want to serialize access to (it's a strategic decision in military terms :-) ). However, *how* I serialize the access (via blocking lock or try/timed locks) is not generally known at the time and will be defined on the case-by-case basis (when I'll be actually creating appropriate locks -- it's a tactical decision). A typical and very basic application I am working on discriminates two threads (and, therefore the appropriate mutex) -- the first always applies a blocking lock (scoped_lock) and the other thread only steps in through the successful try-lock. Having additional (and maybe unused) data in a mutex does not seem like a huge problem (as long as it does not impose performance penalties) -- memory is cheap and mutexes are not usually created in huge numbers. More so, I believe in boost there are techniques/classes minimizing waste. Best, V. > > Now that we got rid of the excess locks, how about doing the same with > the > > mutexes? > > I had considered this, but there does seem to be some benefit in having > separate mutex types, which is what I assume led to there being three > mutex types and three lock types in the original design. You've noted > these reasons below, but I'll reiterate: > > * On pthreads, the timed mutex requires an additional data member, > (condition variable) to handle cases when pthreads_timedlock isn't > supported. > > * On WinNT, the timed mutex operations require a win32 mutex object, > while the mutex and try mutex can use a win32 critical section. > > * On Win9x, the timed mutex and try mutex operations require a win32 > mutex object, while the mutex can use a win32 critical section. > > In other words, on the most widely-used platforms, collapsing the mutex > types into one imposes some penalty (larger mutex object or more limited > implementation options) on users. Also (I ask, not as a hypothetical > question, but as a request for information): is there another platform > where combining the mutex types incurs a similar or worse penalty?

2 1

Is serialization going to be in 1.32?
by Jeff Garland 15 Jul '04

15 Jul '04

Awhile back we added code and tests in date_time for serialization of dates, times, durations, etc. The tests have been disabled since serialization wasn't in CVS. However, if serialization is going to be part of 1.32 I'd like to go ahead and turn on these date_time tests. Thoughts? Jeff

1 0

Program Options failures (and fixes)
by John Maddock 15 Jul '04

15 Jul '04

Vladimir, I have some fixes for the program_options library on Win32 for you, first off here's the problem: On Win32 you must use the a dynamic runtime if you are building or using a dll: if you don't do this then separate runtimes/memory managers etc get linked to each module and the result is almost always a runtime crash some point. However you are also using std::locale and so have added std::facet-support std::locale-support to your build requirements. Doing so however, causes the static runtime to be used, so you're in a bit of a catch-22 situation here I'm afraid. You've also failed to define BOOST_ALL_DYN_LINK when *using* your dll - this is causing the mscv link failures. The patches below address both of these issues, tested with: VC7.1: everything passes. VC7.0: everything passes except the tests that use \u (unsupported). Intel 8 on vc7.1: everything passes. Intel 7.1 on vc7.1 everything pases except the tests that use \u (unsupported). Borland 5.6.4: all tests pass. Borland 5.5.1: Internal compiler error in function from_8bit, haven't investigated further yet. The fact that these tests do pass with Intel, possibly means that std::facet-support could be deprecated - it looks like Intel have fixed that problem with their recent patches. However, you may still experience problems with Metrowerks - I think there is any way around this - the dll version of the library is going to be unusable with that compiler. One final thing: you declare the environ variable in your sources, which is leading to warnings from MSVC and Intel about conflicting dll-specifications for that variable, perhaps you should include the header required rather than defining the variable yourself (unistd.h when BOOST_HAS_UNISTD_H is defined, or stdlib.h on WIN32)? John Index: build/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/build/Jamfile,v retrieving revision 1.2 diff -u -r1.2 Jamfile --- build/Jamfile 18 May 2004 06:38:17 -0000 1.2 +++ build/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -21,7 +21,7 @@ <define>BOOST_ALL_DYN_LINK=1 # tell source we're building dll's <runtime-link>dynamic # build only for dynamic runtimes <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support : debug release # build variants ; cvs diff: Diffing doc cvs diff: Diffing example cvs diff: Diffing src cvs diff: Diffing test Index: test/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/test/Jamfile,v retrieving revision 1.4 diff -u -r1.4 Jamfile --- test/Jamfile 28 Jun 2004 09:31:28 -0000 1.4 +++ test/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -19,7 +19,9 @@ run $(name).cpp <dll>../build/boost_program_options <lib>../../test/build/boost_test_exec_monitor : : : <include>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support + <define>BOOST_ALL_DYN_LINK=1 + <runtime-link>dynamic : $(name)_dll ] ; }

2 6

STLPort linking error
by Ian McCarty 15 Jul '04

15 Jul '04

Hi, I am in the middle of moving our development from the std STL to STLPort and I am having a problem with two Athlon boxes. SuSE Linux 9.0 gcc 3.3.1 STLPort 4.6.2 Boost 1.31 I am changing an existing application to use STLPort and I have successfully completed the transition on a number of Intel boxes. When I try to build on an Athlon box I get the following error message: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I'm linking against libboost_thread-gcc-mt-p-1_31 and libboost_date_time-gcc-mt-p-1_31. I can't see an obvious solution so I'm hoping someone has solved this problem already. Thanks in advance, Ian. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 2

FW: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 15 Jul '04

15 Jul '04

Hi Robert, We'll see what we can do - but sadly there's no bjam port for AS400 or MVS. On both we use the unix-like environment (something like 'qshell' and the mvs version I keep forgetting), so it might be doable. The mac-version (not too much) or the unix version of the bjam sources ("file*.c", "exec*.c" "path*.c" etc) could be used as a base - on the other hand, the gnu tools like 'make' on AS400 map their calls to the 'local' calls - which is not fopen :) - so it might be tricky. We'll let you know (If anoynone has ported bjam to AS400 or MVS - I'd lve to know) Dirk Robert Ramey wrote: Dirk Griffioen wrote: I also outcommented line 125. We will, however, upgrade to #20 as soon as possible. Note that #20 and subsequent versions do not have boost/serialization/shared_count.hpp but rather use a very crude hack to gain access to private variables within shared_count. Hopefully this will be addressed in a better way in the near future. You might want to wait just a tiny bit. It looks like serialization may be included in the upcoming boost release. If the release works out soon you might want to move right to boost 1.32. If the release boggs down or for some reason its inconvenient for you do move to 1.32 - you can use to #20. #20 is the last draft. I've tested it extensively with 1.31. We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Hmmm - embarrassment of riches. It is possible you might be able to run - at least occasionally the bjam test suite for some of the less common platforms? I would love to know how boost (and of course serialization) work with AS400 and Mainframe(?). I believe the others are already covered. If you're willing to run the tests, developers might be more willing the help with the porting. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

regression tests not update
by Pavol Droba 15 Jul '04

15 Jul '04

Hi, I don't know what is wrong, but it seems, that regression test are not updated. I have commited markups for failuers two days ago and they are still not used in the regression test. (Specificaly not in the metacomm tables) Also some bugfixes seems to be not applied. Can anybody check this out? Thanks, Pavol

2 1