Re: any_function (callback) library

From: williamkempf_at_[hidden]
Date: 2001-04-13 08:40:11

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> > > > > What does this program do with msvc?
> > > > >
> > > > > include <cassert>
> > > > > #include <iostream>
> > > > >
> > > > > int main() {
> > > > >     try {
> > > > >         assert(0);
> > > > >     }
> > > > >     catch(...) {
> > > > >         std::cout << "hi there" << std::endl;
> > > > >     }
> > > > >     return 0;
> > > > > }
> > > > >
> > > > > Try compiling it as follows:
> > > > >     cl /MLd /GX /EHa foo.cpp
> > > >
> > > > It halts the program.  Even if you Ignore the assertion the 
catch
> > > > block is never entered.  Like I said, none of the assertion
> > libraries
> > > > that come with MSVC throw exceptions.
> > >
> > > That's incorrect. You obviously didn't try it.
> >
> > Whoa.  Slow down there.  This comes very close to flame material,
> 
> Well, no offense intended...
> 
> > especially considering I *DID* check it (VC 6, SP 4), and I'm 
correct
> > that the catch block is never entered.  Sorry.
> 
> Did you use the compiler settings specified above? If so, I am at a 
loss to
> explain our differing results. I am also using VC6 SP 4.

Same settings.

> > > It throws a structured
> > > exception which raises JIT debugging. First you get an 
abort/retry
> > dialog.
> > > Then you choose "Retry" to enter JIT debugging. Then it 
prints "hi
> > there" to
> > > standard out as the structured exception enters the catch block.
> > Then the
> > > JIT debugger fails to come up because the exception isn't re-
thrown.
> >
> > Not on my tests it doesn't.  However, I ran this test under the
> > debugger.
> 
> OH. Then you're not going to see the same issues as one sees for JIT
> debugging. But I think if you continue from the program "halt" you 
will see
> the "hi there" message and a return code of 0.

I continued from the assertion line and the catch was never entered.
 
> > Possibly the behavior you speak of only occurs when run
> > outside of the debugger.
> 
> Yes.
> 
> > That would be an interesting case, but one
> > that I've never encountered since I only run debug builds through 
the
> > debugger.
> 
> That explains it.
> 
> > > > Again, std::vector::at() exists for precisely this reason, 
and C++
> > > > programmers use it in precisely the same manner as IndexError 
is
> > > > used.  I don't agree that we have a completely different 
culture
> > in
> > > > this case.  There are many C++ programmers that want, even 
need,
> > to
> > > > insure their programs never crash... that they can catch 
errors,
> > > > possibly handle them, and continue running.
> > >
> > > ...mmm, I don't think I agree. Would anybody really do this in 
C++?
> > >
> > > for (std::size_t i = 0;; ++i)
> > > {
> > >     T* x;
> > >     try {
> > >         x = &v.at(i);
> > >     }
> > >     catch(std::out_of_range) {
> > >         break;
> > >     }
> > >     f(*x);
> > > }
> >
> > Yes, people really do that, though this particular case is so 
simple
> > that a rewrite can easily be done to insure out of range checks 
are
> > not needed.  So I'd expect qualified C++ programmers would avoid
> > this.  Then again, I'd expect qualified language X programmers to
> > avoid it as well (and have seen them do so).
> 
> What I'm trying to say is that the mechanism is built into the 
python
> language. When you write
> 
>   for x in s:
>     print x
> 
> it uses an exception under the covers to detect the end of the 
sequence.
> Python exceptions are no less efficient than any other control 
structure.

Regardless, people *do* use exceptions in the same manner here, and 
frankly this would be the only purpose for at() throwing.

Bill Kempf