Re: Saving C++ based data structures
Re: Saving C++ based data structures
- Subject: Re: Saving C++ based data structures
- From: Dan Price <email@hidden>
- Date: Wed, 7 Dec 2005 01:29:44 +0000 (GMT)
>
>Hi Dan.
>
>
>
>Boost serialization library, I think. I haven't
really thought about
>
>how it would work with hybrids, like you've got, but
you should be
>
>able to use overloading to take care of Objective-C
types, so it
>
>would all integrate together perfectly. Take a look
at the docs:
>
><http://www.boost.org/libs/serialization/doc/>
Thanks, but I would rather avoid 3rd party libraries
if possible.
>
>If you want to stick with NSCoding, you could have
encodeWithCoder be
>
>a virtual function in Shape:
>
>void encodeWithCoder( NSCoder* coder ) const;
>
>You'd have to compile your class with Objective-C++
in that case.
>
>Anyway, ShapeNode's encodeWithCoder method would
then just forward
>
>calls to the Shape pointer it contains:
>
>- (void) encodeWithCoder:(NSCoder *) coder {
>
> ([self getShape])->encodeWithCoder( coder );
>
>
This would work for saving, but I'm trying to keep my
C++ classes as 'pure' as possible - they know nothing
of Cocoa or ObjC.
>
>The main issue is that because there is only a
single objective-c
>
>front-end to the c++ objects, the unarchivers won't
know how to tell
>
>the difference. You can handle this is a couple of
ways:
>
>1. The Shape object can encode some kind of type
information. It can
>
>decode that information and call an appropriate
constructor when
>
>being unarchived. That probably means a big switch
statement, which
>
>is anathema to most OO programmers.
This is pretty much what I'm doing right now with
ShapeNode's initWithCoder() method. Each C++ class as
type enum which identifies it and this is encoded with
the data. A switch statement then creates the
appropriate object. It's messy, but this is compromise
of hybrid code.
>
>2. Create a parallel Objective-C class tree to your
C++ tree. So
>
>you'd have a subclass of ShapeNode for each subclass
of Shape. (Well,
>
>from your description it seems that ShapeNode is
actually a little
>
>more than a wrapper around a Shape, since it
actually contains an
>
>array; so first you'd make a wrapper that didn't do
anything at all
>
>except hold a single Shape pointer and had some
forwarding methods;
>
>then ShapeNode would contain a pointer to a wrapper
and the array of
>
>child nodes.) The subclass would pretty much forward
encodeWithCoder
>
>and construct appropriate subclass when
initWithCoder was called.
>
>
>
>Derrick
This is OTT for what I'm trying to accomplish and
would likely outweigh the advantage of having a C++
core. I do see how it would work though. The only
reason I have arrays of NSObject-based ShapeNodes
write now is to manipulate my scenegraph with drag and
drop in an NSOutlineView. Otherwise, I would be using
straight <vectors> (which was the case originally -
worked fine with a non-hierachical NSTableView).
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
http://uk.security.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden