I've posted this code in comp.lang.c++.moderated, and
upon reflection, decided to post it to comp.std.c++ too.

In the following code, can it be shown by reference to
the standard that there is a sequence point between the
'a[++i]' used to call 'f' and the '++i' in f?

      int i = 0;
      void f() { ++i; }
      void (*a[])() = { f, f, f, f, f };
      int main() { a[++i](); }

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hyman Rosen wrote:

> I've posted this code in comp.lang.c++.moderated, and
> upon reflection, decided to post it to comp.std.c++ too.
>
> In the following code, can it be shown by reference to
> the standard that there is a sequence point between the
> 'a[++i]' used to call 'f' and the '++i' in f?
>
>       int i = 0;
>       void f() { ++i; }
>       void (*a[])() = { f, f, f, f, f };
>       int main() { a[++i](); }
>

The problem i think is that the function entry sequence point seems to be
not immediately before the function execution starts, but only "somewhere
between after argument evaluation and before function execution really
starts". If the sequence point happens immediately after evaluation of the
arguments, it seems to me the calling function can still put evaluations of
the calling functions before executing the called function but *after* the
function-entry sequence point (like you show in your other question's copy):

"When calling a function (whether or not the function is inline), there
is a
sequence point after the evaluation of all function arguments (if any)
which
takes place before execution of any expressions or statements in the
function body."

Now, however, there is a second sequence point "after the copying of a
returned value and before the execution of any expressions outside the
function"

In practice, the consequence of this second sequence point seems to be that
"++i" cannot be "broken up" so that one half is executed before the
function
execution, and the other half after. The function-exit sequence point
forbids that (and the sequence point after the "++i" full-expression inside
"f" already too), because it says any evaluation that started shall have
been completed. So in effect both "++i" evaluations are properly
sequenced -
but not because of sequence points, but because of additional wording that
forbids both evaluations to interleave in 1.9/8: "Once the execution of a
function begins, no expressions from the calling function are evaluated
until execution of the called function has completed." . So because a
sequence point is missing, behavior still seems to be UB.

This sounds really weird though - i think if there is a sequence point at
function-entry, it should be *immediately* before the function starts,
anyway. In C++0x, situation is clearer, and your code has no UB there (and
notice sequence points are gone in '0x xD):

1.9/16: "When calling a function (whether or not the function is inline),
every value computation and side effect associated with any argument
expression, or with the postfix expression designating the called function,
is sequenced before execution of every expression or statement in the body
of the called function. Every evaluation in the calling function (including
other function calls) that is not otherwise specifically sequenced
before or
after the execution of the body of the called function is indeterminately
sequenced with respect to the execution of the called function."

So you can even do "++i + f()" and f can increment i by whatever - it will
work. But as "++i" is not part of the postfix expression, f doesn't know
what value "i" has.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hyman Rosen <hyrosen@mail.com> writes:

> In the following code, can it be shown by reference to
> the standard that there is a sequence point between the
> 'a[++i]' used to call 'f' and the '++i' in f?
>
>      int i = 0;
>      void f() { ++i; }
>      void (*a[])() = { f, f, f, f, f };
>      int main() { a[++i](); }

Yes. There is a sequence point on the entry to every function. See
1.9p17 of the 2003 standard.

Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pavel wrote:
> Hyman Rosen wrote:
>> I've posted this code in comp.lang.c++.moderated, and
>> upon reflection, decided to post it to comp.std.c++ too.
>>
>> In the following code, can it be shown by reference to
>> the standard that there is a sequence point between the
>> 'a[++i]' used to call 'f' and the '++i' in f?
>>
>>      int i = 0;
>>      void f() { ++i; }
>>      void (*a[])() = { f, f, f, f, f };
>>      int main() { a[++i](); }
>>
> 1.9-17:
> "When calling a function (whether or not the function is inline), there
> is a sequence point after the evaluation of all function arguments (if
> any) which takes place before execution of any expressions or statements
> in the function body. There is also a sequence point after the copying
> of a returned value and before the execution of any expressions outside
> the function"
>
> Hope this will help
> -Pavel

It doesn't. This is a particularly nasty piece of code (and would be in
any language that allowed pointers or references to functions)

The problem is that the rule about the sequence point after the
evaluation of the function arguments does not specifify that which
function to call has to be evaluated before evaluating the arguments, or
at least before the sequence point after the evaluation of the arguments.

unless someone can come up with a second rule it seems that this order
is legitimate:

evaluate the arguments (trivial in this case)
sequence point
evaluate a[++i] to determine which function pointer
call the function through the pointer
execute the function

now we have two writes to i without an intervening sequence point.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pavel wrote:
> Hyman Rosen wrote:
>> In the following code, can it be shown by reference to
>> the standard that there is a sequence point between the
>> 'a[++i]' used to call 'f' and the '++i' in f?
>>
>>      int i = 0;
>>      void f() { ++i; }
>>      void (*a[])() = { f, f, f, f, f };
>>      int main() { a[++i](); }
>>
> 1.9-17:
> "When calling a function (whether or not the function is inline), there
> is a sequence point after the evaluation of all function arguments (if
> any) which takes place before execution of any expressions or statements
> in the function body. There is also a sequence point after the copying
> of a returned value and before the execution of any expressions outside
> the function"
>
> Hope this will help

Sorry, it doesn't help at all. A legal order according to the
section you quoted is:
      1) Evaluate the (zero number of) arguments.
      2) Sequence point.
      3) Evaluate the function subexpression 'a[++i]'.
      4) Call the function.
      5) Evaluate '++i' in the function.
