[M3devel] AND (., 16_ff). Not serious - or so I hope!

[Dragiša Durić]

As for input encoding… Benjamin Kowarch (of M2R10 project) solved this with pragmas. There is good idea on how to instruct parser about text encoding used for source code (meaning also encoding used for string literals). As it's dependent on locals settings, it is important to let compiler know how to parse source. Of course, Unicode string literals will be stored as UTF8 strings after parsing.

On Jun 26, 2012, at 6:46 PM, Dragiša Durić wrote:

> You had idea in other message. Store length!
> 
> Another idea - store partial list of indices to character locations. So whatever one does, that list can be used/expanded. Whatever storage issues this makes, they are probably minor as compared to 32bit WIDECHAR for all idea.
> 
> Mika had performance problems with cm3 TEXT. I hope he follows and cares to refresh us on those issues?!
> 
> On Jun 26, 2012, at 6:34 PM, Jay wrote:
> 
>> I'm torn on that. We'd have to consider ramifications like Text.Length vs buffer size requirements/expectations.
>> 
>> 
>> Is TEXT & its use abstracted enough to have been widened? Should we put it back and introduce WIDETEXT? That is essentially what C and C++ do. They are inconvenient for existing code but simple predictable make sense. Contrast with weird hybrid systems like Perl & Python for which I just can't get through the documentation and understand and predict how they work..
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120626/a4d6a0f2/attachment-0002.html>