Re: Minimize <iosfwd>

[Benjamin Kosnik <bkoz at redhat dot com>]

I think the idea of splitting fpos and mbstate_t deps out of postypes.h 
is excellent.

> +// We may be able to use a special feature of glibc's <wchar.h> to
> +// get a definition of mbstate_t and nothing else.  If used, it exposes
> +// __mbstate_t rather than mbstate_t (the latter is a typedef to the
> +// former when the full header is included, so we have no linkage issues).
> +// This header provides the macro _GLIBCXX_MBSTATE_T which expands to
> +// mbstate_t or __mbstate_t as appropriate.
> +//
> +// N.B. The special feature does not work if used via <cwchar>, nor does
> +// it work if we attempt to force the <wchar.h> definitions into a
> +// namespace.
> +
> +#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 1)
> +
> +  #define __need_mbstate_t
> +  #include <wchar.h>
> +  #define _GLIBCXX_MBSTATE_T ::__mbstate_t
> +
> +#else
> +
> +  #include <cwchar>
> +  #define _GLIBCXX_MBSTATE_T mbstate_t
> +
> +#endif

This, however, is problematic.

There's been a serious attempt made to keep system-dependent macros out 
of main include files and into configuration-selected files. I think 
that approach might be best with this, and as an addition I believe 
doing something like a mbstate_t.h that is configuration-selected will 
also simplifiy <cwchar>'s handling of mbstate_t when ndef 
_GLIBCXX_HAVE_MBSTATE_T. In addition, this would allow typdefing for 
mbstate_t in the linux case, and thus the removal of the 
_GLIBCXX_MBSTATE_T macro.

If you look at the compile-server docs, at the "1.10.4 types defined in 
multiple locations" bit, you'll see more info on this. After two weeks 
spent wrestling with this issue on newlib, glibc, and solaris targets 
I've come to the conclusion that __need_FOO macros should always be 
FOO.h includes. If we cannot get this from the native "C" library than 
libstdc++ should simulate this approach IMHO.

best,
-benjamin