[M3devel] Windows, Unicode file names

[Mika Nystrom]

As far as I know, SRC M3 and PM3 come with a TEXT implementation that
works exactly as described below.  An extra byte is used at the end with
a character VAL(0,CHAR).  The Texts are simply arrays of 8-bit characters.

One of the big advantages of the old version is that Text.Hash is really,
really fast.  Especially on Alphas...  it's hugely more expensive to
have hash tables (i.e., Modula-3 generic Tables) keyed on Texts under
CM3 than under the old compilers and runtimes.  We're talking a factor
of five or so in speed since the Table routines are generally entirely
dominated by Text.Hash.

    Mika

Hendrik Boom writes:
>On Mon, Jun 25, 2012 at 08:46:18PM +0000, Jay K wrote:
>> 
>> Somewhat but not fully.  Text.Length should fetch a stored length. As 
>> I'm sure it already does.That length should always be correctly 
>> maintained. Same as today.Adding one extra nul at the end doesn't 
>> invalidate the data.std::string has the same properties -- c_str() can 
>> on-demand append a terminal nul,but there could also be one in the 
>> string itself.I understand it is a bit wierd.  Maintaining a terminal 
>> nul does add cost that might be wasted.And reduces the capacity by 
>> one.It could be on-demand, I guess.   - Jay
>
>Don't need the 'on demand'.  For the benefits of C interoperability, the 
>extra byte is well worth the price.  What I'm worrying about is someone 
>using an enbedded NUL as an end-of-string marker.  I smell more bugs 
>creeping in.  But I guess bug are inherent in C use, so I'm not 
>surprised seeing them in C interoperation.
>
>-- hendrik