Hi, On Fri, 2007-04-06 at 14:06 +0200, Carsten Neumann wrote: > Hi Gerrit, > > I've looked at the MField sync and have a couple of questions (I know > you are still working on parts of this, so some questions might not be > relevant):
which branch did you look at ?. For this the mixin-collapse one is best. > - I think AspectOffsetStore should be std::vector<ptrdiff_t> otherwise > I'd (maybe naively) expect problems on 64 bit archs ? yup, that might be better ;-) > - AspectStore::fillOffsetArray invokes undefined behavior, I think, by > performing pointer arithmetic on pointers that do not point into the > same array (I've tried to read the relevant parts of the standard, but > the language it uses is a bit difficult ;) ). I'm aware this is not > likely to be a problem, but I wonder how long it will take until some > clever compiler uses this to optimize the loop in that function away and > returns a vector full of -1 entries ? which part of the standard ? > - fillOffsetArray is called quite often it seems, wouldn't it make sense > to pass the AspectStore to the relevant functions instead and cache the > offsets there, for example ? which functions ? It is only used during the sync (where the offset arrays are passed around) and during the resolveLinks but there only if the container contains a value (e.g. non pointer) mfield. Given you might want to try to optimize this and pass the array around too, but there is a trade off between creating it always and passing it around or creating it only on demand. As I did not have any timings I chose the simpler version to create the array locally on demand during resolveLinks > Or we could cache the offsets of the fields from the start of the > container. This would never change (except for DynamicFieldAttachment) > even if container copies/instances in some aspects a destroyed and > recreated. well it does change as the offsets are relative to the ref pointer passed which is either this during resolveLinks or the destination pointer during the sync. As the offsets need to be relative to the target container caching might not work that well because you would have to readjust the offsets according to the target container. regards, gerrit ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
