incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: Windows infrastructure for generating VisualStudio projects and solution(s)
Date Tue, 22 Aug 2006 17:02:23 GMT
Farid Zaripov wrote:
>   If the compiler do not conform in "for loop scope" then
> generated config.h file will contain #define _RWSTD_NO_FOR_LOCAL_SCOPE.
> I searched _RWSTD_NO_FOR_LOCAL_SCOPE macro in source files
> and found it in examples\include\examples.h and tests\include\testdefs.h
> files only:
> -----------------
> #  define for if (0) ; else for
> -----------------

Yes, this is only used in examples (and tests) to make it possible
and easy to make them look like fully conforming programs without
having to work around the lack of the feature. If we had config
tests just for our examples (and the test suite) the config macro
would be defined by them and not by the library configuration
infrastructure (and wouldn't show up in the library's config.h).

>   The conslusions:
> 1. the stdlib and utils itself are independent from compiler "for loop
> scope"
> conformance (because of they not uses _RWSTD_NO_FOR_LOCAL_SCOPE
> macro);

Yes. The library sources (including headers) avoid relying on
the feature in order to be portable to legacy compilers. I.e.,
they avoid using the same name for the controlling variable of
two or more loops in the same scope. This is being verified by
compiling the library with legacy compilers such as MSVC 7 w/o
the feature enabled.

> 2. the examples and tests itself are independed from compiler "for loop
> scope"
> conformance too (because of they get the conformance by defining "for"
> as
> "if (0); else for" in case when compiler do not conform).

Yes. Being programs (and not library headers), the examples can
use the '#define for' hack. A library header cannot very well do
that because the behavior of a program that defines a macro with
the same name as one of the C++ keywords is undefined. We cannot
impose undefined behavior on the users of our library headers.

>   What kind of problem could be when user link his project (compiled by
> without /Zc:forScope option enabled) with the stdcxx library (compiled
> with this
> option enabled)? Could you, please, show the example?

The problem is not with the linking of the library, it comes up
when compiling library headers that make assumptions about the
scope of the for loop's controlling variable. Consider this
algorithm defined in some public library header (i.e., one that
can be included by a program, such as <algorithm>):

   inline void
   some_algorithm (int __nloops)
       for (int __i = 0; __i != __nloops; ++__i)
           do_something (__i);

       for (int __i = 0; __i != __nloops; ++__i)
           do_something_else (__i);

The algorithm will compile with no errors or warnings when the
/Zc:forScope is used but will cause a diagnostic when it's not.

>   BTW in MSVC8 the "for loop scope" conformance and native wchar_t
> supporting
> are enabled by default.

You mean the default invocation of MSVC 8 enables these features?
That's good (but it still doesn't mean that we can assume they are
always enabled since we have MSVC 7 to deal with).


View raw message