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                             ]