On Mar 11, 2008, at 4:22 AM, Krzysztof KosiĆski wrote:
Hello,
I had a look at the stream classes used to output SVG to flies and memory while working on fixing the clipboard bug. The functionality of those classes is largely the same as std::iostream and the related class hierarchy. I think Inkscape could switch from its own stream implementation to the standard library streams. This would, among other things, reduce the complexity of the application and the size of the codebase.
Is there some good reason Inkscape uses its own stream implementation instead of the standard streams?
One main issue is that std::iostream is broken in regards to internationalization. One can't really use the wide API's, and other behavior starts to get weird when one goes to use things in a non- American context.
Switching to std::iostream actually could *increase* both the size of the codebase and the complexity of the application. In order to safely use std::iostream one would need to add more code everywhere IO is done, and ensure it is done correctly everywhere.
If you look at the classes an API, you might see a similarity to Java's IO classes. That is due much to Java needing to properly handle Unicode and byte<->character conversions. Remember, bytes and characters do not always correspond one-to-one, so conceptually a byte stream is a *very* different thing from a character stream.
Additionally you can look at the top of inkscapestream.cpp:
/** * Our base input/output stream classes. These are is directly * inherited from iostreams, and includes any extra * functionality that we might need. *