Hi Wang Rui,
On Fri, Jan 22, 2010 at 5:01 AM, Wang Rui <[email protected]> wrote:
> 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.
The name ObjectRegistry is potentially confusing for users whien they
start looking at osgDB, so I'l like to come up with a new name that
doesn't overlap with osgDB::Registry. ObjectWrapperManager perhaps?
I'm struggling to think of a better name.
I want to refactor the old DotOsgWrapper support into osgDB::Registry
to follow the decoupled approach we already have with ObjectRegistry,
so pull out DotOsgWrapper methods in Registry out into their own
DeprecatedDotOsgWrapperManager class. Then Registry would have a get
method for both the ObjectWrapperManager and the
DeprecatedDotOsgWrapperManager, and the macro's would then redirect
them selves to these new classes.
>
>> 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?
It does seem a more nature approach to take. Could you have a bash at
implementing this and see how you get on.
>> 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
> }
I wouldn't follow this approach as it'd mean maintaining more code
with some paths rarely getting compiled and runtime tested - it would
almost certainly lead to bugs down the road. It's almost alway best
to avoid conditionals like this in code, especially so when they
behave differently.
What I'd like to see is an approach like I took with the .ive plugin -
it does mean slightly more code in terms of checking for whether to
abort a read or write compared to using exceptions, but it'll be less
code than a conditional compile approach which tries to do both, and
far easier to maintain.
>> 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.
If you wanted could organize a little section on the history side then
please feel free to ping me and others for it. With the nature of the
project I think it's healthy to know that it's not been developed by a
big corporation or a bunch of engineers from a different world.
> And wish my child born quicker
> than the 5.0 version of OSG. :)
OOo I think you have a good chance there, we be lucky if OSG-5.0
appear in the next five years, we haven't even got OSG-3.x series out
the door yet, let alone contemplate what major changes might instigate
an OSG-4.x series.
Cheers,
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
