Problem 2 with Boost 1.31.0 Regex for tru64cxx65
Having persuaded everything to compile in the 1.31.0 Regex library, it runs into another problem in building the .a archive libraries: tru64cxx65-Archive-action bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a /bin/sh: /bin/ar: arg list too long rm -f bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a ar r bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/c_regex_traits.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/c_regex_traits_common.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/cpp_regex_traits.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/cregex.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/fileiter.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/posix_api.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/regex.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/regex_debug.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/regex_synch.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/w32_regex_traits.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/wide_posix_api.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/instances.o bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/winstances.o "bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release"/cxx_repository/* ...failed tru64cxx65-Archive-action bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a... The problem is due to the number of instantiations in the template repository and the lengths of their names. There are 492 instantiations, and many of them have 90-character file names, which looks like the compiler's maximum allowed. I solved the problem in previous versions of boost by breaking up the build into separate steps. This was the way I modified the make file: AR:= ar -cq IIDIR:= $(LIBDIR)/cxx_repository $(DIRNAME)/lib$(LIBNAME).a : $(ALL_O) @echo "*** creating lib$(LIBNAME).a" rm -f $@ $(AR) $@ $^ @echo "*** adding template instantiations" $(AR) $@ $(IIDIR)/[_A-Z]* $(AR) $@ $(IIDIR)/[a-z]* It builds the library from just the object files and then adds the instantiations in two steps. (Apparently, adding all of them exceeded the same shell arg list limit.) How can I do something equivalent with bjam to build the library? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Having persuaded everything to compile in the 1.31.0 Regex library, it runs into another problem in building the .a archive libraries:
tru64cxx65-Archive-action bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a
/bin/sh: /bin/ar: arg list too long
[snip]
The problem is due to the number of instantiations in the template repository and the lengths of their names. There are 492 instantiations, and many of them have 90-character file names, which looks like the compiler's maximum allowed.
I solved the problem in previous versions of boost by breaking up the build into separate steps. This was the way I modified the make file:
AR:= ar -cq IIDIR:= $(LIBDIR)/cxx_repository
$(DIRNAME)/lib$(LIBNAME).a : $(ALL_O) @echo "*** creating lib$(LIBNAME).a" rm -f $@ $(AR) $@ $^ @echo "*** adding template instantiations" $(AR) $@ $(IIDIR)/[_A-Z]* $(AR) $@ $(IIDIR)/[a-z]*
It builds the library from just the object files and then adds the instantiations in two steps. (Apparently, adding all of them exceeded the same shell arg list limit.)
How can I do something equivalent with bjam to build the library?
Solving this will require changing the archive action in the tru64cxx65-tools.jam file. The most generic way I can think of is to change it to something like so: actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) for i in "$(<[1]:D)"/cxx_repository/* ; do ar r$(ARFLAGS) $(<) $i ; done } Tell me what works for you and I'll update the toolset in CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Solving this will require changing the archive action in the tru64cxx65-tools.jam file. The most generic way I can think of is to change it to something like so:
actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) for i in "$(<[1]:D)"/cxx_repository/* ; do ar r$(ARFLAGS) $(<) $i ; done }
Tell me what works for you and I'll update the toolset in CVS.
This was great advice. The unfortunate thing about the general way, adding just one file from the repository at a time, is the huge overhead of each call to ar. I remember trying this myself a couple of years ago and deciding it was unacceptable. That was why I added as many object files at a time as I could get away with. This time, I had to break it into four pieces: actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) # one at a time is general, but too slow. Do a bunch at once. # for i in "$(<[1]:D)"/cxx_repository/* ; do ar r$(ARFLAGS) $(<) $i ; done ar r$(ARFLAGS) $(<) "$(<[1]:D)"/cxx_repository/[_A-Z]* ar r$(ARFLAGS) $(<) "$(<[1]:D)"/cxx_repository/[a-f]* ar r$(ARFLAGS) $(<) "$(<[1]:D)"/cxx_repository/[g-m]* ar r$(ARFLAGS) $(<) "$(<[1]:D)"/cxx_repository/[n-z]* } Of course, there may be libraries for which this will still fail. I don't know how to arrive at a better solution, but you could just wait until someone complains and then break it into smaller pieces. For now, I'll go with this huge time savings. I didn't let it go to completion with the one-at-a-time rule, but I'm pretty sure it's on the order of 10-15 minutes, compared to 10-15 sec. with my approach. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Rene Rivera wrote:
Solving this will require changing the archive action in the tru64cxx65-tools.jam file. The most generic way I can think of is to change it to something like so:
actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) for i in "$(<[1]:D)"/cxx_repository/* ; do ar r$(ARFLAGS) $(<) $i ; done }
Tell me what works for you and I'll update the toolset in CVS.
This was great advice. The unfortunate thing about the general way, adding just one file from the repository at a time, is the huge overhead of each call to ar. I remember trying this myself a couple of years ago and deciding it was unacceptable. That was why I added as many object files at a time as I could get away with. This time, I had to break it into four pieces:
Hmm, I think there's a way around the problem. Since the archive is getting recreated each time we can use the much faster "q" (append) option instead of the slow "r" (add/replace). Try the general solution but using "ar q..." instead if "ar r.." -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Hmm, I think there's a way around the problem. Since the archive is getting recreated each time we can use the much faster "q" (append) option instead of the slow "r" (add/replace). Try the general solution but using "ar q..." instead if "ar r.."
I recall trying it last time. In fact, I would use it anyway, because you are always building the archive from scratch, so 'q' should be safe. However, it still didn't help much. If I get some extra time, I can make a measurement, but I think I decided that the problem was due to the overhead of ar opening and closing the library each time, probably spending some time digesting whatever directory info is there. I also seem to remember that I would print a line for each append, and it would slow down drastically as the library grew larger. (It's been a while, so I won't swear to it.) -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
If I get some extra time, I can make a measurement, but I think I decided that the problem was due to the overhead of ar opening and closing the library each time, probably spending some time digesting whatever directory info is there. I also seem to remember that I would print a line for each append, and it would slow down drastically as the library grew larger. (It's been a while, so I won't swear to it.)
I made the measurements of the total time it took to add the instantiations to the archive library. I used 'ar q' instead of 'ar r', as suggested. The times are in the form hh:mm:ss. Method debug release appending 4 groups 0:43 0:10 appending individually 1:07:24 13:31 That's right -- over an hour for the debug version when appended one instantiation at a time, compared to under a minute when grouped. Since Tru64 Unix is a dead-end platform, I wouldn't spend too much time on this. It's only worth noting in case another compiler does the same thing with its instantiations and doesn't provide its own method for building archive libraries. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Richard Hadsell wrote:
I made the measurements of the total time it took to add the instantiations to the archive library. I used 'ar q' instead of 'ar r', as suggested. The times are in the form hh:mm:ss.
Method debug release
appending 4 groups 0:43 0:10
appending individually 1:07:24 13:31
That's right -- over an hour for the debug version when appended one instantiation at a time, compared to under a minute when grouped. Since Tru64 Unix is a dead-end platform, I wouldn't spend too much time on this. It's only worth noting in case another compiler does the same thing with its instantiations and doesn't provide its own method for building archive libraries.
I'll make the changes as you suggested. Certainly something to keep in mind for other toolsets. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Richard Hadsell wrote in a first mail:
When the build gets to this point:
tru64cxx65-C++-action bin/boost/libs/regex/build/libboost_regex.so/tru64cxx65/release/cregex.o
it hangs. I have run into this situation with other large files, and my usual remedy is to decrease the optimization level.
and in a second mail:
Having persuaded everything to compile in the 1.31.0 Regex library, it runs into another problem in building the .a archive libraries:
tru64cxx65-Archive-action bin/boost/libs/regex/build/libboost_regex.a/tru64cxx65/release/libboost_regex-tru-1_31.a
/bin/sh: /bin/ar: arg list too long
<snip> You might want to try the appended tools file for true64cxx65. I recently started to use boost on this platform and this is what I have come up with so far. These were the major issues with the toolset description: - The "flags tru64cxx65 CFLAGS <inlining>full : -inline all ;" hangs the compiler when compiling with full inlining. Leaving this at the default value solves the problem. - The command line for the archive action exceeds its maximum length when used with certain libs. On recommendation from Ralf Grosse-Kunstleve I removed the whole cxx repository stuff and added "-tlocal" to the C++ compiler options. This avoids the need for repositories completely. - The Cc-action was refering to a non existant cxx-Cc-action. - The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better. Maybe the maintainers should consider to replace the current toolset with the one attached. There are other issues to be aware of: - When compiling boost you will see several warnings (and one error!) about the use of assert on pointer types. These are caused by a bug in the system header files which force the argument for assert() to int. This can be fixed by editing the header file "/usr/include/assert.h". - When the macro _XOPEN_SOURCE is defined to something greater or equal to 500, you will encounter errors when compiling code which involes iostreams because of a bug in the iotraits header file. This happended to me when compiling boost.python because python forces the _XOPEN_SOURCE to 600. You need to fix the iotraits header file for this. - There are several statements in the form of # if (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031) sprincled through boost to work around compiler deficencies. As we are using 60590040 I patched these to the new revision number. I didn't check if the bugs were fixed in the compiler but you might want to do the same. Thats all I can remember off the top of my head. I did some tweaking to the boost.python source but that might not be necessary for you. HTH, Markus # (C) Copyright David Abrahams 2001. Permission to copy, use, # modify, sell and distribute this software is granted provided this # copyright notice appears in all copies. This software is provided # "as is" without express or implied warranty, and with no claim as # to its suitability for any purpose. # # Jam tools information for : # Compaq Alpha CXX compiler # # No static linking as far as I can tell. # flags cxx LINKFLAGS <runtime-link>static : -bstatic ; flags cxx CFLAGS <debug-symbols>on : -g ; flags tru64cxx65 LINKFLAGS <debug-symbols>on : -g ; flags tru64cxx65 LINKFLAGS <debug-symbols>off : -s ; flags tru64cxx65 LINKFLAGS <target-type>$(SHARED_TYPES) : -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' ; flags tru64cxx65 CFLAGS <optimization>off : -O0 ; flags tru64cxx65 CFLAGS <optimization>speed/<inlining>on : -O2 ; flags tru64cxx65 CFLAGS <optimization>speed : -O2 ; # Added for threading support flags tru64cxx65 CFLAGS <threading>multi : -pthread ; flags tru64cxx65 LINKFLAGS <threading>multi : -pthread ; flags tru64cxx65 CFLAGS <optimization>space/<inlining>on : <inlining>size ; flags tru64cxx65 CFLAGS <optimization>space : -O1 ; flags tru64cxx65 CFLAGS <inlining>off : -inline none ; #flags tru64cxx65 CFLAGS <inlining>full : -inline all ; flags tru64cxx65 CFLAGS <profiling>on : -pg ; flags tru64cxx65 LINKFLAGS <profiling>on : -pg ; flags tru64cxx65 CFLAGS <cflags> ; flags tru64cxx65 C++FLAGS <cxxflags> ; flags tru64cxx65 DEFINES <define> ; flags tru64cxx65 UNDEFS <undef> ; flags tru64cxx65 HDRS <include> ; flags tru64cxx65 STDHDRS <sysinclude> ; flags tru64cxx65 LINKFLAGS <linkflags> ; flags tru64cxx65 ARFLAGS <arflags> ; if ! $(ARFLAGS) { flags tru64cxx65 ARFLAGS : "" ; } #### Link #### rule Link-action ( target : sources + : target-type ) { tru64cxx65-Link-action $(target) : $(sources) ; } # for tru64cxx, we repeat all libraries so that dependencies are always resolved actions tru64cxx65-Link-action bind NEEDLIBS { cxx -noimplicit_include $(LINKFLAGS) -o "$(<)" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -lrt -lm } actions tru64cxx65-Link-shared bind NEEDLIBS { cxx -qrtti -noimplicit_include $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -lm } #### Cc ##### rule Cc-action { tru64cxx65-Cc-action $(<) : $(>) ; } actions tru64cxx65-Cc-action { cc -std1 -msg_display_number -msg-disable 186,450,1115 -c -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### C++ #### rule C++-action { tru64cxx65-C++-action $(<) : $(>) ; } # Note: DON'T disable warning 1133 -- the compiler is buggy and you # really can't ignore this one! actions tru64cxx65-C++-action { cxx -tlocal -noimplicit_include -c -D__USE_STD_IOSTREAM -nousing_std -msg_display_number -msg_disable 186,450,1115 -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### Archive #### rule Archive-action { tru64cxx65-Archive-action $(<) : $(>) ; } actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) }
Markus Schöpflin wrote:
Maybe the maintainers should consider to replace the current toolset with the one attached.
Will do.. but could you update the copyright on the file first? As in put in your name and use the new Boost License text (Dave A. has given permission to change all his copyrights to the new text). Just want to give credit where it's due ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Markus Schöpflin wrote:
Will do.. but could you update the copyright on the file first? As in put in your name and use the new Boost License text (Dave A. has given permission to change all his copyrights to the new text).
Ok, but that will have to wait 'till Monday morning. Have a nice weekend! Markus
Markus Schöpflin
Rene Rivera wrote:
Markus Schöpflin wrote: Will do.. but could you update the copyright on the file first? As in put in your name and use the new Boost License text (Dave A. has given permission to change all his copyrights to the new text).
Ok, but that will have to wait 'till Monday morning. Have a nice weekend!
Please make sure you use the form shown at http://boost-consulting.com/boost/more/license_info.html#FAQ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Rene Rivera wrote:
Will do.. but could you update the copyright on the file first? As in put in your name and use the new Boost License text (Dave A. has given permission to change all his copyrights to the new text).
Here you are. I have added the new license header and some comments. # Copyright 2001 David Abrahams. Copyright 2004 Markus Schöpflin. # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # # Jam tools information for : # Compaq Alpha CXX compiler # # Notes on this toolset: # # - The default language mode "-std ansi" has been found to work better than # "-std strict_ansi" so we keep to the default. # # - C++ standard iostreams are enabled with __USE_STD_IOSTREAM as the compiler # defaults to the pre-standard iostreams in ansi language mode. # # - For template instantiation "-tlocal" is used. This avoids the need for a # repository. Note that the compiler manual page warns against code bloat # when using this option but this has not been observed so far. # # No static linking as far as I can tell. # flags cxx LINKFLAGS <runtime-link>static : -bstatic ; flags cxx CFLAGS <debug-symbols>on : -g ; flags tru64cxx65 LINKFLAGS <debug-symbols>on : -g ; flags tru64cxx65 LINKFLAGS <debug-symbols>off : -s ; flags tru64cxx65 LINKFLAGS <target-type>$(SHARED_TYPES) : -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' ; flags tru64cxx65 CFLAGS <optimization>off : -O0 ; flags tru64cxx65 CFLAGS <optimization>speed/<inlining>on : -O2 ; flags tru64cxx65 CFLAGS <optimization>speed : -O2 ; # Added for threading support flags tru64cxx65 CFLAGS <threading>multi : -pthread ; flags tru64cxx65 LINKFLAGS <threading>multi : -pthread ; flags tru64cxx65 CFLAGS <optimization>space/<inlining>on : <inlining>size ; flags tru64cxx65 CFLAGS <optimization>space : -O1 ; flags tru64cxx65 CFLAGS <inlining>off : -inline none ; # The compiler versions tried (up to V6.5-040) hang when compiling Boost code # with full inlining enabled. So leave it at the default level for now. # # flags tru64cxx65 CFLAGS <inlining>full : -inline all ; flags tru64cxx65 CFLAGS <profiling>on : -pg ; flags tru64cxx65 LINKFLAGS <profiling>on : -pg ; flags tru64cxx65 CFLAGS <cflags> ; flags tru64cxx65 C++FLAGS <cxxflags> ; flags tru64cxx65 DEFINES <define> ; flags tru64cxx65 UNDEFS <undef> ; flags tru64cxx65 HDRS <include> ; flags tru64cxx65 STDHDRS <sysinclude> ; flags tru64cxx65 LINKFLAGS <linkflags> ; flags tru64cxx65 ARFLAGS <arflags> ; if ! $(ARFLAGS) { flags tru64cxx65 ARFLAGS : "" ; } #### Link #### rule Link-action ( target : sources + : target-type ) { tru64cxx65-Link-action $(target) : $(sources) ; } # for tru64cxx, we repeat all libraries so that dependencies are always resolved actions tru64cxx65-Link-action bind NEEDLIBS { cxx -noimplicit_include $(LINKFLAGS) -o "$(<)" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -lrt -lm } actions tru64cxx65-Link-shared bind NEEDLIBS { cxx -qrtti -noimplicit_include $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) -lm } #### Cc ##### rule Cc-action { tru64cxx65-Cc-action $(<) : $(>) ; } actions tru64cxx65-Cc-action { cc -std1 -msg_display_number -msg-disable 186,450,1115 -c -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### C++ #### rule C++-action { tru64cxx65-C++-action $(<) : $(>) ; } # Note: DON'T disable warning 1133 -- the compiler is buggy and you # really can't ignore this one! actions tru64cxx65-C++-action { cxx -c -tlocal -noimplicit_include -D__USE_STD_IOSTREAM -nousing_std -msg_display_number -msg_disable 186,450,1115 -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### Archive #### rule Archive-action { tru64cxx65-Archive-action $(<) : $(>) ; } actions updated together piecemeal tru64cxx65-Archive-action { rm -f $(<) ar r$(ARFLAGS) $(<) $(>) }
Markus Schöpflin wrote:
Rene Rivera wrote:
Will do.. but could you update the copyright on the file first? As in put in your name and use the new Boost License text (Dave A. has given permission to change all his copyrights to the new text).
Here you are. I have added the new license header and some comments.
Awesome... It's in CVS now. Thanks :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Markus Schöpflin wrote:
- When compiling boost you will see several warnings (and one error!) about the use of assert on pointer types. These are caused by a bug in the system header files which force the argument for assert() to int. This can be fixed by editing the header file "/usr/include/assert.h".
Thanks for the tips. With regard to this one, was your fix to (a) change the cast to bool, (b) change the cast to long, or (c) just eliminate the cast and let the compiler convert to bool? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
- When compiling boost you will see several warnings (and one error!) about the use of assert on pointer types. These are caused by a bug in the system header files which force the argument for assert() to int. This can be fixed by editing the header file "/usr/include/assert.h".
Thanks for the tips. With regard to this one, was your fix to (a) change the cast to bool, (b) change the cast to long, or (c) just eliminate the cast and let the compiler convert to bool?
Never mind. I decided to fix the assert complaints by modifying boost/regex/v4/perl_matcher_non_recursive.hpp. I prefer that to modifiying a system header on every machine and for any future upgrades (unlikely as they are at this point). I changed all the asserts with an argument of just a pointer to compare the pointer to 0, thus producing a valid bool. E.g.: assert(rep->next.p); => assert(rep->next.p != 0); I don't think Boost developers (i.e., John Maddock) would mind. Do you think they (i.e., he) might even accept this as an improvement? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Richard Hadsell wrote:
Markus Schöpflin wrote:
- When compiling boost you will see several warnings (and one error!) about the use of assert on pointer types. These are caused by a bug in the system header files which force the argument for assert() to int. This can be fixed by editing the header file "/usr/include/assert.h".
Thanks for the tips. With regard to this one, was your fix to (a) change the cast to bool, (b) change the cast to long, or (c) just eliminate the cast and let the compiler convert to bool?
As the argument to assert() is allowed to be any integral expression I simply removed the cast to int. I filed a bug report for this and HP acknowledged it but up to now I have no information on if or when a fixed header will be released officially.
Never mind. I decided to fix the assert complaints by modifying boost/regex/v4/perl_matcher_non_recursive.hpp. I prefer that to modifiying a system header on every machine and for any future upgrades (unlikely as they are at this point). I changed all the asserts with an argument of just a pointer to compare the pointer to 0, thus producing a valid bool. E.g.:
assert(rep->next.p); => assert(rep->next.p != 0);
I don't think Boost developers (i.e., John Maddock) would mind. Do you think they (i.e., he) might even accept this as an improvement?
I can't speak for John, you would have to ask this himself. But as that would be a very widespread change and would affect many lines of code (essentially every use of assert(p), where p is either a raw pointer or a smart pointer) I don't think this would be such a good idea after all. You could propose to add a new portability macro BOOST_ASSERT() or some such but as far as I know the general feeling is that there are too many such macros already. Tru64 is the only plattform I have encountered this problem but on the other hand, its the only 64bit plattform I have worked with so far. I have no idea if other 64bit plattforms are affected as well. Markus
Never mind. I decided to fix the assert complaints by modifying boost/regex/v4/perl_matcher_non_recursive.hpp. I prefer that to modifiying a system header on every machine and for any future upgrades (unlikely as they are at this point). I changed all the asserts with an argument of just a pointer to compare the pointer to 0, thus producing a valid bool. E.g.: assert(rep->next.p); => assert(rep->next.p != 0); I don't think Boost developers (i.e., John Maddock) would mind. Do you think they (i.e., he) might even accept this as an improvement? ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sure why not, the changes (and there are quite a few asserts like this) will be in cvs shortly. John.
participants (6)
-
David Abrahams -
John Maddock -
Markus Schöpflin -
Markus Schöpflin -
Rene Rivera -
Richard Hadsell