[boost] Re: true64cxx and toupper

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-08-12 04:13:32

Jonathan Wakely wrote:
> On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
> 
>>>- 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.
> 
> This seems a bit hasty IMHO. Surely it would be better to make Boost work
> with the compiler in strict_ansi mode than just force the compiler to act
> in a non-standard way?

What would you consider the correct way then? IMO we have three options.

1. Only use "-std strict_ansi". This means that the C header files 
(#include <c...>) included by boost libraries only define exactly those 
names specified in the C++ standard and nothing else. This would means 
changes to at least test, fs, regex and probably more libs. OTOH, this 
would mean that those libs are more conforming afterwards.

Here is the output of a configure run with the options "-pthread -tlocal 
-std strict_ansi":

#define BOOST_MSVC6_MEMBER_TEMPLATES
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#define BOOST_HAS_PTHREAD_DELAY_NP
#define BOOST_HAS_PARTIAL_STD_ALLOCATOR
#define BOOST_HAS_NRVO
#define BOOST_HAS_NL_TYPES_H
#define BOOST_HAS_LONG_LONG
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_DIRENT_H

(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no 
clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE 
or _POSIX_SOURCE or some such.)

2. Revert to "-std strict_ansi -nopure_cname". These were the flags that 
came with 1.30.0 but didn't work for me. Did those really work for you? 
If yes, which platform and which version of the compiler did you use?

Here is the output of a configure run with the options "-pthread -tlocal 
-std strict_ansi -nopure_cname":

#define BOOST_MSVC6_MEMBER_TEMPLATES
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_SIGACTION
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#define BOOST_HAS_PTHREAD_DELAY_NP
#define BOOST_HAS_PARTIAL_STD_ALLOCATOR
#define BOOST_HAS_NRVO
#define BOOST_HAS_NL_TYPES_H
#define BOOST_HAS_NANOSLEEP
#define BOOST_HAS_LONG_LONG
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_DIRENT_H
#define BOOST_HAS_CLOCK_GETTIME

3. Leave them at "-D__USE_STD_IOSTREAM -nousing_std". Those flags worked 
for me for boost 1.30.0. Note that this uses the default C++ mode for 
the compiler. This means: "The default ANSI mode permits some common 
extensions and provides less strict error checking than the STRICT_ANSI 
mode." (excerpt from manpage) The "-D__USE_STD_IOSTREAM" part is the 
offical documented way to enable standard iostreams and "-nousing_std" 
turns of the implicit using namespace std.

Here is the output of a configure run with the options "-pthread -tlocal 
-D__USE_STD_IOSTREAM -nousing_std":

#define BOOST_MSVC6_MEMBER_TEMPLATES
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_SIGACTION
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#define BOOST_HAS_PTHREAD_DELAY_NP
#define BOOST_HAS_PARTIAL_STD_ALLOCATOR
#define BOOST_HAS_NRVO
#define BOOST_HAS_NL_TYPES_H
#define BOOST_HAS_NANOSLEEP
#define BOOST_HAS_LONG_LONG
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_DIRENT_H
#define BOOST_HAS_CLOCK_GETTIME
#define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL

There is one compiler failure which doesn't happen in strict ansi mode.

> 
> I'd have thought that simply "-std strict_ansi" would be ok, as Boost
> has plenty of its own mechanisms for working around any remaining quirks
> of the compiler, without resorting to the compiler's own large array of
> compatibility switches.
> 
> Do the config settings for that compiler match the new switches used, or
> are they still the settings determined when "-std strict_ansi
> -nopure_cname" was used?

Those are still the old settings, AFAICT. But the only difference is 
BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL.

Markus