Re: Internal Representation of Strings

"cr88192" <cr88192@hotmail.com>
Fri, 6 Mar 2009 18:17:52 +1000

          From comp.compilers

Related articles
[33 earlier articles]
Re: Internal Representation of Strings marcov@stack.nl (Marco van de Voort) (2009-02-27)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-02-28)
Re: Internal Representation of Strings cr88192@hotmail.com (cr88192) (2009-03-03)
Re: Internal Representation of Strings armelasselin@hotmail.com (Armel) (2009-03-02)
Re: Internal Representation of Strings tony@my.net (Tony) (2009-03-03)
Re: Internal Representation of Strings hebisch@math.uni.wroc.pl (Waldek Hebisch) (2009-03-05)
Re: Internal Representation of Strings cr88192@hotmail.com (cr88192) (2009-03-06)
| List of all articles for this month |
From: "cr88192" <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: Fri, 6 Mar 2009 18:17:52 +1000
Organization: albasani.net
References: 09-02-051 09-02-068 09-02-078 09-02-120 09-02-125 09-02-134 09-03-001 09-03-009 09-03-018
Keywords: storage, design
Posted-Date: 06 Mar 2009 06:41:06 EST

"Tony" <tony@my.net> wrote
> "cr88192" <cr88192@hotmail.com> wrote
>> "Tony" <tony@my.net> wrote
>>> "Armel" <armelasselin@hotmail.com> wrote in message
>>
>> <snip>
>>>
>>> My goal is to get away from all the APIs that use null-terminated
>>> strings,
>>> so I will be replacing all of that. Not needing that null terminator
>>> would
>>> be an indication of success of a string implementation that wished to
>>> depart from that paradigm.
>>
>> what is the problem with NULL-terminated strings anyways?
>> my code uses them all the time with no real ill-effect...
>
> But if you were doing it from scratch, would you implement strings as
> null-terminated?


probably, and I even did NULL-terminated arrays (although, I would
probably change this as one can soon discover that NULL is a useful
value to be able to put into an array, but at the same time,
initially, I had used a different value to represent NULL as well,
...).


if I were designing them clean, I would probably use a hybrid
approach, sort of like I eventually did with arrays...


>> so, maybe the big question that can be asked is:
>> really, why do you so much dislike the NULL-terminated strings?...
>
> Many reasons. Not the least of which are that they are bad and the
> implementation is ugly. ;) (Read: I don't feel like retyping
> everything already said a thousand times that is is bad about
> null-terminated strings).


I don't remember a specific deficiency being specified, nor can I seem
to find one in the thread. it is repeatedly stated that you don't
like them, but there is no clear reason for this sentiment from what I
can tell...


(so, I can't say where this was actually said, I can't find it...).




I see both pros and cons to null-terminated strings, and as I see it, for
the most part the pros outweigh the cons (and the few cases there are cons
are fairly rare in practice, such as finding the length of a very long
string, ...).


likewise, as a general rule, the algos are generally simpler for working
with null-terminated strings than with length-terminated strings, ...


so, as I see it, personally, disliking them so much does not seem
reasonable.


although, granted, I guess one could find it useful to equate strings and
string-buffers, and a length could be useful for this (or, if one
supports/uses indexing operations into strings, a length allows faster
bounds checking). all this, however, would more seem to opt for a hybrid
approach than pure length-based approach (since for other kinds of
operations the terminator would still be useful, ...).


but, oh well, I also like lists and CONS cells, as for many things they are
so much more convinient than arrays (for many tasks I use CONS-based
structures more than arrays, ...).


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.