Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Internal Representation of Strings tony@my.net (Tony) (2009-02-14) |
| Re: Internal Representation of Strings mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2009-02-14) |
| Re: Internal Representation of Strings haberg_20080406@math.su.se (Hans Aberg) (2009-02-14) |
| Re: Internal Representation of Strings DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-02-14) |
| Re: Internal Representation of Strings marcov@stack.nl (Marco van de Voort) (2009-02-14) |
| Re: Internal Representation of Strings anton@mips.complang.tuwien.ac.at (2009-02-14) |
| Re: Internal Representation of Strings cfc@shell01.TheWorld.com (Chris F Clark) (2009-02-14) |
| [33 later articles] |
| From: | "Tony" <tony@my.net> |
| Newsgroups: | comp.compilers |
| Date: | Sat, 14 Feb 2009 01:21:26 -0600 |
| Organization: | at&t http://my.att.net/ |
| Keywords: | storage, question |
| Posted-Date: | 14 Feb 2009 05:09:23 EST |
What are some good ways/concepts of internal string representation?
Are/should string literals, fixed-length strings and dynamic-lenght strings
handled differently? My first tendency is to avoid like the plague
NUL-terminated strings (aka, C strings) and to opt for some kind of array
with a length at the beginning followed by the characters that could be
encapsulated at the library level with appropriate functions. But just a
length seems like not enough information: the capacity (array length) also
would be nice to have around. All thoughts, old and novel, welcome.
Tony
Return to the
comp.compilers page.
Search the
comp.compilers archives again.