STRING * n support in StarBasic
sbergman at redhat.com
Thu Oct 25 01:37:01 PDT 2012
On 10/25/2012 01:17 AM, Norbert Thiebaud wrote:
> On Wed, Oct 24, 2012 at 6:41 PM, Stephan Bergmann <sbergman at redhat.com> 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:
> 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
> leak or not ?
So if get_some_OUString_pointer adjusted N accordingly for the caller to
"consume" the string, everything should be fine.
More information about the LibreOffice