Hi Gerrit, Gerrit Voss wrote: > On Fri, 2007-04-06 at 14:06 +0200, Carsten Neumann wrote: [snip] > which branch did you look at ?. For this the mixin-collapse one is > best.
that's the one I looked at, r660 >> - 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 ? Section 5.7 Additive Operators, especially paragraphs 4-6. actually I had to use a draft (available here http://www.open-std.org/jtc1/sc22/wg21/docs/projects#14882 under the link "draft November 2006" -> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf). >> - 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 ? basically syncWith, resolveShare and terminateShare in MField, those are the ones that make use of the offsets from what I can see. > 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 agreed, without timings it is not possible to make an informed decision here. >> 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. Either I misunderstand what you are writing here or you misunderstood what I've suggested above. I'll try to explain my idea better: Let's say we have a container SomeContainer with two MFUInt32 (_mfData1, _mfData2). To perform the sync or resolveLinks we need to obtain pointers to the fields in all (existing) aspects. AspectStore can give us the pointer to the SomeContainer instance for each aspect // pointer to the container in aspect i SomeContainer *pAspect = dynamic_cast<SomeContainer*>(_pAspectStore->getPtr(i)); now _mfData1 will always be a constant number of bytes further in memory than pAspect, i.e. // obtain pointer to _mfData1 in aspect i MFUInt32 *pData1 = reinterpret_cast<MFUInt32 *>(reinterpret_cast<Char8*>(pAspect) + data1Offset); data1Offset is an offset from the "head" of the container to one of its members and should therefore never change. Granted this is probably at least as much outside the standard as what we currently do ;) Thanks, Carsten ------------------------------------------------------------------------- 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
