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

List:       kde-devel
Subject:    Re: About memory allocation failures....
From:       Guillaume Laurent <glaurent () telegraph-road ! org>
Date:       2002-03-22 18:40:30
[Download RAW message or body]

Why you felt the need to pursue this inane conversation after all this time 
is beyond me.

Anyway, see "The C++ Programming Language", 3rd. Ed., #6.2.6.2.

On Friday 22 March 2002 19:20, you wrote:
> 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...
>
>
> John Schmidt
> ServerVantage Development
> Compuware Corporation
> (248) 737-7300 x16779
> 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.

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