This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Minimize <iosfwd>
On 4/10/07, Benjamin Kosnik <bkoz@redhat.com> wrote:
[...]
[The __need_mbstate_t hack], 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.
I'd be happy to make changes to the mbstate_t handling, but I'm going
to need more guidance. I am not sufficiently familiar with the
library organization or configuration logic to understand what you
want done from the above description.
In addition, this would allow typdefing for mbstate_t in the linux case,
and thus the removal of the _GLIBCXX_MBSTATE_T macro.
Unless you are proposing to duplicate glibc's definition of the
structure I do not see how you can do that. glibc <wchar.h> will
continue to assume that it is the one that gets to typedef mbstate_t.
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
I certainly agree on FOO.h versus __need_FOO - in the dreaded
alternative universe where I have to maintain glibc, it is what I
would be doing - but, um, compile server? I thought that was an
ex-parrot.
zw