Anyway, entering and leaving a try { } block may have overheads in many
environments, but they can vary massively.  Again, a basic programming
skill is to benchmark things in your own environment, and/or look at
the assembly output from your compiler (e.g. g++ -S).  On Solaris a
couple years ago, I found reporting errors via exceptions was about 15
times slower than using integral return codes (like libc), but things
may well have changed.  I don't recall the overhead for successful
processing.  Anyway, whether this is significant depends on many
factors.  It just confirmed my impression that the programmer I had
just interviewed was being a bit silly when he insisted that he hadn't
reported an error using anything other than an exception for several
years.

As for what influences the memory: use of exceptions may require the
compiler to reserve an additional stack, but the standard C++ library
uses exceptions itself, so you should have that overhead anyway.  Re
program size, it's just not relevant unless you're in an embedded
environment, in which case I'd say again that you have to write code
and make measurements with your particular compiler and processor.

The general rule is use exceptions to report exceptional circumstances,
not oft-encountered error conditions.  Varying from this rule isn't
worth doing unless you have profiling results showing you that you have
to.

A design example: a function written "bool is_odd(int)" probably
shouldn't throw, but "void assert_odd(int)" could, because the caller
is clearly saying it would be exception not to succeed.  See
Stroustrup's TC++PL3 for some background discussions on use of
exceptions.

Cheers, Tony

My question is about destructor. When it be called? Yes I made some
tests with cout. I guess that the destructor is called at more external
try. And the compiler is smart if you use um rethrown. But this
behavior must be written is some place? or not?

struct  X{
 X(AnyInterface *p) {
   if (p == 0)
    throw runtime_error("AnyInterface is obrigatory for class X!");
   else
     p->f();
 }

TC++PL3 is very good! :)
I read also:
CUJ august 2004, "When, for what, and how should you use exceptions"
Sutter
Exceptional C++ Style and C++ Coding Standard.

Thank's
http://paginas.terra.com.br/informatica/thiago_adams/eng/index.htm

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

void f(pointer *p){
  assert(p != 0);
  p->f();

The TC++PL has an example:

template <classX , classA > inline void Assert(A assertion) {
  if (!assertion ) throw X();

When use throw and when use asserts?
Two cases:
void func(vector &v, int *p) {
  if (p == 0)
    throw bad_arg(); // why not? because this functions alread throws
  v.push_back(p); // push can throw right?

 // yes I can use reference but is only an example :)
 *p = v.size() + 10;

Thanks!
(and sorry my english is not so good)

Do they know the cost in correctness and maintainability of using
return codes?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

First, the reason why one would like to 'throw' in this case, which is
usually not to recover in the sense of continuing normal execution, but
to recover enough to do useful logging, reporting and graceful exit on
an end-user system with no debugger and other programmer's tools
(including, no programmer's level understanding of what goes on).

Why that is a problem in C++: the standard exception hierarchy is not
designed.  Uh, I meant, it's not designed with different degrees of
recoverability in mind.  At best you can use std::runtime_error for
"soft" (in principle recover-and-continue-normally'able) exceptions, and
classes derived otherwise from std::exception for "hard" exceptions, but
in practice people tend to not restrict themselves to
std::runtime_error, and the Boost library is an example of this common
practice  --  the standard's own exception classes are also examples.

So, if you want a really "hard" exception in C++, one that is likely to
propagate all the way up to the topmost control level, you'll have to
use something else than a standard exception.

And even that non-standard exception might be caught (and not rethrown)
by a catch(...) somewhere.  Which is not as unlikely as it might seem.
E.g., as I recall, ScopeGuard does that in its destructor¹.

Well, then, why not use std::terminate instead?  After all, that's what
it's for, isn't it?  And it's configurable.

But no, that's not what it's for.  Calling std::terminate does not
guarantee RAII cleanup as a "hard" exception would.  In short, I know of
no good portable solution to this problem in standard C++, and thinking
of how extremely easily it could have been supported in the design of
the standard exception classes (there was even existing practice from
earlier languages indicating how it should be) it's very frustrating.

¹) One might argue that calling std::terminate is the only reasonable
    failure handling in a destructor, even for ScopeGuard-like objects.
    But the standard already provides that draconian measure for the
    situation where it's really needed, where you would otherwise have a
    double exception (which does not exist in C++).  Doing it explicitly
    just removes a measure of control from the client code programmer.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

In some situations (ATM machine in the middle of a transaction, say) it
might make sense to attempt recovery even when an assertion fails, if
things can't possibly get any worse. This is extremely fragile, of
course. You can't test how well the recovery works because by
definition it is only executed in situations that your tests did not
cover (if they did, you'd have fixed the code to no longer assert).

If "recovery" in the above means something generally more reasonable,
like, cleaning up, then again that flies in the face of established
fact.  E.g., generally open files are closed by the OS whenever a
process terminates, whatever the cause of the termination, and it's no
big deal to define that as part of the application.  In this sense of
"recovery" the above therefore says it's impossible to write an OS in
C++, and that's patently false, too.

So what does the above mean, if anything?

Is it, perhaps, a "proof", from principles, that hummingbirds can't fly?

Then I'd suggest the proof technique and/or the principles are to blame.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

So I assumed that by "recovery" you mean "stack unwinding" (with its usual
side effects), because this is what 'throw' does.