Hi Robert
2010/1/21 Robert Osfield <[email protected]>:
> I've just merged the addition of the exports for for now I haven't
> merged the integration of ObjectRegistry into osgDB::Registry as I'd
> prefer to keep it decoupled. The way I'd like to go with both
> DotOsgWrappers and the new wrappers is to have a dedicated container
> class for each of these that is attached to osgDB::Registry, so
> Registry "has a" wrapper container, rather than "is a" wrapper
> container.
OK, to have an independent ObjectRegistry class won't affect the
serializers. Also a base class for DotOsgWrapper, ObjectWrapper and
even the BaseCompressor would be much convenient, and the public
methods in osgDB::Registry will be clearer in reading.
> I'm in two minds about merging Output and OutputStream. How much
> overlap do you see? My main concern would be avoiding one huge class
> that tries to do too many different tasks.
> Renaming isn't too difficult, a quick sed script can tackle renaming
> pretty easily.
The Output class uses stream operators for writing, too, which are
derived from the ostream class. So it won't be too hurt to rewrite the
3rdparty nodekits and plugins with the new OutputStream class later.
I'm also thinking of reduce the InputStream/OutputStream to avoid
handling ascii/binary/xml formats in an overstuffed class or method,
as you said before.
My plan is to make OutputStream a pure virtual base class, and inherit
from both the OutputStream and a derived ostream class, which could
handle only ascii or binray stream data. This will keep the already
generated wrapper classes unchanged, reduce the too much '<<' and '>>'
operators, and improve the reading/writing efficiency. Like this:
class OutputStream;
class AsciiOutputStream : public virtual OutputStream, public ascii_ostream;
class BinaryOutputStream : public virtual OutputStream, public binary_ostream;
And in writeNode() function of the ReaderWriter:
OutputStream* os;
if ( isAsciiOption() ) os = new AsciiOutputStream;
else os = new BinaryOutputStream;
os->writeObject( ... );
It seems to be better than just do both tasks in a huge OutputStream.
What's your opinion?
> The how stop to reading/writing is something that is very conviniently
> solved by exceptions, without them you have to set a flag and then
> check it periodically to see if one should keep working on the task.
> One can use whether an exceptions has been set as to whether one
> should stop reading/writing.
So, could we have a macro to throw exceptions in different ways? Such like:
void throwException( const std::string& msg )
{
#ifdef EMBEDDED_SYSTEM
osg::notify(osg::WARN) << msg;
#else
throw Exception(msg);
#endif
}
> The OSG project got a bit of boost in it's infancy at the same time as
> the arrival of my first child. My wife and daughter would sleep
> during the day, rise late, go to bed early, for the first few months
> so I'd be left alone, awake but enable to head out and do my usual
> venture sports - so I just tinkered with code for fun instead. It's
> funny how the OSG and my eldest daughter have grown in parallel. I
> must be said she got to 1.0 much quicker than the OSG
Really interesting. I'd like to add these to my Chinese OSG book if I
have the opportunity to reprint it. And wish my child born quicker
than the 5.0 version of OSG. :)
Cheers,
Wang Rui
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
