I wonder: My assumption is that SfxItemPool::GetItemCount() will still return USHORT, right?
We just change one implementation detail (internal array will use a different container), but we don't change the SfxItemPool API (which probably would be the CWS new_itemsets, where we also might change API, don't know). Does it really make sense to store anything larger than USHORT, while the SfxItemPool API is still USHORT? I don't think so. So I suggest to keep USHORT for persistence, and really only focus on the task to replace the array implementation and nothing more. Why introducing unnecessary side effect or possible incompatibilities? Malte. Michael Stahl wrote, On 10/13/10 17:04: > On 13/10/2010 15:54, Christian Lippka wrote: >> Hi Michael, >> >> Am 13.10.2010 15:35, schrieb Michael Stahl: > > [...] > >>> does anybody know where (or if) this method is still called? >>> i was of course suspecting the dreaded binfilter to call it, but actually >>> binfilter seems to have its own svtools copy complete with item pools, so >>> that can't be it. >>> >>> OpenGrok finds 138 definitions of a "Store" method, and 479 callers. >>> now, if it were possible to parse C++, perhaps i would know which of these >>> call this particular Store... >>> >>> in case it is still called, what should be done to introduce a new >>> incompatible version here? >> >> An incompatibility would only arise if we still exchange binary data >> between different versions. To my knowledge we do not do this anymore. >> We still have binary clipboard in some cases but clipboard never worked >> between different versions (f.e. no clipboard between a running OOo 2.0 >> and OOo 3.0). > > ok. > >> The only Problem could be if this implementation is also used by the >> binfilter module, but I think binfilter cloned the sources regarding >> items. But you should double check that. > > have already checked that (as mentioned above :) > >> So if I'm not mistaken, you can change the binary stream operations >> as you like, as long as load and store is the same of course :-) > > ok, this means we'd have to find the place where this thing is loaded > again and check that it's also changed to size_t... > of course size_t would be an inappropriate type for a file format anyway > as it has varying size; perhaps a sal_uInt64 is in order... > >> Regards, >> Christian > > PS: your mail didn't make it to the list (or at least to the Gmane version > of it) - any idea why? > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
