Re: STRING * n support in StarBasic

On 10/25/2012 01:17 AM, Norbert Thiebaud wrote:
> On Wed, Oct 24, 2012 at 6:41 PM, Stephan Bergmann <sbergman@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:
>
> 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