[boost] Re: true64cxx and toupper

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-08-12 06:12:34

Jonathan Wakely wrote:
> 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?  :)

In theory I agree with you, in practice I'm not sure. Maybe we should 
get more opinions on this from other users of this platform.

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

Agreed. But what is the best way to do that? Define those macros to some 
value and you will get conflicts with users of boost. So you have to 
leave that decision to the user and let boost make the best of it, 
whatever environment it finds. I think that is already done by 
"boost/config/posix_features.hpp".

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

But it would require much effort to fix it. I know this is a pragmatic 
point of view, but I'm not sure if it's really worth the effort.

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

Ideally, boost should adapt to whatever mode the compiler is in. In 
theory, this should be possible as every switch defines some compiler macro:

-pthread => _REENTRANT
-pure_cname => __PURE_CNAME
-using_std => __IMPLICIT_USING_STD
-std ansi => __STD_ANSI
-std strict_ansi => __STD_STRICT_ANSI, also sets __PURE_CNAME

For thread support this is already done by 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".

Compiled libs would end up with yet more build variants. Header only 
libs could be made to adapt automatically, if one is willing to put 
enough effort into it. Which returns us to the question if it's really 
worth it.

Markus