Re: Linux vs. libio

[Per Bothner <per at bothner dot com>]

Jamie Lokier <jamie.lokier@cern.ch> writes:

> The down side is it's not at all portable, so code that's written on
> Linux will output differently on other platforms.

Firstly, is not a downside if glibc provides well-defined expected
behavior where other platforms don't.  Secondly, the C++ standard
*does* require the standard streams cin/cout/cerr to be syncronized
with stdin/stdout/stderr.  You can do this portably, but you do an
extra useless plus a function call on every character.

> Only the /very/ few fields that are used by inline input/output
> functions need to be shared. Since they are simple data fields, sharing
> those would be very easy even with many different kinds of C++ ABI.
> 
> Everything else, including vtable format and placement does not need to
> be shared.  Just have the C library call functions (not virtual ones)
> like "flush_my_output_stream" etc., and those functions would contain
> the vtable lookup code.

I believe we do that.  At least we used to.  The intent was to partly
insulate user code from ABI changes.  However, you still need to
co-ordinate the C and C++ data structures.  If you do that, it seems
logical to *share* the data structures.  Otherwise, you have to use
extra indirection.  (You have to share the pointer(s) for the current
input/output position:  The same actual pointers have to be logically
in both the FILE and the streambuf.  So either one of these data
structures has to use an extra indirction, or they have to be the
same object, or at least the objects have to overlap.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/