There is no sequence point between (3) and (5), hence the two
increments cause undefined behavior.

I'm looking for standardese which tells me that there is a
sequence point after the evaluation of the call expression
before the execution of the function begins.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 20, 2:54 am, Hyman Rosen <hyro...@mail.com> wrote:
> I've posted this code in comp.lang.c++.moderated, and
> upon reflection, decided to post it to comp.std.c++ too.
>
> In the following code, can it be shown by reference to
> the standard that there is a sequence point between the
> 'a[++i]' used to call 'f' and the '++i' in f?
>
>       int i = 0;
>       void f() { ++i; }
>       void (*a[])() = { f, f, f, f, f };
>       int main() { a[++i](); }

1.9p8: "Once the execution of a function begins, no expressions from
the calling function are evaluated until execution of the called
function has completed."
1.9p17: "When calling a function (whether or not the function is
inline), there is a sequence point after the evaluation of all
function arguments (if any) which takes place before execution of any
expressions or statements in the function body. There is also a
sequence point after the copying of a returned value and before the
execution of any expressions outside the function."

This means that there is always a sequence point between anything in a
function and outside of it. There's a clarifying footnote in p8 that
makes the intent perfectly clear: functions do not interleave.

However, I cannot find anything to specify whether the outer ++i does
its modification before or after the function runs. So I think the
value of i might be unspecified (0 or 1) inside f. This means the
program, should it decide to print i in f, has unspecified behavior,
but not undefined. Reading 5.2.2 very carefully, I cannot find any
indication that the left side of the function call expression is
considered an argument expression, so it is not subject to the same
guarantee as the arguments.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> This is a particularly nasty piece of code

My point, of course, is that it's not the code that's nasty
but the language. It's yet another piece of evidence that C++
should completely define order of evaluation of expressions.

Another poster has pointed out that the current working draft
has language in 1.9/16 saying that evaluation of the postfix
expression designating the function is sequenced before the
statements of the function, so someone else noticed the problem
and stuck on another band-aid. (There does not seem to be a fix
for the multiple auto_ptr parameter problem, though.)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 20 Oct, 01:54, Hyman Rosen <hyro...@mail.com> wrote:
> I've posted this code in comp.lang.c++.moderated, and
> upon reflection, decided to post it to comp.std.c++ too.
>
> In the following code, can it be shown by reference to
> the standard that there is a sequence point between the
> 'a[++i]' used to call 'f' and the '++i' in f?
>
>       int i = 0;
>       void f() { ++i; }
>       void (*a[])() = { f, f, f, f, f };
>       int main() { a[++i](); }

Yes, it's legal.

1.9/17 says there is a sequence point after the evaluation of all
functions arguments which is before the function body is executated,
and one after the copying of the return value but before the
evaluation of any expression outside the function

So the ++i in main must have finished all its side effects before the +
+i in f.

Ric




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Jim Barry wrote:
>
> James Kuyper wrote in message <374352C1.D0D0465C@wizard.net>...
>>
>> There is both a section 15.2, and a section 15, paragraph 2. You
>> should use a notation that distinguishes between sections and
>> paragraphs, to avoid confusion.
>
> What notation do you suggest? 15/2?

Common accepted practice that I've seen on news:comp.std.c and
news:comp.std.c++ is "15.2p3" or "15.2#3".  Even "15.2[3]" or
"15.2(3)" works.  In other words, use "." to separate
chapter/section/subsection numbers and something else for
paragraph numbers.

-- David R. Tribble, dtribble@technologist.com --
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Barry wrote:
>
> James Kuyper wrote in message <374352C1.D0D0465C@wizard.net>...
> >
> >There is both a section 15.2, and a section 15, paragraph 2. You
> should
> >use a notation that distinguishes between sections and paragraphs, to
> >avoid confusion.
>
> What notation do you suggest? 15/2?

Just about anything that isn't 15.2 would work; I use "15, p2".
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 22 May 99 18:47:07 GMT, James Kuyper <kuyper@wizard.net> wrote:

>Just about anything that isn't 15.2 would work; I use "15, p2".

