Hi Allen,
Allen Bierbaum wrote:
> Carsten:
> I appreciate the detailed description. I think I have to read it a few
> more times to fully grasp the internal details.
>
> What I think would be useful would be to describe the the user-level API
> would look like. For example, will a user application only use
> RefPtr's? Will these handle all the internal details automatically?
> How will user apps handle aspects or will this be hidden? When the user
> needs a true cptr, how will they get them.
ok, this is not fully finalized but the idea is as follows: the
interface offered by FieldContainers will be more or less what I've
listed in the last mail. Some other points that were not very clear there:
- Interfaces accept and return plain C-ptrs (the {ContainerName}Ptr
typedefs) by value.
- The notable exception are the ::create functions and the
FieldContainerFactory, they return a pointer type that forces the user
to create a RefPtr from it. It is called TransitPtr and internally
contains a RefPtr that it passes with similar semantics as std::auto_ptr.
- Applications are intended to use ref pointers (the
{ContainerName}RefPtr typedefs) which modify the external ref count.
- Pointers are local to their aspect, if a user wants to use a pointer
from another aspect it needs to be converted explicitly, using
convertToCurrentAspect, which should probably get an overload that
accepts and returns ref ptrs directly.
- Pointer fields will store yet another pointer type (InternalRefPtr)
that modifies the internal ref count. User code is not supposed to come
into contact with this type or use it and since the current interface
does not grant direct access to pointer fields one should only have to
deal with them when working on the generated code.
> I guess what I am saying is that I am asking a much simpler question of
> what will everything look like to users. I am just trusting that you
> and Dirk will be able to get everything working correctly internally. :)
Well, thanks for your confidence :) but we'd also like it to be usable
in the end, so please keep asking questions if you something is not clear.
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
