Hi Robert,
2010/1/19 Robert Osfield <[email protected]>:
> Having a single plugin we ease maintenance and make it easier to
> dynamically decide what version of the .osg file that file is being
> loaded. It will also lead to a smaller footprint on disk as the less
> will be less plugins sitting on disk, and also small footprint in
> memory if you are loading .osg and .osgb files as again only one
> plugin will be loaded. For static builds I think it'd also help as
> there wouldn't be any confusion about trying to include symbols from
> the wrappers twice.
>
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.
>
> 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.
> Next step after that will be to refactor your new plugin so that the
> wrapper infrastructure classes are all in osgDB, the wrappers placed
> in src/osgWrappers/serialization, and have the osg wrappers loaded by
> default. We'll need to modify your new classes that will go into
> osgDB so that they automatically load the wrappers required for the
> NodeKits.
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. :)
Regards,
Wang Rui
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
