This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimize <iosfwd>



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.

Sure. Hang on...


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.

sorry. duplicate the typedef, not the structure.


doesn't matter if there are duplicates typedefs if the underlying type is the same. right?

ie

// mbstate_t.h for gnu
namespace std {
typedef __mbstate_t mbstate_t;
}

// cwchar
typedef __mbstate_t mbstate_t;

I haven't looked at the glibc includes for this so I'm not quite sure of the details.

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.

Just using these docs because of the clear description of the issue, nothing more.


-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]