"David O'Brien" <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 17, 2002 at 06:16:45PM -0400, Garrett Wollman wrote:
> > <<On Mon, 17 Jun 2002 18:02:17 -0400 (EDT), Thomas David Rivers
><[EMAIL PROTECTED]> said:
> >
> > > The correct approach (and, I have to admit to not
> > > glancing at your patch) would be:
> >
> > > #ifndef __cplusplus
> > > typedef _BSD_WCHAR_T_ wchar_t
> > > #endif
> >
> > Actually, the correct approach would be to avoid defining
> > _BSD_WCHAR_T_ when compiling C++. This way, it only needs to be done
>
> I am much more likely to force the libstdc++ build to use our
> _BSD_WCHAR_T_. Our types should be centralized and not in some hidden
> vendor software that often makes wrong assumptions about us.
I accidently sent a reply to just David, so please forgive
the duplicate.
I think there is a misunderstanding here...
It's not that the vendor software has "hidden" the definition
of `wchar_t'. The C++ standard mandates that `wchar_t' be
a "builtin" type, just like `int'.
This is so function overloading can distinguish based on the
`wchar_t' type.
That is, these would be two *different* functions in a standard-
conforming implementation:
void
foo(unsigned int)
{
}
void
foo(wchar_t)
{
}
If `wchar_t' is simply a typedef provided by the headers,
then the implementation isn't C++ standard conforming.
Also note that the source above is C++ standard conforming,
you don't need to #include anything to get the definition
of `wchar_t'.
gcc v3.x finally gets this correct - and we have to adjust
the headers to no longer define a typedef for wchar_t
in this situation.
This is not a situation of gcc being wrong - it's the
opposite - gcc is getting closer to right :-)
- Dave Rivers -
--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
