>  URL please.

Here:
http://aspn.activestate.com/ASPN/Mail/Message/boost/1811713

>  What interaction?

See URL above and/or Robbins book chapter 13


> > I don't think so. Well, it can fail. 
> It only fails under restricted circumstances, which are documented.

That is the *interaction* I am talking about: it can fail. 

>  which are documented.

Where is this documentation? In boost.test ? in the source?

I would like to learn where it can and cannot work. My current
understanding is that it works when the compiler does not optimize too
much :)

>  I think you are seriously missing my point.  This is not a substitute
>  for my technique because it causes unwinding and recovery instead of
>  going immediately to JIT debugging.

a) I guess I am. You mentioned earlier that you don't know what
execution_monitor is doing, now is a good time to check it out because
we are not talking about your technique in the vacuum. 

b) My proposal can do the same thing(s) as your technique for
execution_monitor. Mine causes unwinding and yours not? You lost me
there. Please explain. 

c) causes recovery? I never said recovery... where do you get that from
my pseudo code?

>  Interesting things are counter-productive at this point.  

Okeey.. How should I read that?

>  "Invoke the
>  debugger" is the right thing to do for developers, and "report
>  failure and terminate" is the right thing to do for testers.

No problem there. Remember that we have other classes derived from
execution_monitor where behavior is specialized for production or
testing.

> > Think about it.
>  No thanks! ;-)

I know, thinking sometimes is difficult. I hope I can get the attention
of the maintainer of boost.test and that he/she feels like thinking.


CPU


-----Original Message-----
From: boost-bounces@[...].org
[mailto:boost-bounces@[...].org] On Behalf Of David Abrahams
Sent: Sunday, September 21, 2003 1:16 PM
To: boost@[...].org
Subject: [boost] Re: boost::execution_monitor impl under windows

"carlos pizano" <carlospizano@[...].com>  writes:

>  Dave Abrahams wrote:
> > No, I'm disabling the warning with pragmas.  The technique works
fine.
> 
>  I don't think so. Well, it can fail. 

It only fails under restricted circumstances, which are documented.

>  See Carl Daniel post on 9/21. 

URL please.

>  I saw the thread(s) on comp.lang.c++.moderated about the subject but
>  nobody mentioned the interaction of the *technique* with /EHs at
>  that time.

What interaction?

>  Here is where I am going with this. The current way, complied with
/EHs
>  seems to me that can be better done with something along the lines of:
> 
>  execute() 
>  {
> 
>  __try
>  {
>  	try
>  	{
>  		user_function();
>  	}
>  	catch( specific_type1& )
>  	{
>  		report1(text);
>  	}
>  	catch( specific_type2& )
>  	{
>  		report2(text);
>  	}
>  	... other type specific catch(s) here..
>  	
>  	... do not put catch(...) here ever..
>  }
>  __except ( filter(GetExceptionInformation()) )
>  {
>  	report_def()
>  }
> 
>  } // end of function
> 
>  /* take the above code at the pseudo-code level */

I think you are seriously missing my point.  This is not a substitute
for my technique because it causes unwinding and recovery instead of
going immediately to JIT debugging.

>  Now, inside filter() you can do interesting things for instance
>  re-throwing the SE under certain conditions or checking for the magic
>  number that says that the SE is really a C++ exception and maybe do
your
>  trick...

Interesting things are counter-productive at this point.  "Invoke the
debugger" is the right thing to do for developers, and "report
failure and terminate" is the right thing to do for testers.

>  Note that the code above will be done in two nested calls since VC
>  does not Allow you to mix __try and try on the same function.
> 
>  There seems to be very little restrictions on what filter() can be,
>  I wonder if we can make it dispatch to a virtual function so a
>  derived class can customize the behaviors.
> 
>  Think about it.

No thanks! ;-)

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost