Re: xmalloc string functions
- From: "Malcolm McLean" <regniztar@xxxxxxxxxxxxxx>
- Date: Sun, 27 Jan 2008 21:07:38 -0000
"Kelsey Bjarnason" <kbjarnason@xxxxxxxxx> wrote in message
Yes, that's right, it's a trap door function: you can enter, but you canExactly. Which is what these string functions will do. They will never return null for out of memory conditions.
never leave, unless and until the memory is available. No error
reporting, no recovery, no options at all. That is the intent of the
code, as Malcolm has expressed more than once, that you *cannot*
recover from any allocation failure. You get the memory, or you exit.
Period.
The quote character is passed, together with the character to escape the quotes (which can be the quote itself). It doesn't support different opening and closing quotes, which maybe it ought.
And does it do single quotes? Double quotes? Both?
No, no, it makes error handling *easier*, because you don't ever need toYou've got it. If machine won't give us a hundred bytes, and the end user cannot free up any more applications, what can we do, seriously? The ambitious might attempt an emergency save in the callback function/
*do* error handling. xmalloc does that for you - by ensuring you get the
memory, or the app aborts. See how wonderful it is? No need for all
that error handling code at the calling point. Also no way to ever do
anything like, oh, reduce the allocation request and try again, or
reschedule the operation for later, etc, etc, etc, but hey, it's not like
any application would ever actually do things like that.
Single user apps. Or database apps where there isn't a robust memory recovery strategy in place - e.g. anything which uses an X server. Not for an app where it doesn;t matter if you crash or not on the null pointer dereference that will follow a failed, unchecked malloc(), not for an app which absolutely must not terminate but can abort jobs if memory gets low. Between that low end and high end there's an enormous number of programs.
Except it's of little use in toy apps. Such an app probably doesn't do a
hell of a lot of complex allocations in the first place, so wouldn't
benefit significantly from "easy malloc". A complex app where there may
be thousands or millions of allocations done from hundreds or thousands
of places in the code, now this would benefit from "easy malloc" - if it
were actually useful.
The xmalloc notion presented is of little interest in a toy app, and is
unusable in a real app. One wonders where, exactly, it would actually be
used. One place it won't be used: my code. I actually like to be able
to choose a course of action on allocation failure, not be stuck with
some asinine notion that allocation will succeed or there's no point in
continuing.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
.
- Follow-Ups:
- Re: xmalloc string functions
- From: Kelsey Bjarnason
- Re: xmalloc string functions
- References:
- xmalloc string functions
- From: Malcolm McLean
- Re: xmalloc string functions
- From: Eric Sosman
- Re: xmalloc string functions
- From: Kelsey Bjarnason
- xmalloc string functions
- Prev by Date: Re: xmalloc string functions
- Next by Date: Re: Yet another User Input Question
- Previous by thread: Re: xmalloc string functions
- Next by thread: Re: xmalloc string functions
- Index(es):
Relevant Pages
|