On Thu, 2 Dec 2004, Jasper van de Gronde wrote:
Bob Jamison wrote:
If we could upgrade from char * ---to--->FILE *
to a much cleaner URI ---to--->istream and URI ---to--->ostream
In general a good idea, but I'd be very careful with using iostreams, they can be VERY slow, difficult to work with and can cause interesting problems, while their advanced features are usually hardly worth the trouble of using them (I've actually reverted to using FILE* or Win32 specific APIs as I find them much easier and more reliable).
Personally I like printf (especially after having benchmarked similar conversions using streams), but again I doubt this is a decisive feature.
I've had similar experience with iostreams. I had gotten into using them a great deal (including deriving custom stream classes, making custom formatting operators, etc. etc.) and got pretty knowledegable and comfortable with the advanced features, but for the things I was typically using it for (generating tabulated reports of enginering data), making it print nicely took a lot more work than printf. I also found myself having to write my own number<->string converters, etc. because the iostream capabilities were limited in one way or another.
Anyway, when I finally saw that printf-style I/O was common in a lot of programming languages, but iostream was rather C++-unique, that was sort of the deciding factor, and I switched back.
However, I'm certain that for certain specific types of usage models, iostream can be superior. It's good for developers unfamiliar with pointers, or for doing logging/error printing, and interactive cmdline stuff. It doesn't seem to offer much for GUI stuff (sprintf is a workhorse) or formatted text file output.
I haven't really looked into how Inkscape is doing I/O, and don't know the comparitive support for XML that the two models have. Possibly iostream provides a better XML-writing interface?
Anyway, my thinking is, it's worth a shot. We always say 'patch first, discuss later', so I'd say despite my reservations I'd support plugging it in and trying it out. I would imagine it'd be a fairly easy thing to remove if we found it caused some problem. If Bob's right that it majorly cleans up the code, and doesn't hurt performance, that'd be great. If not, then at least we'd know, and perhaps have some better ideas of how to do it in the future. ;-)
Bryce