Re: Non-failure guarantied malloc/new
From: Jeff Schwab (jeffplus_at_comcast.net)
Date: 12/26/03
- Next message: Jeff Schwab: "Re: Class Member Variables:instance Vs pointer"
- Previous message: Derek: "Re: How is my code?"
- In reply to: John Eskie: "Re: Non-failure guarantied malloc/new"
- Next in thread: Nicholas Hounsome: "Re: Non-failure guarantied malloc/new"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 26 Dec 2003 11:28:31 -0500
>>>> When I used to learn the language I was told always to check "if (p
>>>> != > NULL)" and return a error otherwise.
>> Were you using C?
> In past yes. But I've also used this construct for C++ applications.
>>>> I still do that always but sometimes it's annoying the hell out of
>>>> me if I want to allocate memory inside a constructor and have no
>>>> way to return an error code to the caller to inform that something
>>>> went wrong.
>> Throw an exception.
> As written in another post I am unsure how to write a proper handler
> for it. After all I can recieve such a exception at any time so I
> will have no possibilities to do proper cleanup of resources.
If clean-up of resources is performed by destructors, it will be
performed automatically as the stack is unwound.
>>>> In my opinion it's still better to run a while() loop and stall the
>>>> program then having it crash instead, no?
>> I suppose so, but I don't really like either of those options. If
>> availability of the process is not cricital, I usually print an error
>> message, then try to exit as gracefully as possible. Of course, if
>> it's essential that the program not die, the resources needed must be
>> specified very carefully, and the program can try to reserve them all
>> on startup.
> Yes but if you got some open file handles or similar then you can't
> really clean up the whole thing gracefully.
The destructors should do it for you.
> I would say there is alot effort to do that.
It depends on the program. I agree that writing a truly fail-safe
programs can be a lot of effort. :) By the time I've found a crash-proof
OS, bought the server and peripherals (UPS etc.), checked which library
functions I can use for I/O in case of emergency and which system calls
are guaranteed not to fail, and rented space in a flood-proof,
fire-proof machine room, I'll be darned sure the spec's of the system
are well-defined. In such a case, it's probably worth the extra effort
to do your allocations at the front of the program.
> This is probably also the reason why I dislike exceptions. Because you
> end up somewhere in the program and have no way of going back.
How did you get there in the first place? Throw information about the
call stack as part of the exception. I have done this by dividing a
program into "layers," and putting an exception handler around each
crossing of a boundary between layers. Each handler then may add
information about the call-stack to the exception. I should mention
that it is rare for me to deal with exceptions so catastrophic, and that
most of my programs do fail with a nasty error message when needed
memory is not available.
> If you just get a NULL pointer you can check for you will be able to
> return to the caller and inform there is something wrong and the
> caller can do it's own cleanup.
You can do the same thing with an exception, but the exception will
allow you to return whatever sort of object is necessary to help the
caller deal with the failure. You don't have to encode everything in
"errno" or some other global variable. Also, by catching different
types of exceptions at different places along the call stack, the
calling code can deal with different types of errors in different
places. With the old "encode errors in the return value" trick common
in C, a low-level function might be responsible for handling some very
high-level errors, usually by passing the error back up the call stack.
Now, the intermediate code has been removed, and errors go straight to
the places you want to handle them. As a bonus over setjmp or "goto
error" approaches, the call-stack is still unwound properly.
>>>> I am looking for suggestions or possible implementations of memory
>>>> allocation which is guarrantied not to fail.
>> You could allocate all needed memory in static blocks. Of course,
>> then every run of your program will use as much memory as the worst
>> case. Your while-loop idea may be the next closest thing to a
>> "fail-proof" allocator.
> While it's certainly possible it's very impractical. Sometimes you
> don't know how much memory you will need. A simple example is when
> you read in a file of size which you find out when the program runs.
You don't have to know how much you need to allocate it up front: you
have to know what the *worst case* is, and be prepared for it. If you
don't end up using all the memory you allocated, so be it. Just to be
clear, this is not an approach I use often, and it is one that may make
your program grossly inefficient in the general case. It's still better
than hanging for an "infinitely long" time, though.
> -- John
-Jeff
- Next message: Jeff Schwab: "Re: Class Member Variables:instance Vs pointer"
- Previous message: Derek: "Re: How is my code?"
- In reply to: John Eskie: "Re: Non-failure guarantied malloc/new"
- Next in thread: Nicholas Hounsome: "Re: Non-failure guarantied malloc/new"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
