Hi,
Carsten Neumann wrote:
Carsten Neumann wrote:ok. I think on this one we are not so far away as I thought ;) I'll see if I can update the patch over the day and add the correct fcd magic for the registration and the query functions, but that should not change the stuff that is in the patch at this point (much).here is a slightly updated patch, but it still does not touch the .fcd files,
as mentioned earlier, here is a new patch. Some things were I'd be especially interested in feedback are:
- I had to disambiguate the generated remove/replace functions that take an index from those that take a pointer [1]. I choose the following replaceObjIn<FieldName> and removeObjFrom<FieldName> for the functions that take a pointer. Adding a ByObj, ByObject or ByIndex suffix would be alternatives, I don't have a strong opinion on what is nicer though ;)
- for the same reason I had to change some .fcd files that already named functions different from the default, here I used the ByObj suffix, because that required less changes. I'm happy to improve consistency here, provided we can decide on a naming scheme ;)
- wrt the generated functions there are basically three pieces of information that are relevant:
* is there a function that provides the operation ?
* is it generated in base or hand-written in the class ?
* what's its name ?
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.
Thanks,
Carsten
PS: I hope the attached patch captures all changes (except the base
regen), it was done with git-diff master..HEAD on a branch in my git
repo. I'm still getting used to the workflow with git... ;)
[1] the problem is that in the expression:
boost::bind(&@!Classname!@::@!field.ReplaceInMFieldIndex!@,
static_cast<@!Classname!@ *>(this), _1, _2));
the member function pointer is not assigned to a variable (which is
normally used to determine overload resolution). A cast or temporary
could be used, but seem like a rather ugly/clumsy solution especially
considering that the index 0 also causes problems in user code, as it
can not be distinguished from a null pointer.
generic_interface-2008-06-11.diff.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------- 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
