Topic: planning for operator new and exceptions.
Author: Darron.Shaffer@beasys.com (Darron Shaffer)
Date: 1996/11/17 Raw View
I have a few questions about the proposed changes to ::operator new(size_t).
As I see it the reason the for the "new" vs. "new(nothrow)" approach as
opposed to the old set_newhandler(0) involve linking code that expects
different semantics into the same executable.
However, my question really involves how a company should prepare for
compilers that follow the proposed standard. My current project
requires porting to a variety of platforms, and, as such we do NOT use
exceptions in any form.
As I see it our alternatives are:
1) Continue to use the base operator new and assume that each compiler will
have a compatable mode available even after standardization.
Pro: No code changes required.
Con: If the compiler vendor's solution is a "global" one (such as the
set_newhandler(0) hack) then we will be unable to link with
any third-party libraries that either expect new to throw
exceptions or need to install their own newhandler.
All new code written continues to use the old style,
increasing the size of the eventual problem if this approach
fails.
2) Write all new code with the new(nohandle) syntax and use something
like a preprocessor hack to make this work with current compilers.
Start converting existing code.
Pro: The code will be ready for new compilers.
Con: ALL existing code must be converted.
All third-party libraries must still be checked for
consistecy within one executable.
What if the standard changes before it is finalized? Are we reacting
too soon?
By the way, what does the standard say about invocations of new within
library routines? Are the iostream classes going to start throwing
bad_alloc exceptions? Is there a way to turn this off?
What are other companies doing?
Thank you,
Darron Shaffer
BEA Systems, Inc.
Darron.Shaffer@beasys.com
--
Darron Shaffer
lmmorgan@dallas.net (wife's account)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]