Re: gets() and "string" variable type
Andy Drummond wrote:
>
> I have followed the CR / LF / CRLF discussion with interest.
> Personally I am with Christian in agreeing that gets() is to
> look for the reasonable end-of-line indicator, which can be
> any of those arrangements, with VT or FF thrown in too.
>
> What I would like to see addressed too is the possibility
> of a type "string", which is a string of bytes rather than
> a sequence of 32-bit words. The memory saving is significant,
> and the possibility of strings containing non-characters is
> completely removed. Granted one could force the latter but
> you still have this wasteful 32-bits per character. A poke()/
> peek() could reduce the data size but is a very messy way to go.
>
> I suppose the Unicode argument will wreck all I have said,
> but a string type would simplify a lot of text processing.
> So - comments?
This and other extremely useful additional Eu types will resquire more native
types included. This will be very difficult to do without a thorough
reexamination of bit and test patterns, as discussed before. Adding them
straight into the interpreter is probably impossible.
Since this idea raised only "don't do anything" knee jerk reactions, while
collective, careful study of the backend, coupled with extensive experimentation
and testing, is probably what was needed, do as I do: use other languages for
efficient string handling. You'll usually lose the benefits of the & operator in
the process - can't have it all.
CChris
|
Not Categorized, Please Help
|
|
