Re: What risk of undefined behavior if destructor must throw?
Gennaro Prota wrote:
On 13 Oct 2006 09:03:46 -0400, "kanze" <kanze@gabi-soft.fr> wrote:
Gennaro Prota wrote:
I see. My question was more about the technical aspect though;
I find the standard assert macro too prone to ODR violations
and linking issues.
Such as? About the only one I can think of is if you compile
some modules with NDEBUG defined, and others without,
Yes :-)
and even
then, it would only affect inline functions and non-exported
templates
And isn't that 99% of the existing template code? (Well, you know,
"99" is almost always an exaggeration.)
Actually, it's probably an understatement here. Who uses
exported templates today, given the lack of compiler support?
, and in practice, will work anyway.
This surprises me (and of course, even if it appears to
work... UB could imply that it fails at some unpredictable
moment).
Knowing how compilers work, and how templates and inline
functions are handled, it doesn't surprise me.
And of course, in the twenty-five years I've been doing
C/C++, I've never compiled a module with NDEBUG defined, so
the problem doesn't exist anyway.
I know that you take complete control over the build process.
And I agree that it is the correct thing to do.
It's the only thing that works.
But many environments automatically define NDEBUG when you use
their "release mode".
All environments have a number of defaults which you get if you
don't read the documentation, and don't know what you are doing.
I've yet to find an environment where the defaults were of any
use in developing production code. Regardless of the compiler,
I end up with twenty or more different options.
And the best I've seen in production is exporting a makefile
from there (as opposed to the more common alternative:
invoking the environment -e.g. msdev.exe(!)- from the command
line and pass the project name as an argument --yes,
programmers could happily checkout/checkin the project file).
Of course those are just bad practices and bad production
environments but still I find the "definition depends on a
macro" approach a little too dangerous for C and C++.
It's far from ideal. But we're not going to remove macros from
the language, so we have to live with it.
In principle the danger exists and Murphy can make his
appearance at any time, so I was wondering if anyone had found
a somewhat more robust approach.
The current solution is robust enough for me, at least for
small, in house projects. And I generally set pretty high
standards.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]