[haiku-development] Re: RFC: BDataIO::Print(), PrintToStream(BDataIO&)

"Ingo Weinhold" <ingo_weinhold@xxxxxx> wrote:
> > That could also be solved by a BFormattedIO class that you can wrap 
> > around any other class.
> > If one would also add parsing functionality, I think this would be 
> > the 
> > preferred way to go.
> I thought about that too and, since Java uses a somewhat similar 
> design
> (PrintWriter/PrintStream), I thought about it some more. I just can't 
> see any
> advantage to this approach, while it has the obvious disadvantage 
> that useful
> facilities from the derived classes cannot be used. E.g. BFileIO 
> overrides
> VPrint() to make use of vfprintf(). The base class implementation 
> (respectively
> a BFormattedIO class) has to resort to vsnprintf() and a limited 
> static buffer.

While that is true, it's also a rare case; ie. only BFileIO would have 
that ability.
But if you prefer that solution, I'm not really against it either.
Where would you put functions like (endian-safe) {Read|Write}Int32() 
in? Also in BDataIO?

> What would make sense IMHO is to pull Print() and VPrint() into an 
> abstract
> base class -- let's call it BPrintOutput -- to allow for greater 
> flexibility (the
> PrintToStream() methods would get such an object instead of a 
> BDataIO).
> For above reasons I would still derive BDataIO directly from it, 
> though.

Not sure what binary compatibility would say about that :-)

> > > * Added experimental BFdIO and BFileIO, which are BPositionIO 
> > > implementations wrapping a given file descriptor respectively 
> > > FILE*.
> > I don't like the BFdIO name, but I don't have a good idea for a 
> > replacement either -
> If it's just the name, Stippi's proposed BDescriptorIO sounds good to 
> me.

Rene's suggestion, but yes, I like that, too.

> > or have only BFileIO, and have it accept an fd as 
> > well (the FILE* version could flush the stream, and directly write 
> > to 
> > its fd, for example).
> That's quite ugly and wouldn't work as expected when mixed with 
> [f]printf()s.
> The other way around -- i.e. creating a FILE* from the FD -- I would 
> find OK,
> but the API for FILE* is significantly less handy.

I wouldn't mind, but having them separated isn't that bad either.

> > I think we could also add the Meta{Read|Write|...}() functions to 
> > BDataIO, they should be useful, too.
> Deja vu... ;-)

We still haven't added them yet, haven't we? ;-)

Bye,
   Axel.

Other related posts: