This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support


Bernardo Innocenti wrote:
> > Depends on what you mean by need :-)
> 
> Well, does it make sense to provide a full blown public
> interface as mandated by the standard even when sume
> functionality cannot be implemented because of missing
> support from the underlaying system?

>From a users point of view, it doesn't really matter if some
function is totally missing or if it is present but unimplemented;
either way that function does nothing useful.

>From a maintainers point of view, the situation is different. If
that function is called from some other part of the library, those
calls have to be guarded by #ifdefs if the called function may be
undeclared. If the called function is always present, but may be
unimplemented, nothing special needs to be done.

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.

> 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.

> 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?

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

Petur


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