When operator new() fails, it throws a bad_alloc.
This generally results in the destructors for all local
objects up to that point being called and the stack
being unwound. Supporting all this activity
undoubtedly requires more complicated (and thus
slower) machine code each time the compiler
detects the presence of the word "new" in your
program.

My question is, when it was decided that new must
throw an exception rather than simply returning 0,
as it did formerly, was it ever considered that in some
applications, speed is everything and the chance of new
failing is infinitesimally small?

For such applications, is it recommended that we
eschew operator new() and use malloc() instead? This
would be unfortunate since there is apparently no way
to manually call a constructor.

Thank you.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a84b5ec$1_2@news.nwlink.com> Sore Loserman writes:
>When operator new() fails, it throws a bad_alloc.
>This generally results in the destructors for all local
>objects up to that point being called and the stack
>being unwound. Supporting all this activity
>undoubtedly requires more complicated (and thus
>slower) machine code each time the compiler
>detects the presence of the word "new" in your
>program.
>
>My question is, when it was decided that new must
>throw an exception rather than simply returning 0,
>as it did formerly, was it ever considered that in some
>applications, speed is everything and the chance of new
>failing is infinitesimally small?

Yes.  An operator new() declared with an empty throw-specifictaion,
i.e., throw(), returns a null pointer on failure instead of
throwing an exception.  See 5.3.4 paragraph 15.

Steve Adamczyk
Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Sore Loserman wrote:
>
> When operator new() fails, it throws a bad_alloc.
> This generally results in the destructors for all local
> objects up to that point being called and the stack
> being unwound. Supporting all this activity
> undoubtedly requires more complicated (and thus
> slower) machine code each time the compiler
> detects the presence of the word "new" in your
> program.
>
> My question is, when it was decided that new must
> throw an exception rather than simply returning 0,
> as it did formerly, was it ever considered that in some
> applications, speed is everything and the chance of new
> failing is infinitesimally small?
>
> For such applications, is it recommended that we
> eschew operator new() and use malloc() instead? ...

No, use new(nothrow). std::nothrow_t is an empty type that serves no
other purpose but to allow overload resolution to cause a different
version of operator new() to be used. std::nothrow is a single const
object of that type. "new(nothrow) T()" calls operator new(size_t,
const  std::nothrow_t&), which is almost identical to the normal
operator new(), except that it will return a null pointer if it fails,
rather than throwing an exception.

> ... This
> would be unfortunate since there is apparently no way
> to manually call a constructor.

To manually call only the constructor, without doing any memory
allocation, just use placement new; it also does not throw (unless the
constructor itself throws).

if( (void *p = malloc(sizeof(T))) != NULL )
{
 T* pT = new(p) T(arg1, arg2);

 // Use pT

 free(p);
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a84b5ec$1_2@news.nwlink.com>, Sore Loserman <nobody@nowhere
.moderated.news.pipex.net> writes
>When operator new() fails, it throws a bad_alloc.
>This generally results in the destructors for all local
>objects up to that point being called and the stack
>being unwound. Supporting all this activity
>undoubtedly requires more complicated (and thus
>slower) machine code each time the compiler
>detects the presence of the word "new" in your
>program.

False deduction. It will require more machine code, but the speed cost
need not be paid until an exception is thrown. Indeed there are
mechanisms on some systems whereby the footprint in RAM isn't even
enlarged until an exception is thrown. One result of this is that a well
written exception safe program may actually be faster and have a smaller
execution footprint (until an exception occurs) than an equivalent
program that handles runtime problems by some other mechanism.

>
>My question is, when it was decided that new must
>throw an exception rather than simply returning 0,
>as it did formerly, was it ever considered that in some
>applications, speed is everything and the chance of new
>failing is infinitesimally small?

Well not exactly in those terms, but go and check out new(nothrow) and
you will discover that the Standards Committees were wiser than you are
giving them credit for.

>
>For such applications, is it recommended that we
>eschew operator new() and use malloc() instead? This
>would be unfortunate since there is apparently no way
>to manually call a constructor.

Again wrong, twice over. Using malloc is not a good idea because
new(nothrow) will do the job. And secondly, while you cannot call a ctor
directly on dynamic memory you can do so by using the version of
placement new designed for that job.

I think you need to do some further study of both operator new and the
new expression because clearly there are things that you have missed.


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Sore Loserman" <nobody@nowhere.moderated.news.pipex.net>:
> My question is, when it was decided that new must
> throw an exception rather than simply returning 0,
> as it did formerly, was it ever considered that in some
> applications, speed is everything and the chance of new
> failing is infinitesimally small?
>
> For such applications, is it recommended that we
> eschew operator new() and use malloc() instead? This
> would be unfortunate since there is apparently no way
> to manually call a constructor.
No. Using placement new with the nothrow object will result in new returning
0 in case of allocation failure. So this:

#include <new>
#include <iostream>

int main() {
    int *p = new (std::nothrow) int;
    if (!p) {
        std::cout << "Error in memory allocation." << std::endl;
        std::abort();
    }
    delete p;
}

would work fine.

sm



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]