This looks like chapter 15, page 2.  How about "15:2" or
"section 15, paragraph 2"?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 22 May 99 18:47:07 GMT, James Kuyper <kuyper@wizard.net> wrote:
>
> >Just about anything that isn't 15.2 would work; I use "15, p2".
>
> This looks like chapter 15, page 2.  How about "15:2" or
> "section 15, paragraph 2"?

I was keeping my explanation short - I always prefix my section
references with the word 'section', so the confusion you suggest is
unlikely. On the other hand, using the notation 14.7.2 to refer to
paragraph 2 is very likely to be confusing - I've been confused by it
myself several times.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7i4ihb$ea6$1@nnrp1.deja.com>,
  Jim Hyslop <jim.hyslop@leitch.com> wrote:

> > > 15.2: A goto, break, return, or continue statement can be used to
> > transfer
> > > control out of a
> > > try block or handler, but not into one.
> >

> Out of curiosity, what other interpretation(s) you see?

Maybe it's my English.
The sentence seems to collect try blocks and handlers together. If you
think of it this way, you can rephrase it like this:

You can goto out of a try-block or handler.
You cannot goto from the outside into a try-block or handler.

This leaves open the possibility to goto from within a try-block into a
handler.

Andrei


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>> I was keeping my explanation short - I always prefix my section
references with the word 'section', so the confusion you suggest is
unlikely. On the other hand, using the notation 14.7.2 to refer to
paragraph 2 is very likely to be confusing - I've been confused by it
myself several times.

What about the notation "S.6.5.1(2)" to signify "When the condition of a
while
statement is a declaration, the scope of the variable ..."? This clearly
disambiguates section numbering from paragraph numbering and has the
major benefit of being concise.

The text to which I originally referred is therefore S.15(2).

Arnold the Aardvark
===========================
http://www.foxholly.demon.co.uk
ICQ# 30592054
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote in article
<7i97r7$crl$1@nnrp1.deja.com>...
>>>The sentence seems to collect try blocks and handlers together. If you
think of it this way, you can rephrase it like this:

>>>You can goto out of a try-block or handler.
You cannot goto from the outside into a try-block or handler.

>>>This leaves open the possibility to goto from within a try-block into a
handler.

This interpretation is highly contrived for a native English speaker.
Change "the outside" to "anywhere". The English merely says that
try blocks and handlers are identical in this context - you cannot
transfer control into them using the specified methods.

If the standard said "try block and handler" you would have a case.

Arnold the Aardvark
===========================
http://www.foxholly.demon.co.uk
ICQ# 30592054
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote in message
news:7i97r7$crl$1@nnrp1.deja.com...
> In article <7i4ihb$ea6$1@nnrp1.deja.com>,
>   Jim Hyslop <jim.hyslop@leitch.com> wrote:
>
> > > > 15.2: A goto, break, return, or continue statement can be used to
> > > transfer
> > > > control out of a
> > > > try block or handler, but not into one.
> > >
>
> > Out of curiosity, what other interpretation(s) you see?
>
> Maybe it's my English.
> The sentence seems to collect try blocks and handlers together. If you
> think of it this way, you can rephrase it like this:
>
> You can goto out of a try-block or handler.
> You cannot goto from the outside into a try-block or handler.
>
> This leaves open the possibility to goto from within a try-block into a
> handler.

It seems pretty clear to me that the intention was not to allow transfer
from the try-block into the handler.  However, I can see where the phrase
"but not into one" might confuse you.  Perhaps it would be clearer if it
were stated:

"A goto, break, return, or continue statement can be used to transfer
control out of a try block or handler, but not into either one."
or even more verbosely
"A goto, break, return, or continue statement can be used to transfer
control out of a try block or handler, but not into either a try block or
handler"
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Leichter wrote:

> I agree that the answer is no.  As to why he asks ... this is one way to
> try (unsuccessfully) to get the effects of the "try/finally" construct
> present in many other implementations of exceptions.  For those who
> haven't seen it,
>
>         try
>         {       A;
>         }
>         finally
>         {       B;
>         }
>
> has the semantics:  Execute A; then execute B, *whatever A's outcome*,
> then continue as if B weren't there.  In particular, if A throws an
> exception, B is executed before the exception is propagated out of the
> try/finally block.  A common use of such a thing is to take out a lock
> in A and release it in B.
>

How about something like this:

#include <iostream>
using namespace std ;
int main (int argc, cahr *argv[])
{
  cout << "start" << endl ;
  try {
    class finally {
    public:
      ~finally () {
        cout << "finally" << endl ;
      }
    } _finally ;

    cout << "try" << endl ;
    if (argc > 1) {
      cout << "throw" << endl ;
      throw 1 ;
    }
  } catch (...) {
    cout << "catch" << endl ;
  }
  cout << "end" << endl ;
}

