Hi,
On Thu, 2009-08-06 at 14:29 +0200, Johannes Brunen wrote:
> Hello,
>
> currently I'm trying to switch to the OpenSG 2.0 codebase. In this
> context I have a couple of questions.
>
> 1. Can I safely assume the support of a boolean context from the XRecPtr
> smart pointer types, i.e. can I write something like the following?
> NodeRecPtr node = ...
> if (node) ...
> if (!node) ...
>
> If this is correct, can I then assume that I do not have to use NullFC
> anymore?
yes NullFC is gone, if you want to you can do the normal == NULL or
!= NULL comparisons. I have to check the boolean part. IIRC the old
fcptr had something special in there which the current one does not
have.
A general comment on RecPtr though. They are meant for the app to
permanently store a pointer to an object and keep the refcounts
correct in clustered environments. This comes with an overhead, so
for temporary pointers it is better to either use UnrecPtr or the
raw pointer. Especially those that are used as function parameters.
>
> 2. Dynamic casting from smart pointer does not work seemlessly. Using
> dynamic_pointer_cast from a XRecPtr does work fine, but using it on a
> TransitPtr is not supported. Is this intentionally?
yes, it is and actually in a more general form as we don't allow
TransitPtr to raw ptr conversions. The reason is that if we would, after
XXX *ptr = XXX::create();
ptr would point to an already destroyed object. I'm aware that
this results in the inconvenient fact that something like
objA->set(ObjB::create());
does not work out of the box. I'm still looking for a nice
solution which does not just add 'set transit ptr' variants.
> See the following
> example:
>
> // Works fine
> NodeCoreRecPtr nodeCore = node->getCore();
> GeometryRecPtr geomCore =
> dynamic_pointer_cast<Geometry>(nodeCore);
>
> // Not supported
> GeometryRecPtr geomCore =
> dynamic_pointer_cast<Geometry>(node->getCore());
>
> In the examples, I could not found any application of
> dynamic_pointer_cast function at all. Here only the following pattern is
> applied:
>
> GeometryRecPtr geomCore =
> dynamic_cast<Geometry*>(node->getCore());
which is correct as node->getCore returns a std C++ NodeCore * so you
can work with the std dynamic_cast. We did not overload the
dynamic_pointer_cast for std pointers. IIRC this follows boost.
> What is the proper usage pattern. Is it safe to go to the native pointer
> level?
yes. For intermediate access you can use a native pointer. If queried
for a stored pointer all OpenSG objects return a native pointer.
> 3. In the same direction as 2). I was used to work with the traverse
> function taking a vector of NodePtr parameter. In OpenSG 2.0 a vector of
> Node* pointers and a const MFUnrecChildNodePtr obect is supported, but
> not a vector of NodeRecPtr, as I assumed I should use. Again looking
> into the examples I did only found cases working directly on the Node*
> pointers.
The RecPtr variant is just missing. As we don't use it internally I
might have missed adding it. I'll do so.
> Is this the recommended way for using traverse function? What
> are the limits with respect to multithreading?
For multi-threading the only important thing is you have to
start with the pointer for the correct aspect. All FieldContainer
pointers stored inside OpenSG FieldContainers point to objects in the
same aspect.
There are two ways to do that. You either can convert to the respective
aspect manually like the csm window does
Window* pThreadLocalWin =
convertToCurrentAspect<Window *>(_pWindow.get());
before it calls render, or you can use the mt variant of the ptr,
which interestingly are only available for rec and weak variants
and also lack the traversal functions. I'll check and make it
consistent.
> 4. I did see that the TextureChunk class has gone. So I replaced it with
> the TextureObjChunk class. Then, I did found a place where I called an
> Image object's addParent function with the TextureChunk object. But I
> could not find this function in the OpenSG 2.0 Image class. Do I not
> have to perform this task anymore?
no, as the texture object chunk knows that the image is a child of it
the parent pointer of the image is automatically updated. With this,
changes to the image should propagate to the texture object chunk
without the apps having to do anything. That was IIRC a grey zone
in 1.x.
kind regards,
gerrit
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
