Hello Carsten,
Carsten Neumann wrote:
> yes, to create new FieldContainers or modify existing ones you
basically
> write or edit a .fcd file and have FCEdit generate the
> SomeContainerBase.{h,cpp,inl} and (for a new container)
> SomeContainer.{h,cpp,inl} as well. Then you add functions/code to the
> latter.
> The easiest way to get started is to take an existing .fcd and modify
> it, e.g. by adding new fields.
>
> To generate the files you'd run commands like these (the cmd line only
> variant of fcdEdit is called fcdCompile):
>
> fcdCompile -d SomeContainer.fcd -b -p /Path/To/Write/Files/To
>
> for the base files and
>
> fcdCompile -d SomeContainer.fcd -f -p /Path/To/Write/Files/To
>
> for the non-base files.
This worked fine and is now part of my toolbox.
> I'd be happy to add such a contribution, however I'm wondering if it
> would be better to add a MFInt32 _mfChoices; to such a type and allow
> selection of an arbitrary number of children ?
>
> NodePtr msN = Node::create();
> MultiSwitchPtr ms = MultiSwitch::create();
>
> msN->setCore(ms);
> msN->addChild(c1);
> msN->addChild(c2);
> msN->addChild(c3);
>
> ms->editMFChoices()->push_back(0); // select c1
> ms->editMFChoices()->push_back(2); // select c3
>
> What do you think ?
Actually, I did build such a core, but I'm not satisfied with the result
for several reasons.
At first, the interface is less flexible than using a bitfield. You
have, for instance, to clear the whole multi field and rebuild it in
order to switch to another set of nodes. In addition handling the
selection of the child nodes with their particular index is also only
feasible for small numbers of nodes.
Second, for efficience reasons. Using a multi field does imply testing
for each entry to the multi field. This is efficient only for a small
size. However, then I'm fine with the bitfield implementation. If the
size is growing some kind of sorting is inevitable. This however,
inefficient for itself.
At last, using the bitfield design I got the corner cases if NONE and
ALL for free. Using the multi field approach, however, does imply an
additional field plus interface.
So I'm inclined to use the original bitfield implementation. I think
that this implementation is perfectly well suited for most of the use
cases.
What do you think?
I will send you my bitfield implementation privately. The mailing list
attachement did not work. I did name it Select core. Do you can live
with this naming or do you prefer another wording.
With best regards,
Johannes
P.S.: What is the policy of the OpenSG framework with respect to third
party libraries? Especially, with respect to the boost libraries? If I
remember correctly, they have a dynamic bitset implementation. But I
guess that the fields must be of the special types provided by the
framework.
____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.4903 from 11.08.2008
Virus news: www.antiviruslab.com
-------------------------------------------------------------------------
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