Talking about locks, this concept could be used by defining a monitor:

class lock {
...
public:
  void lock () ;
  void unlock () ;
...
} ;

class monitor {
public:
  monitor (lock & l) : _lock (l) { _lock.lock () ; }
  ~monitor () { _lock.unlock () ;}
private:
  lock & _lock ;
} ;

and then:

lock l;

try {
  monitor _m (l) ;
  ...
} catch (..) {
}

The lock will be released if an exception is thrown or not.

Jochen


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7i1kr0$bav$1@nnrp1.deja.com>,
  Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
> > 15.2: A goto, break, return, or continue statement can be used to
> transfer
> > control out of a
> > try block or handler, but not into one.
>
> I've seen that, but that "or" seems ambiguous to me.
I don't see any ambiguity at all - I can see only one possible
interpretation of that statement:

You may use a goto(etc.) to leave a try block.
You may use a goto to leave a handler.

You may not use a goto to enter a try block.
You may not use a goto to enter a handler.

Out of curiosity, what other interpretation(s) you see?

--
Jim
I ignore all email from recruitment agencies.
Please do not send me email with questions - post
here.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

int main()
{
    try
    {
        goto label;
    }
    catch (...)
    {
        label: ;
    }
}

Thanks,

Andrei


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

No.

15.2: A goto, break, return, or continue statement can be used to transfer
control out of a
try block or handler, but not into one.

Arnold the Aardvark
===========================
http://www.foxholly.demon.co.uk
ICQ# 30592054



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 19 May 1999 19:16:13 GMT, Andrei Alexandrescu <andrewalex@hotmail.com> wrote:

>int main()
>{
>    try
>    {
>        goto label;
>    }
>    catch (...)
>    {
>        label: ;
>    }
>}

My gut feeling is no.  But why do you ask?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Arnold the Aardvark wrote:
>
> No.
>
> 15.2: A goto, break, return, or continue statement can be used to transfer
> control out of a
> try block or handler, but not into one.

There is both a section 15.2, and a section 15, paragraph 2. You should
use a notation that distinguishes between sections and paragraphs, to
avoid confusion.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <374352C1.D0D0465C@wizard.net>...
>
>There is both a section 15.2, and a section 15, paragraph 2. You
should
>use a notation that distinguishes between sections and paragraphs, to
>avoid confusion.

What notation do you suggest? 15/2?

--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk - Queen's Award for Export 1998
http://www.geocities.com/SiliconValley/2060
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

| >int main()
| >{
| >    try
| >    {
| >        goto label;
| >    }
| >    catch (...)
| >    {
| >        label: ;
| >    }
| >}
|
| My gut feeling is no.  But why do you ask?

I agree that the answer is no.  As to why he asks ... this is one way to
try (unsuccessfully) to get the effects of the "try/finally" construct
present in many other implementations of exceptions.  For those who
haven't seen it,

 try
 { A;
 }
 finally
 { B;
 }

has the semantics:  Execute A; then execute B, *whatever A's outcome*,
then continue as if B weren't there.  In particular, if A throws an
exception, B is executed before the exception is propagated out of the
try/finally block.  A common use of such a thing is to take out a lock
in A and release it in B.

In C++, you can get similar effects by using the "construction is
resource acquisition/destruction is resource release" idiom.  This
solves the lock/unlock problem cleanly, but there are other uses that
aren't quite so clean - you may have to define a rather artificial class
to do this, and there can be problems with access if the "finally" block
needs to get at local variables from the surrounding block.  So ... the
obvious thing to try is:

 bool thrown = true;
 try
 { A;
  thrown = false;
  goto final;
 }
 catch (...)
 {
 final:
  B;
  if (thrown)
   throw;
 }

But this is illegal.  The alternative, which you'll sometimes see, is:

 try
 { A;
 }
 catch (...)
 { B;
  throw;
 }
 B;

Two copies of the B code - unfortunate.  (And *don't* suggest moving B
off into a function - if the whole point of B is to manipulate a bunch
of local variables, it's going to have a really ugly interface.  Once
again, nested functions would be nice....)

Note that even if the goto worked, it wouldn't really have the "right"
semantics.  In a proper implementation of try/finally, *any* method of
leaving the try block executes the finally block - including a return, a
continue or break for a surrounding loop or switch, etc.  This could
obviously be implemented by further hacking, but it's not a route you'd
normally want to go.  (In fact, Modula-3, which has try/finally, uses
the clever technique of defining return and break as special, built-in
exceptions - so the semantics of return in a try block just falls out of
the general try/finally semantics.)
       -- Jerry


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> 15.2: A goto, break, return, or continue statement can be used to
transfer
> control out of a
> try block or handler, but not into one.

I've seen that, but that "or" seems ambiguous to me. Just like you, I
lean towards the interpretation that you cannot use goto from try block
to handler.

Andrei


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]