Re gets and "string" variable type
CChris wrote:
>
> Andy Drummond wrote:
> >
> > 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.
That's not necessarily true. Andy mentioned one possibility, even though
he dismissed it. I'd argue that only if you're loading a very large
amount of text is this even necessary. But even if it is necessary,(and I'm
seriously considering it for the next iteration of wxIDE) that doesn't make
it a bad thing. For most uses, using sequences in the normal fashion works
just fine.
You could wrap the memory based string functions to minimize some of the
messiness. A great improvement could be made if we get structured access,
along with the ability to add routines. Then all of your nice string
functionality could be encapsulated in a string UDT.
> 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.
I've only ever come up against dead ends when studying the backend. I
think Rob has had similar experiences. He's said that there's still some
room for adding primitives, but it would complicate many things, and add
a *lot* of code (and bugs, of course) in many places. I can't speak
for others, but I do not consider my opposition to a string type for
euphoria to be knee jerk.
I generally find that Euphoria is sufficient for all but the largest of
string handling jobs. I occaisionally use perl (mainly for the regexp
functionality) although now that wxEuphoria supports them, that's happening
less and less. I usually can't tell the difference between run times of
perl and euphoria code (though I will admit that it's often quicker to
write the perl version--mainly due to built in regexp and hashes).
Matt
|
Not Categorized, Please Help
|
|
