Re: Non-failure guarantied malloc/new
From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 12/24/03
- Next message: Jeff Schwab: "Re: Non-failure guarantied malloc/new"
- Previous message: Victor Bazarov: "Re: Polymorphic behavior without virtual functions"
- In reply to: John Eskie: "Non-failure guarantied malloc/new"
- Next in thread: John Eskie: "Re: Non-failure guarantied malloc/new"
- Reply: John Eskie: "Re: Non-failure guarantied malloc/new"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 24 Dec 2003 22:10:29 GMT
"John Eskie" <john.smith@intheunknown.net> wrote...
> Lately I've seen alot of C and C++ code (not my own) which doesn't do any
> checking if memory obtained by new or malloc is valid or if they return
NULL
> pointers.
> Why does most people not care about doing this kind of error checking?
Probably because memory is cheap and computers on which the programs made
from the code you've seen are supposed to have lots of it. Just a guess...
> When I used to learn the language I was told always to check "if (p !=
> NULL)" and return a error otherwise.
It's not a bad style.
> 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. It's the usual way to indicate a failure to create
an object.
> Thinking about this issue made me do some hacks like running memory
> allocation in a while() loop such as:
>
> blah *p = NULL;
> while (!p)
> {
> p = malloc(...);
> }
To do what?
> On top of the whole thing we got new operator which works differently on
> each compiler implementation. Some compilers throw exceptions while others
> give NULL pointers.
Those that give NULL pointers are non-compliant.
> Actually I prefer NULL pointers because it's so much
> easier to handle in a while loop then doing some exception handling.
Then you need to use a "nothrow" form of the new operator.
> I hope I've reached my point now because OS's do run out of memory. Why
> would I let my program crash if I can avoid it? Just for fun I recently
> wrote a program that took all my memory in the OS and then started one
> program which I knew did not have any error checking on new operator.
Guess
> what, it crashes in no-time.
Sure. What else could it do?
> In my opinion it's still better to run a while() loop and stall the
program
> then having it crash instead, no?
I am not sure what you mean by that. I get really annoyed by programs
that do not respond when I need them to, and have to kill them manually.
How is that better than crashing?
> I am looking for suggestions or possible implementations of memory
> allocation which is guarrantied not to fail.
No such thing. Since memory is a limited resource, some memory
allocations are bound to fail.
Victor
- Next message: Jeff Schwab: "Re: Non-failure guarantied malloc/new"
- Previous message: Victor Bazarov: "Re: Polymorphic behavior without virtual functions"
- In reply to: John Eskie: "Non-failure guarantied malloc/new"
- Next in thread: John Eskie: "Re: Non-failure guarantied malloc/new"
- Reply: John Eskie: "Re: Non-failure guarantied malloc/new"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|