Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Also, length-prepended strings. :)
Posted Mar 5, 2007 21:14 UTC (Mon) by k8to (subscriber, #15413)
Certainly using them where they don't belong is awful, but I don't see a problem with them fundamentally.
Posted Mar 6, 2007 0:50 UTC (Tue) by ldo (subscriber, #40946)
Back in my Mac programming days (pre-OS-X), the APIs were full of "Pascal"-format strings, which started with a length byte. A maximum length of 255 may not sound like much, but I estimated that over 90% of the string objects in my programs fitted quite comfortably into this limit.
One thing, I was always careful to pass maximum buffer lengths. To reduce the chance of mistakes, I used macros like this:
#define Descr(v) (void *)&v, sizeof v
which I would use like this:
That way, if the destination buffer was too small for the string, the worst that would happen was that it was truncated--you would never get overwriting of random memory.
Posted Mar 6, 2007 6:59 UTC (Tue) by njs (guest, #40338)
Posted Mar 6, 2007 22:52 UTC (Tue) by nix (subscriber, #2304)
Plus, the length byte was never long enough, and the overhead of keeping
the length up to date dominated surprisingly often, even dead-reckoning
them. At least with null-terminated strings you don't need to work out the
length unless you need it.
String ADTs make more sense :) internally they can do whatever they like,
possibly a varying representation depending on the length.
I did this and more with an adaptive string ADT I wrote a few years ago
for an application my then employer wanted. If you kept asking for the
length of a string it started tracking the length itself; if you kept
inserting and deleting from it, and it was long enough, it switched the
representation to a buffer-gap; if you kept on asking for subsets of the
string and it was long enough to blow the dcache (I randomly picked 64Kb),
it turned itself into a position-keyed binary tree, and if the string was
long enough and rarely-read enough it started zipping the longer and
more-rarely-referenced hunks up with zlib.
There would doubtless be more tricks I could have used, but that was all I
needed to get performance up for that application. It wasn't dealing with
strings longer than 200Mb, after all. ;)
One of these days I should rewrite it (I'd call it `clean it up' but it's
too dirty for that, it needs a rewrite, not least because I want to hold
the copyright this time) and release it, only there's probably no point as
someone else has doubtless written something much better.
(Judy trees, which I didn't discover till much later, of course knock the
socks off this, but their API uses such awful names for basically all its
functions that I've not yet been able to bring myself to use them. I
wonder if they'd accept a patch adding names that it's actually possible
to remember? The Great Lowercase Letter and Vowel Shortage ended *years*
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds