Hi Wang Rui, On Tue, Jan 19, 2010 at 6:14 AM, Wang Rui <[email protected]> wrote: > So we could simply use a unique OutputStream/InputStream pair for > reading and writing ascii, binary and xml formats. The only problem > is: would the many if/else judgements in low-level APIs be > inefficient? For instance, in the integer writing function, > > OutputStream& OutputStream::operator<<( int i ) > { > if ( isBinary() ) _out->write( (char*)&i, INT_SIZE ); > else *_out << i << ' '; > return *this; > } > > Traversing these conditional statements may cause some small loss. We > may use virtual functions instead here, such like: > > virtual OutputStream& OutputStream::operator<<( int i ) = 0; > > OutputStream& BinaryOutputStream::operator<<( int i ) > { _out->write( (char*)&i, INT_SIZE ); return *this; } > > OutputStream& AsciiOutputStream::operator<<( int i ) > { *_out << i << ' '; return *this; } > > But I'm not sure if too many virtual functions (all the operator<< and >>> functions!) would be even worse. At present, I'd like to just leave > the question alone.
Perhaps tackling the problem in a different way would be appropriate. I have been wondering if we could make the serialization side the core part of the new wrapper mechanism then have different output/input stream implementations based on this. Right now you implement serialization using stream operators, perhaps this could be continued or replaced with another scheme. Thanks to the macro scheme you've used in the wrappers we should be able to tweak the classes/templates that macros construct without having to tweak the wrappers. > >> >> My inclination right now is to partially break backwards compatibility >> in the cause of keeping it clear what is what. The way I'm thinking >> of doing it is placing all the old DotOsgWrappers/Input/Output classes >> into a single DeprecatedWrappers/DeprecatedIO header, or moving the >> deprecated headers into the src/osgDB directory but still include them >> in the exports of osgDB. > > I recommend the latter because it will automatically affect the > doxygen generated documentation, removing deprecated class > definitions, which helps developers forget the old Input/Output > classes. Otherwise we could add these classes to the deprecated list > (with a doxygen tag '\deprecated'?) and leave them in the > include/osgDB directory for backwards compatibility. For the transition period I'll add the deprecated message to all the docs for the old classes. Once we've got the new infrastructure working enough for the wider community to start adopting it not just to load files but adding serialization to their own applications/nodekits then we'll be able start pushing over to using the new scheme exclusive and make the old DotOsgWrapper headers private. > I haven't done more modifications right now. And I'm ready to help > merge the new plugin into SVN/trunk. After that, I'll start finishing > other items in my TODO list, which is already indicated in the first > post of this thread, base on the newly refactored serializiers and > wrappers directly. :) I have now checked in the refactor of the old osg plugin and the NodeKits plugins so that all the DotOsgWrappers now exist in subdirectories off src/osgWrappers/deprecated-dotosg. You should see how the src/osgPlugins/osg contains nothing more than a ReaderWriterOSG.cpp. I'd expect your osg2 to be reduced to the same extent once I move out the wrappers and the wrapper infrastructure out into osgDB. Tomorrow I'll tackle refactoring osg2 to live in osgDB + osgWrappers/serialization and a osg2 directory, or I may even just merge osg and osg2. I'll see how I get on. I'm having to do shorter working days this week due to looking after my kids after school while my wife does a training course this week. This means I'm not getting as much done as usual. Fingers crossed I'll be able to get the osg2 plugin refactored and checked in tomorrow before I have to head out for the school run. Cheers, Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
