Re: Saving C++ based data structures
Re: Saving C++ based data structures
- Subject: Re: Saving C++ based data structures
- From: Derrick Bass <email@hidden>
- Date: Sun, 4 Dec 2005 22:27:40 -0600
On Dec 4, 2005, at 7:13 PM, Dan Price wrote:
Hi Dan.
If you don't care about NSCoding compatibility, then you can use the
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/>
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 );
}
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.
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
Greetings
I'm writing a rather complex 3D modeling application.
The interface code is standard Cocoa and Obj-C in a
document framework, but the guts of the program is C++
for the sake of speed, and overloaded operators etc
(it's quite Math heavy). I need to come up with a way
to save out the scene data to XML, but object-value
encoding is proving to be too inflexible. I have an
NSObject-based wrapper class, ShapeNode, which
maintains a pointer to a C++ class, Shape. The C++
class handles drawing to OpenGL, transformation etc.
ShapeNode has an NSMutableArray of child ShapeNodes.
The document object has a single ShapeNode, root,
which represents the top of the scene-graph hierarchy.
So I've got Obj-C wrappers, in an cocoa-style
NSMustableArray database, pointing to C++ objects.
Object-value encoding requires NSObject classes to
adhere to the Encoding protocol and must contain
standard accessors to the object data. But other than
basic stuff like name(), my interface code gets and
sets data to the C++ Shape object directly. ShapeNode
is just simple wrapper.
I could just write a routine in the document object
which visits every object and writes it's data
explicitly, but many of the C++ Shape subclasses have
unique properties (like float ratios and
feature-enablers specific to that object) which would
require the document class to know far too much about
them. I need a object-value encoding style system
where every object is simply asked to save itself and
load itself from the XML. Any ideas as to how I could
do this?
Sorry for the long post - I hope this makes sense.
___________________________________________________________
Yahoo! Model Search 2005 - Find the next catwalk superstars -
http://uk.news.yahoo.com/hot/model-search/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40tapir.caltech.edu
This email sent to email@hidden
_______________________________________________
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