Hi, On Thu, 2008-06-19 at 09:15 -0500, Carsten Neumann wrote: > Hi, > > Gerrit Voss wrote: > > On Mon, 2008-06-16 at 18:27 -0500, Carsten Neumann wrote: > >>> Similar the node children should be NULL checked as no NULL child > >>> is allowed, and other parts of the code rely on this. > >> Changed as well. Can we consider moving to a generated Node class ? > >> > >>> I hope I got all the semantic side effects ;-) > >>>> Therefore the .fcd has now supports the following: > >>>> generatePushToField = "true" / "false > >>>> hasPushToField = "true" / "false" > >>>> pushToFieldAs = "myAddFunctionName" > >>>> > >>>> generate<funcname> implies has<funcname> > >>>> <funcname>As implies has<funcname> > >>>> > >>>> Of course the first two are only relevant for fields with > >>>> ptrFieldAccess="custom", otherwise the functions are generated either > >>>> with the given or default name. > >>> why is anything generated for the custom case ??. I would treat it all > >>> or nothing. If custom is selected all functions must be implemented > >>> inside the class and nothing remains in the base class. I don't see > >>> a reason to implement one half and have the other half generated. > >>> So I don't see the need for the generate part. The 'has' part if fine > >>> to select if the generic interface should support a particular function. > >> I removed that part. > > > > hmm, something seems to be slightly off, your commit still had both > > items unresolved ?? Or am I missing something. At least the generate > > part seems to be inactive as far as I can tell. > > this must be a case of me being thick, but I don't get what you are > referring to here, sorry. > If a pointer field has custom access no functions are generated, for the > other two access types they are generated. Lines 380-450 of Field.py > have the relevant code for that. This sets the generate<FuncName> > variables which are tested in the template files. > BTW these variables are not new, they were called write<FuncName> > before, but I had renamed them to match the option in the .fcd files - > which does not exist anymore, patch to go back to use write<FuncName> is > attached (there is no difference in the generated code). > The reason for not testing the access type in the template files is that > nullcheck and std access produce different sets of functions, so one > needs finer control here anyways.
what confused me was this part of your commit (TemplateFieldContainerBase_h.txt) or the last part of the attached patch: + @@if field.ptrFieldCustomAccess + @@if field.generatePushToField + void @!field.pushToField:15!@ (@!field.Type!@ const value ); + @@endif + @@if field.generateAssignMField + void @!field.AssignMField:15!@ (const @! field.TypeNamespace!@@!field.CARD!@@!field.FieldTypeCaps:15!@ &value); + @@endif + @@if field.generateClearField + void @!field.ClearField:15!@ (void ); + @@endif + @@if field.generateInsertIntoMField + void @!field.InsertIntoMField:15!@ (UInt32 uiIndex, + @!field.Type!@ const value ); + @@endif + @@if field.generateReplaceInMFieldIndex + void @!field.ReplaceInMFieldIndex:15!@ ( UInt32 uiIndex, + @!field.Type!@ const value ); + @@endif + @@if field.generateReplaceInMFieldObject + void @!field.ReplaceInMFieldObject:15!@ (@!field.Type!@ const pOldElem, + @!field.Type!@ const pNewElem); + @@endif + @@if field.generateRemoveFromMFieldIndex + void @!field.RemoveFromMFieldIndex:15!@ (UInt32 uiIndex ); + @@endif + @@if field.generateRemoveFromMFieldObject + void @!field.RemoveFromMFieldObject:15!@(@!field.Type!@ const value ); + @@endif + + @@endif for custom access it checks the generate flag which is never set in this case, as you pointed out and what my 'inactive' comment referred to. > Why they produce different sets of > functions is not clear to me, but the last time I asked about it your > answer seemed to imply it was on purpose so I left it alone ;) because you can edit the field directly. Mainly I just wanted to keep the basic interface one would typically expect to find for a fieldcontainer's pointer field, e.g. add/sub/clear. IIRC the additional one or two (e.g. remove/replace) came from special cases. I'll check if they are still needed, and if not I'll remove them. kind regards, gerrit ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
