[haiku-development] Re: RFC: BDataIO::Print(), PrintToStream(BDataIO&)
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 29 Jun 2009 20:55:01 +0200
-------- Original-Nachricht --------
> Datum: Mon, 29 Jun 2009 19:36:30 +0200 CEST
> Von: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > * Added BDataIO::[V]Print() methods for convenient printf() style
> > printing
> > to BDataIOs.
>
> 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.
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.
> > * 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.
> 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.
As an alternative BFile could be given a constructor that takes a FD. That's a
bit more overhead though.
At any rate this class is not really relevant for the other changes. It is
merely a byproduct. :-)
> > * Added PrintToStream(BDataIO&) versions to BPoint, BRect, BRegion,
> > BMessage.
>
> Very welcome.
>
> > The new BDataIO methods eat up virtual slots. I suppose Print() could
> > actually be non-virtual -- at least I can't imagine why any derived
> > class
> > would want to do anything other than the default implementation (i.e.
> > construct a va_list and call VPrint()).
> >
> > The name for VPrint() is "inspired" by the C/POSIX API names. Another
> > option would be something more descriptive like PrintVarArgs().
>
> I wouldn't mind either way.
>
> I think we could also add the Meta{Read|Write|...}() functions to
> BDataIO, they should be useful, too.
Deja vu... ;-)
CU, Ingo
Other related posts:
