Hi All,
Carsten Neumann wrote:
> [adding the core list back to cc; sorry I had dropped it accidentally in
> my last reply. I'm not trimming quotes here, to allow everyone to catch up.]
>>>> First questions (decisions) ;-)
>>>>
>>>> Names
>>>>
>>>> - for apps I would tend to go for RefPtr (e.g. NodeRefPtr) without
>>>> the Global thing.
>>> The GlobalRefPtr are only needed for things that potentially live past
>>> osgExit. If they are used far more widespread (i.e. become the default
>>> application pointer) I guess some more thought should be put into their
>>> implementation. At the very least, I think, the internal list they
>>> maintain should be sorted to speed up searching.
I would not make them default, as they do have some overhead that is only
needed
for a few cases.
If we can live with an if in the RefPtr destructor I would make the test to
avoid crashing even in opt libs (maybe output an INFO message), leave the use
of
GlobalRefPtr to those that need to search for memleaks.
>>>> - Simular I would change the current Ptr to CPtr (e.g. NodeCPtr)
>>>> - this way we should find most occurrences.
>>> Uhm, find most occurrences of what?
Yeah, I didn't get that one either. Can you give us a little more detail here?
>>>> Concepts
>>>>
>>>> - RefPtr should never auto convert from/to normal pointers
>>>> - this is similar to boost
>>>> - this should remove the transit ptr.
>>>> - basically make the transitptr the refptr
>>> this is tightly related to the argument/return type used for functions,
>>> see below.
>> this is one of my problems, a lot of comments, including the boost
>> shared_ptr FAQ, say auto conversion on this kind of pointer class is
>> not really a brilliant idea.
>>
>>> >From the boost FAQ
>> Q. Why doesn't shared_ptr (or any of the other Boost smart pointers)
>> supply an automatic conversion to T*?
>>
>> A. Automatic conversion is believed to be too error prone.
>
> it is sad that the boost folks have settled for such a weak answer to
> this question, not even giving pointers to any discussions :(
> I would have very much like to see the arguments that have led to that
> decision (I just read up on this in A. Alexandrescu "Modern C++ Design",
> Sect. 7.7, he does not seem to be that unequivocal about the issue).
>
>> Similar I ran into trouble with other auto conversions where the
>> compiler choose a different code path which resulted in wrong
>> results at run time. No crashes just wrong numbers popping up once
>> in a while. And these were painfully hard to find.
>>
>> So I'm a little bit sceptical of auto converting anything especially as
>> you get hit by differences in compiler implementations.
>
> Hm, for pointers I find it hard to think of any cases where this
> actually can happen. Most uses are: calling a member function through
> the pointer, pass the pointer to a function.
> The general guideline should be that anyone not using ref ptrs should
> have a very clear understanding of what they are doing, or things will
> break easily.
We couldn't figure out a good alternative to using cptrs in the interface
without things getting messy. But having to explicitly cast every time you want
to feed a RefPtr into a method sounds very annoying (on a level of
begin/endEdit
or even higher, IMHO).
Do you remember a case where pointer casting bit you?
>>>> - Factories/Loader return ref ptr ?
>>>> - this should be fine
>>> they return TransitPtr now, which made it pretty straightforward to find
>>> a lot of cases where Ptr had to be replaced by RefPtr.
I would like to keep the TransitPtrs just for that case, i.e. finding problems
especially for porting apps.
For this and other things I was thinking about adding a third lib type,
instrumented. Dbg and opt would be binary compatible, and instrumented would
allow us to change things to facilitate debugging at the cost of needing a
recompile. Comments?
>>>> - Member functions take/return ref ptr ?
>>>> - this is the tricky bit.
>>>> - Internally we might to like use the raw ptrs whereas externally
>>>> it should be ref ptrs.
>>>> - The cleanest option would be to duplicate what we need as
>>>> explicit raw pointer access and clearly mark it for internal
>>>> use.
>>>> - or force the parts that need raw pointers to move through
>>>> the field instead of the container interface.
>>> the interfaces currently intentionally use raw pointers (and BTW manage
>>> to render without any refcount changes). The question is where this
>>> causes problems.
>>> To make it usable, this requires that RefPtr is convertible to raw
>>> pointer (it is only _explicitly_ convertible from raw pointer though). I
>>> don't think much harm can be done by this conversion, as things like
>>> delete pFC; are unusual in an OpenSG program anyways.
>>> Can you point out what problems you foresee with this ?
>> It's not so much problems, I'm still struggling to find consistency.
>>
>> Currently some pieces have changed pointers, e.g the factories, the
>> loaders, some don't.
>
> More pieces could/should be changed to ref ptrs, but the transit ptr
> basically made sure that the first pointer a newly created object is
> stored to is a ref ptr and not a raw pointer.
Anything that functions like a factory (i.e. returns an object from the system)
should return RefPtrs. If not it's a bug.
>> Than there are all these pointer variants which
>> I expect to be of some use. So I still trying to wrap my head around
>> it. Again against the background of not auto converting these pointers
>> to raw pointers.
>>
>> If everything inside OpenSG stays as common c-ptrs why would we need the
>> transit ptr. OR are they just there to enforce something ?
>
> If everything on the inside stays as c ptrs, the factories can not
> return ref ptrs.
Well, not trivially. We would have to assign the factory return to a RefPtr and
manually increment the refcount before storing it in a cptr. Ugly, admitted,
but
doable if it really helps.
>> At least they force some of the internal places to deal with RefPtrs
>> which as soon as they are passed to a function disappear.
>
> Think about it like this: Everything that wants to store a pointer to a
> container either has to put that pointer into a field or use a ref ptr.
> Hm... How early may the d'tors for a function argument be called? If
> the arguments are passed by value, can the d'tor call be executed after
> the copy construction, but before the actual function call? That could
> be a problem, when passing a ref ptr to a function that takes a c ptr
> and the ref ptr has no further use after the function call.
I would be surprised if the compiler was allowed to do something like that. But
I haven't read the spec at that level of detail.
>> Can't we keep it simpler and consistent by not using any RefPtr inside
>> OpenSG.
>
> As I said above, that means factories can not return ref ptr (or transit
> ptr), which indeed was meant to force everyone to use ref ptrs (but
> since it uses the same interfaces OpenSG is included in everyone ;) ).
See above.
>> And only provide RefPtrs to be used in user/app code.
>>
>> The only drawback I see is that we can not force the user/app to use
>> RefPtrs.
>
> yes, how much of a drawback that is in reality is probably a central
> point to judge.
IMHO a fairly serious one. We want people to use RefPtrs to avoid all the mess
of dangling pointers. The easiest to force that is to return them (resp.
TransitPtrs) from the factories.
I'm missing a bit of the beginning argument though. FWIU the Fields store c
ptrs
and do manual ref counting anyway, so what's the actual problem right now?
Yours
DIrk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
