[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About memory allocation failures....
From:       "Schmidt, John" <John_Schmidt () compuware ! com>
Date:       2002-03-22 18:28:04
[Download RAW message or body]

On Wednesday 30 January 2002 15:04, Laurent, Guillaume wrote:
> On Wednesday 30 January 2002 15:51, Schmidt, John wrote:
> > I think you need to reread Alex's comments, the performance penalty he
> > mentions
> > is when you do try {...} catch {...} block, not simply doing an if check
> > for NULL
> > on a malloc().

> Yes, but this is C++ so, as it was said several times already :

> - we don't use malloc(), but 'new'
> - 'new' never returns null, it throws.

NEVER?  I guess you must be observing this from the compiler you have
experience with, for the Visual Age C++ compiler on AIX seems to return 
NULL by default.  Even when I wrap it in a try{} catch{} it doesn't throw.  
Maybe an exception specification MUST be used to get it to throw.  The 
same occurs on MS VisualC++, at least it's doc'd to return NULL by default.
You can always add a "nothrow" or use the std::set_new_handler to change
whatever the default is.  BTW, the book you list on your website (by 
Bjarne Stroustrup?) has an example of using nothrow, and in it there's a
comment saying a new without nothrow "may" throw an exception... Hmmmm.  

> > If you do NOT check for NULL and subsequently try to write
> > to the
> > storage addressed from your NULL pointer, this is what you get:

> I'm pretty confident everybody here knows what happens when you
dereference a 
> null ptr, thank you.

> Now I suggest we end this thread here, as all that was worth saying has
been 
> said.

If you only want to know about one compiler and omit some of the facts,
yes...
 
regards,
John Schmidt
ServerVantage Development
Compuware Corporation
http://www.compuware.com/products/vantage
john.schmidt@compuware.com




The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]