Re: [openvrml-develop] Rearchitecture issue

[Braden M. <br...@en...>]

On Mon, 2002-04-29 at 05:01, ja...@on... wrote:
> En r=E9ponse =E0 Braden McDaniel <br...@en...>:
>=20
> >=20
> > The problem seems to be that there is no defined means of casting the
> > object while it's being constructed. I don't see how to get around
> > that.
> >=20
>=20
> It looks that even after having ensured that the NodeType member is creat=
ed, if
> ScriptNode is not fully constructed,  accessing its members or casting it=
s
> address (it is more or less like accessing its base class subobject) is s=
till an
> undefined operation.
>=20
> After analyzing the code posted to comp.lang.c++.moderated I guess that t=
he B
> class represents NodeType.
>=20
> In such a context another idea is to create a factory method or even an o=
bject
> that creates a B (NodeType) object on the heap then constructs a D object=
 that
> aggregates the B object.
>=20
> Something like:
>=20
>=20
> class B {};
>=20
> class A {
>   public:
>     A(B & b) {}
> };
>=20
> class C: public virtual A {
>   public:
>     C(B & b): A(b) {}
> };
>=20
>=20
> class D: public C {
>   public:
>   static D* create()
>   {
>     B* b =3D new B;
>     return new D(b);
>   }
>=20
>   D(B* b): A(*b), C(*b), m_b(b)
>   {}
>  =20
>   private:
>   std::auto_ptr<B> m_b;  =20
> };
>=20
> Now it should be C++ standard compliant but the ScriptNode objects cannot=
 be
> created on the stack with the create function. In such a case it is up to=
 class
> user code to provide a B object and construct a D object. Such an operati=
on may
> be simplified with a helper function creating a B object, but still its
> feasibility depends on how complicated is construction of a B object and =
if it
> can be separated from constructing a D object.

Cool... I think that would work.

At this point I've already committed a change that just avoids accessing
the NodeType from Node's constructor. I'm not sure how necessary that
access is. For one thing, as I mentioned, the flag that was being set
isn't ever getting checked. For another, I suspect it may be more
appropriate to make the method call in individual concrete Node subclass
constructors--a number of nodes will have a "nil" bounding volume
(interpolators, TimeSensor, etc.), and so shouldn't have a need to set
that flag at all. Or so I think.

> On the other hand I think that specifity of ScriptNode may justify such a=
n
> additional burden.

Yes; even under the current scheme, there are special construction rules
for ScriptNode.

> Maybe even addition of a 'create' inline static function to
> every Node derived class would appear useful? I guess most Node objects a=
re
> created dynamically (either by parser or user code) and such a function m=
ay
> handle some obvious constructor parameters ( like scene() ) and shield fr=
om any
> future object construction modifications.

Most nodes get constructed by a factory method on their associated
NodeType object. This doesn't work for ScriptNodes since their NodeTypes
are per-instance. As the code currently stands, ScriptNode is the only
node type that is constructed with an explicit call the the constructor
in client code.

Because it's already a special case, I don't have any problem using a
static factory method instead of a constructor call to create a new
Script node. And stack allocation is never going to be a realistic
scenario for Node instances anyway, so I don't see that as an issue
either.

However, I would like to get some justification of the need to access
the NodeType from Node's constructor before making special
accommodations so that can happen. It's quite comforting to know we have
a solution if we need it. Thanks!

--=20
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>