This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Pétur Runólfsson <peturr02 at ru dot is>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>, libstdc++ at gcc dot gnu dot org
- Date: Fri, 26 Sep 2003 19:01:53 +0200
- Subject: Re: [libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support
- Organization: Develer S.r.l.
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F55D1@mail.ru.is>
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