Re: [reformated] Re: proposed Eistring interface
On Wed, Apr 19, 2000 at 01:32:18AM -0700, Ben Wing wrote:
you can't do alloca in an inline fun.
Fuck.
> - alloca() doesn't go well with string concatenation (no
realloca)
only if you always allocate exactly what you need. cf my Dynarr code.
I'll have a look.
> - alloca() bites you if you try to return one of these strings
to a
> caller or change a string which was given to you through a function
> call
did you miss this?
----- Moving to the heap -----
eito_malloc (eistr):
eifree (eistr):
eito_alloca (eistr):
No, I didn't miss it. That is going to make the code as intuitive as
gcpro(). And as stable. Bad karma.
> - we'll need a kind of sprintf
probably true ... but you could always pull out the raw data and use doprnt().
Yikes. What about mule?
> - dynamically allocated strings tend to add a whole lot of
overhead in
> all mutating operations to check whether they need to be extended.
this doesn't make sense to me. one if statement?
Once upon a time, I started writing a web interface to Jim Breen's
edict (japanese-english dictionary). In the first tests, I was
generating the page by concatenating characters to a dynamic string
(which was doing exponential reallocation, starting at 4K and doubling
the size each time).
On the biggest result (100 entries), building the page was taking 20s.
I changed the code to do the test once per entry, allocating at least
4K in advance (which was enough for any entry) and using pointers to
directly write the data.
New time: 0.05s.
true ... but better to be correct than fast. most of the time, this
will not
be used for huge chunks of data, and it really won't matter. if you really care
about efficiency, there are other (but less convenient) ways, e.g. use
TO_EXTERNAL_FORMAT directly.
Efficiency should not be harder.
OG.