[libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support

[Bernardo Innocenti]

Pétur Runólfsson wrote:

> For the specific case of fpos<mbstate_t>::state(mbstate_t),
> 
> void state(mbstate_t s) const
> {
> #ifdef __FOO__
>   __state = s;
> #endif
> }
> 
> is acceptable, because state() can be called unconditionally from
> basic_filebuf, but
> 
> #ifdef __FOO__
> void state(mbstate_t s) const
> {
>   __state = s;
> }
> #endif
> 
> is not acceptable, because in this case all calls to state() must
> be guarded with #ifdef __FOO__. This would be very fragile,
> as someone testing on a system where __FOO__ is defined might
> add a call to state(), but forget to add the #ifdefs.

I do agree with you. But what shall we do for functions returning
a value? Clearly, returning 0, NULL or false is not always a sane
thing to do.


>>And even if some of them could be made to work somehow,
>>wouldn't it be useful to have a way to turn off advanced
>>functionality to make the library smaller or more efficient
>>for small systems?
> 
> It would be useful, yes. But it would be even better to have
> this happen automatically. Nobody wants to maintain two versions
> of the library.

I understand and agree, but it's not always possible in all cases.
Il libstdc++ keeps ignoring the issues of smaller systems for
improved maintanability, lots of rogue patches will appear
everywhere.


>>If we unconditionally add a member variable of type mbstate_t in
>>class fpos, all instances will end up being bigger. Even worse, the
>>compiler won't be able to pass fpos objects around as scalars because
>>they would now be real structures with multiple fields.
> 
> Sure, but remember the 80-20 rule of optimization. Is fpos really
> used so much that it is a problem?

Whenever a program uses iostreams, fpos will get linked in.

Actually, there are bigger outstanding problems in 3.4: the new
demangler gets linked in as soon as the program uses exceptions,
bringing 200KB worth of code with it.


> That said, you can implement whatever optimizations you like in
> code specific to your platform, so long as it conforms to the generic
> interface.

For the uClibc case, I think it would be wiser to use the gnu-linux/
code. uClibc aims to be 100% compatible with glibc, and is currently
very close.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html