Re: [boost] Re: true64cxx and toupper

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-08-12 05:20:43

On Thu, Aug 12, 2004 at 11:13:32AM +0200, Markus Sch?pflin wrote:

> 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.

Seems the best option to me.

If a compiler is capable of conforming then why tell it not to and
require boost hacks to make it behave as though it conforms?

Would you break a healthy person's legs and then give them crutches?  :)

> 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.)

Yes, adding those is probably a good idea if Boost needs to use any
non-std features.

> 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?

I don't have access to cxx, I've only been able to port my code to it
with the help of bug reports from other cxx users, so I can't comment on
whether those flags worked. The -nopure_cname looks out of place to me.
If Boost doesn't work with pure <cxxx> headers then Boost is broken.

> 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.

This isn't terrible, but is less strict than the standard requires, and
my personal preference would be to conform as much as possible.

On reflection, the main argument I can see against using strict_ansi is
that it requires users of Boost to compile with that flag. This might be
too restrictive for some users as it would prevent their code from
compiling.

On the other hand, requiring users to compile in less-than-conforming
mode would mean that some people using strict_ansi mode and writing
perfectly conforming code cannot use Boost.

As I understand it, whatever flags are used by Boost must match the
flags a user uses (maybe this only applies to compiled libs, not
header-only ones), so one view would be that Boost should use the most
commonly used set of flags. This might be the default - but then that
uses nonstandard streams and implicit using directive for namespace std
- eurgh! And in any case, "noone knows what most C++ programmers do".

yours, not knowing the right answer,

jon

-- 
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
	- M.A. Jackson