Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.146.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=tg8kskabX/lGVDKLMCATr+IUizjLd8LJHl7pV4vv8ewxTs0d9CxNIGEy3ova7LEDbH08OmQ6J4+oKp228wDGX9T6pTOJ4Pl2F4AZNHoZ3pkIDvcivgeSc4knU90LYb4ELIYSCn4boeJK2Gq6PznCU9g/4a8S0+8brBwWcI2xnUE=
Message-ID: <47FFBC65.3060609@roguewave.com>
Date: Fri, 11 Apr 2008 13:30:45 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: _RWSTD_NO_BOOL vs _RWSTD_NO_NATIVE_BOOL
References: <7BDB2168BEAEF14C98F1901FD2DE64383C3EB0@epmsa009.minsk.epam.com>
In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE64383C3EB0@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Farid Zaripov wrote:
>   In library headers somewhere used _RWSTD_NO_BOOL and somewhere - _RWSTD_NO_NATIVE_BOOL.
> The _RWSTD_NO_BOOL.is determined at configure step, but _RWSTD_NO_NATIVE_BOOL - not. At the same time
> _RWSTD_NO_NATIVE_BOOL mentioned in readme file, while _RWSTD_NO_BOOL - doesn't.
> What the difference between these macros?
>  
> Shouldn't be _RWSTD_NO_NATIVE_BOOL. replaced with _RWSTD_NO_BOOL.?

The _NO_NATIVE_XXX macros (_RWSTD_NO_NATIVE_BOOL and
_RWSTD_NO_NATIVE_WCHAR_T) are #defined when the respective type isn't
a distinct type. The others are #defined when the type isn't provided
at all, not even as a typedef. We probably could drop the second kind
because we don't depend on any typedefs like that. It might even make
sense to get rid of both kinds of macros and assume that both bool
and wchar_t are always provided as distinct types. We talked about
doing a review of all these workarounds in the future (sometime after
4.2) and cleaning things up -- see this post:
   http://stdcxx.markmail.org/message/zuawhacu2cihto4y
It might make sense to add these to the list.

Martin