Subject | Re: [Firebird-Architect] Re: [firebird-support] Writing UTF16 to the database |
---|---|
Author | Olivier Mascia |
Post date | 2005-02-28T14:11:47Z |
Le 28-févr.-05, à 14:10, Claudio Valderrama C. a écrit :
without any effect. Sometimes a string has to see its storage
re-allocated, certainly not character per character of course. Though
most of the times, an database engine will handle *existing* strings
whose char and byte sizes can be known in advance. I'm not sure this
could have a terrible impact. Sure, if people feel safer to allocate
the maximum size, it is clear a fixed width character representation
would be even simplier than utf. 32 bits would seem obvious in such
case.
--
Olivier Mascia
>> Those classesEducated guess would surely be okay. We do so in our applications
>> typically use dynamic memory allocation already. The only thing they
>> can't assume is byte-length == characters-count.
>
> How do you allocate initial buffer for a string defined with length 20
> in
> charactes that's going to be filled? Do you take an educated guess or
> do you
> take the worst case or do you go playing
> alloc-more-copy-and-dealloc-old
> until you have enough buffer while characters are written in the
> buffer?
without any effect. Sometimes a string has to see its storage
re-allocated, certainly not character per character of course. Though
most of the times, an database engine will handle *existing* strings
whose char and byte sizes can be known in advance. I'm not sure this
could have a terrible impact. Sure, if people feel safer to allocate
the maximum size, it is clear a fixed width character representation
would be even simplier than utf. 32 bits would seem obvious in such
case.
--
Olivier Mascia