On 10/25/2012 01:17 AM, Norbert Thiebaud wrote:
On Wed, Oct 24, 2012 at 6:41 PM, Stephan Bergmann <[email protected]> wrote:
But the fix would simply be switching the implementation of
SbiRuntime::StepPAD (and possibly more) to properly use the SbxVarialbe's
OUString, and nothing more, or what am I missing? So I fail to see how that
relates to getting rid of xub_StrLen.
One issue is that String already enforce the 64K limit (despite
internally using a int32 for the len), whereas OUString, obviously
does not... should we bother enforcing that limit ? including
maintaining a distinction between 'variable-len' (Basic) String and
'fixed-len' String (which is not going to be trivial since they are
represented by the same kind of object)
That String has still that artificial-by-now 64K limit is just because
things like #define STRING_NOTFOUND ((xub_StrLen)0xFFFF), where
xub_StrLen is sal_uInt16, make it difficult to adapt existing code to
OUString's sal_Int32 length.
while on the topic of magic c++ trick:
does
OUString* a = get_some_OUString_pointer()
Assume a->pData->refCount is N > 0 now.
*a = a->copy(0,5);
a->copy won't modify a->pData->refCount while a->operator= will
decrement it by one (and if N was 1 at the outset, that will delete
a->pData).
leak or not ?
So if get_some_OUString_pointer adjusted N accordingly for the caller to
"consume" the string, everything should be fine.
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
