Hello Marcus,
Marcus Lindblom wrote:
> Carsten Neumann wrote:
>> Marcus Lindblom wrote:
>>> Carsten Neumann wrote:
>>>> Is there a way to force the
>>>> construction to happen early ? (What triggers the construction anyways ?)
>>> Construction of these are on demand, so just call
>>> getDefault[unlit]Material().
>> hm, that creates the default materials, I was wondering more about what
>> creates the pointer objects (i.e. the objects of type
>> SimpleMaterialMTRefPtr) that point to them.
>
> Ah, no. That happens before main, but the order is undefined (except
> that it happens per dll/exe).
>
> Otherwise automatic initialization methods (like factory registration)
> would not work.
ah, right.
>> *If* these are also created "on demand" (and it looks like they are [1])
>> we have a problem, because while we could call getDefaultMaterial() from
>> osgInit it would break separation of base and system lib and does not
>> generalize well to other, similar situations. We could use a statically
>> created object to call addPostFactoryInitFunction with a function that
>> just calls getDefaultMaterial, but I don't see why that object should be
>> "on demand"-created at all?
>> I need to see if/what the standard has to say on the point in time when
>> static objects are created.
>
> I think it works like this, given my current "battle experience" :)
>
> Static initializers are constructed in order inside each compilation
> unit, but the order between compilation units is undefined, except that
> calls between compilation units (during static initialization) forces
> on-demand initialization.
ok, the undefined order should not be a problem here.
> This breaks down if you have recursive initialization dependencies
> between static initializations in compilation units, unless you're
> carueful. (And/or use on-demand construction singletons that do not
> depend on each other's constructors recursively.)
yes, that matches my understanding as well. What I don't get anymore at
this point is why it crashes anyways. AFAICS we don't do anything wrong.
By the time osgInit runs the pointer objects should be constructed and
from the standard quote Gerrit posted, any atexit handler registered by
osgInit should then run *before* the pointer objects are destroyed. This
order of events is fine, I think. I'm confused.
regards,
Carsten
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
