 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Nick Maclaren
Guest
|
 Posted: Wed Jan 25, 2006 8:02 pm Post subject: throw/catch and sequence points |
 |
|
Well, I sent this to a couple of relevent reflectors, and got a
stunned silence - not a new experience for me - so let's see if
this newsgroup does better :-)
Please do NOT answer it unless you have a more than casual knowledge
of the sequence point morass, as I can assure you that it is an evil
question. The same applies to the implementation aspects. But note
that I am not a C++ programmer!
Well, either I have seriously omitted to find the reference, or there
is a serious omission in the C++ standard :-)
1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function, and the attached footnote makes it clear that this was
intended to apply to throw and catch.
Er, but isn't the point about throwing an exception within a function
and catching it by a handler outside that function (perhaps in a quite
different file) that the return value is NOT copied?
Now, for reasons that I can attempt to explain in ghastly detail (but
will almost certainly not make clear), this is a real problem and is
much more serious for threaded codes than for serial ones. I have
been caught by it, badly, on some systems.
The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B. One interpretation of sequence points is that the handler
is then called in a nonce sub-tree rooted at the point the exception
is raised. That is, actually, how a large proportion of hardware
works.
This means that there is no sequence-point ordering between the
update of A and the execution of the handler, and the programmer has
no power to introduce any. So what happens when the handler completes?
Well, in practice, nothing special. This is BAD news. As far as the
standard goes, that is pretty hard to justify, but I can assure you
that it is what implementations will do.
What almost all systems do, after the problem has bit badly enough
that they realise it must be fixed, is to put a barrier somewhere
around the throw/catch (it doesn't matter where). Unless I have
missed something critical, C++ needs to do the same.
Note that this ISN'T just relevant to hardware-raised exceptions,
but applies even to the most explicit throw/catch clauses on systems
with sufficiently loose memory ordering.
So I am right or confused?
Regards,
Nick Maclaren.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Hyman Rosen
Guest
|
| Posted: Wed Jan 25, 2006 10:52 pm Post subject: Re: throw/catch and sequence points |
|
|
Nick Maclaren wrote:
| Quote: | 1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function
|
That's 1.9/17, not 1.7/17.
| Quote: | Er, but isn't the point about throwing an exception within a function
and catching it by a handler outside that function (perhaps in a quite
different file) that the return value is NOT copied?
|
So? 1.9/17 tells you that there are two sequence points.
There's one after copying the returned value, and there's
one before execution of any expressions outside the
function. Since the exception handler is most assuredly
outside the function, a sequence point has been encountered
before the handler receives control.
| Quote: | much more serious for threaded codes than for serial ones
|
The C++ standard does not address multi-threaded programming,
so you need to check with your implementation if you need some
special effect.
| Quote: | The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B. One interpretation of sequence points is that the handler
is then called in a nonce sub-tree rooted at the point the exception
is raised. That is, actually, how a large proportion of hardware
works.
|
What has hardware to do with C++? At the very least, stack
unwinding needs to be done up to the exception handler. The
only "interpretation" of sequence point is 1.9/7, which says
that at sequence points, previous side effects are complete
and future side effects haven't happened yet. They are not
related to exceptions, or to concurrent programming. (And
they should be done away with completely, but that's another
thread.)
| Quote: | So I am right or confused?
|
Confused.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Wed Jan 25, 2006 10:52 pm Post subject: Re: throw/catch and sequence points |
|
|
On Wed, 25 Jan 2006 20:02:46 GMT, [email]nmm1 (AT) cus (DOT) cam.ac.uk[/email] (Nick Maclaren)
wrote:
[snip]
| Quote: | note that I am not a C++ programmer!
|
OK...
| Quote: | Well, either I have seriously omitted to find the reference, or there
is a serious omission in the C++ standard :-)
1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function, and the attached footnote makes it clear that this was
intended to apply to throw and catch.
Er, but isn't the point about throwing an exception within a function
and catching it by a handler outside that function (perhaps in a quite
different file) that the return value is NOT copied?
|
As you say, there is a sequence point after the copying of a return
value. However, that doesn't mean that there are no sequence points
before that. 1.7 paragraph 11 tells you what a sequence point is ...
is that what you think it is?
| Quote: | Now, for reasons that I can attempt to explain in ghastly detail (but
will almost certainly not make clear), this is a real problem and is
much more serious for threaded codes than for serial ones. I have
been caught by it, badly, on some systems.
|
If you are not a C++ programmer, please explain how have you been
"caught by it" and how this relates to the C++ language?
| Quote: | The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B. One interpretation of sequence points is that the handler
is then called in a nonce sub-tree rooted at the point the exception
is raised. That is, actually, how a large proportion of hardware
works.
|
What is a "nonce sub-tree"?
| Quote: | This means that there is no sequence-point ordering between the
update of A and the execution of the handler, and the programmer has
no power to introduce any. So what happens when the handler completes?
Well, in practice, nothing special. This is BAD news. As far as the
standard goes, that is pretty hard to justify, but I can assure you
that it is what implementations will do.
|
Whether or not an "update of A" is successful in the event of an
exception depends on the cv-qualification of A in the case of a
built-in primitive type (please refer to the keyword "volatile" in
this context), or if A is of non-POD type, whether it has been made
exception-safe, including whether or not proper synchronization has
occurred in a multi-threaded environment. But C++ has no built-in
language features concerning threading. Synchronization always depends
to a large extent on platform-specific mechanisms.
| Quote: | What almost all systems do, after the problem has bit badly enough
that they realise it must be fixed, is to put a barrier somewhere
around the throw/catch (it doesn't matter where). Unless I have
missed something critical, C++ needs to do the same.
|
Can you please give us a concrete example? What kind of barrier are
you referring to?
| Quote: | Note that this ISN'T just relevant to hardware-raised exceptions,
but applies even to the most explicit throw/catch clauses on systems
with sufficiently loose memory ordering.
|
Since you are not a C++ programmer, you probably aren't aware that C++
exceptions and hardware exceptions are not the same thing. There are
C++ implementations (compilers) out there which will somehow map
hardware exceptions to C++ exceptions using OS-specific mechanisms.
For example, some C++ compilers will use SEH on Windows to trap
hardware exceptions and throw a C++ exception which can then be caught
by C++ code. Otherwise, there is no C++ built-in mechanism to catch
hardware exceptions. (How could there be if C++ is a true
cross-platform language?) Another thing is threads: C++ has no
language features (yet) which deal with multi-threading issues in a
cross-platform manner.
| Quote: | So I am right or confused?
|
You are probably confused as to what a sequence point is ... lots of
C++ programmers are, and since you aren't a C++ programmer, it
wouldn't be surprising.
--
Bob Hairgrove
[email]NoSpamPlease (AT) Home (DOT) com[/email]
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Jan 26, 2006 1:54 am Post subject: Re: throw/catch and sequence points |
|
|
In article <a7nft115m54bime7trdj1u6v3u7abb615m (AT) 4ax (DOT) com>, Bob Hairgrove
<invalid (AT) bigfoot (DOT) com> writes
| Quote: | So I am right or confused?
You are probably confused as to what a sequence point is ... lots of
C++ programmers are, and since you aren't a C++ programmer, it
wouldn't be surprising.
|
I very much doubt that Nick is in any way confused as to what a sequence
point is. He is an outstanding C programmer on heavy duty hardware. I
suspect his main concern is what is about to happen as multi-core CPUs
become the norm on the desk-top. Are we going to have to learn the hard
lessons (learnt on main-frames) all over again.
Please try to take his concerns seriously even if understanding them
proves difficult (but the area he is considering is fraught with
surprises and unexpected difficulties that many programmers are unable
to grasp)
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Thu Jan 26, 2006 5:36 am Post subject: Re: throw/catch and sequence points |
|
|
Nick Maclaren wrote:
| Quote: | 1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function, and the attached footnote makes it clear that this was
intended to apply to throw and catch.
|
It's 1.9/17. Footnote 11 is not intended to "apply to throw and catch",
but the committee thinks it's a necessary clarification because there
are "more ways in which a called function can terminate its execution,
such as the throw of an exception." There's a big difference.
| Quote: | Er, but isn't the point about throwing an exception within a function
and catching it by a handler outside that function (perhaps in a quite
different file) that the return value is NOT copied?
|
An exception may be thrown by the destructor of a local object after the
return value has been copied. In C++, as opposed to C, copying the
return value is not the last thing performed before leaving the function
(thus, probably, the need for footnote 11).
| Quote: | The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B. One interpretation of sequence points is that the handler
is then called in a nonce sub-tree rooted at the point the exception
is raised. That is, actually, how a large proportion of hardware
works.
|
Your simplest example could be made even more simple if you could
provide us with a piece of code. Without code it's very difficult (for
me, at least) to visualize the problem and follow you. In particular, I
cannot figure out how an expression could update an object and throw
without a separating sequence-point. I'm sure you have an example ready,
could you post it, please?
| Quote: | So I am right or confused?
|
I can't tell about you, but I *am* confused.
Ganesh
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Thu Jan 26, 2006 3:55 pm Post subject: Re: throw/catch and sequence points |
|
|
Francis Glassborow wrote:
| Quote: | In article <a7nft115m54bime7trdj1u6v3u7abb615m (AT) 4ax (DOT) com>, Bob Hairgrove
[email]invalid (AT) bigfoot (DOT) com[/email]> writes
So I am right or confused?
Please try to take his concerns seriously even if understanding them
proves difficult (but the area he is considering is fraught with
surprises and unexpected difficulties that many programmers are unable
to grasp)
|
There are two basic problems worth thinking about here,
and it's not clear which one the original poster is trying
to discuss.
First, there's the problem of converting a machine exception
into a C++ exception. C++, unlike Ada, does not generally
support that at all, although some implementations do try to
make it work. But that's a language extension.
Second, there's the issue of what happens when the compiler
has introduced paralleism into a sequential program as an
optimization, and one of the threads throws an exception.
The original poster seems to be trying to figure out just
how conservative the C++ standard requires the compiler to be
in such situations. SGI has (had?) compilers which did such
optimizations, and so this problem is more than theoretical.
Consider, for example:
inline float f(float x)
{ ... } // expensive function with no side effects
// but which could raise an exception
float tab1[100000];
float tab2[100000];
...
for (int i=0; i<100000; i++)
{ tab2[i] = f(tab1[i]); }
A multithreading compiler might try to optimize this by putting
a few threads to work on the problem. That works out fine,
unless some call to f raises an exception. Should that occur,
"tab1" would be partially updated, but the updated elements
might not necessarily be sequential.
John Nagle
Animats
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Sean Kelly
Guest
|
| Posted: Thu Jan 26, 2006 5:12 pm Post subject: Re: throw/catch and sequence points |
|
|
Bob Hairgrove wrote:
| Quote: | On Wed, 25 Jan 2006 20:02:46 GMT, [email]nmm1 (AT) cus (DOT) cam.ac.uk[/email] (Nick Maclaren)
wrote:
This means that there is no sequence-point ordering between the
update of A and the execution of the handler, and the programmer has
no power to introduce any. So what happens when the handler completes?
Well, in practice, nothing special. This is BAD news. As far as the
standard goes, that is pretty hard to justify, but I can assure you
that it is what implementations will do.
|
Why is this a problem? I would assume that in a multithreaded
environment, the exception would be handled by the same thread that
threw it, so memory synchronization should not be an issue in this
case. Is this incorrect?
| Quote: | What almost all systems do, after the problem has bit badly enough
that they realise it must be fixed, is to put a barrier somewhere
around the throw/catch (it doesn't matter where). Unless I have
missed something critical, C++ needs to do the same.
Can you please give us a concrete example? What kind of barrier are
you referring to?
|
I think he's referring to a memory barrier, which are used to order
memory accesses on SMP systems.
| Quote: | So I am right or confused?
You are probably confused as to what a sequence point is ... lots of
C++ programmers are, and since you aren't a C++ programmer, it
wouldn't be surprising.
|
This seems like a gray area at the moment. Since the current spec
assumes a single-threaded model, I don't believe there is any language
describing what a sequence point means in memory synchronization terms.
I'm not sure I entirely understand the issue Nick is describing, but I
do believe it is indicative of questions that may arise as C++ 0x
memory model talk continues.
Sean
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted: Thu Jan 26, 2006 5:12 pm Post subject: Re: throw/catch and sequence points |
|
|
In article <1BRBf.62798$eD5.1046673 (AT) twister2 (DOT) libero.it>,
Alberto Ganesh Barbati <AlbertoBarbati (AT) libero (DOT) it> writes:
| Quote: | Nick Maclaren wrote:
1.7 paragraph 17 says that there is a sequence point after the copying
of a return value and before the execution of any expressions outside
the function, and the attached footnote makes it clear that this was
intended to apply to throw and catch.
It's 1.9/17. Footnote 11 is not intended to "apply to throw and catch",
but the committee thinks it's a necessary clarification because there
are "more ways in which a called function can terminate its execution,
such as the throw of an exception." There's a big difference.
|
Oops. Yes. Thanks for the correction and explanation - that is
very useful.
| Quote: | An exception may be thrown by the destructor of a local object after the
return value has been copied. In C++, as opposed to C, copying the
return value is not the last thing performed before leaving the function
(thus, probably, the need for footnote 11).
|
Ugh. That is even more important to me!
| Quote: | Your simplest example could be made even more simple if you could
provide us with a piece of code. Without code it's very difficult (for
me, at least) to visualize the problem and follow you. In particular, I
cannot figure out how an expression could update an object and throw
without a separating sequence-point. I'm sure you have an example ready,
could you post it, please?
|
(a = 0) + (b + c);
Where b+c overflows. There are more complex examples that can occur
even in the cleanest of code.
Regards,
Nick Maclaren.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Thu Jan 26, 2006 5:13 pm Post subject: Re: throw/catch and sequence points |
|
|
On Thu, 26 Jan 2006 01:54:25 GMT, [email]francis (AT) robinton (DOT) demon.co.uk[/email]
(Francis Glassborow) wrote:
| Quote: | I very much doubt that Nick is in any way confused as to what a sequence
point is. He is an outstanding C programmer on heavy duty hardware. I
suspect his main concern is what is about to happen as multi-core CPUs
become the norm on the desk-top. Are we going to have to learn the hard
lessons (learnt on main-frames) all over again.
Please try to take his concerns seriously even if understanding them
proves difficult (but the area he is considering is fraught with
surprises and unexpected difficulties that many programmers are unable
to grasp)
|
I do take them seriously, and if anything in my message indicated
otherwise, it certainly wasn't intentional, and I apologize if I made
that impression. I also missed the wrong section number of the
standard (1.9 instead of 1.7), as others have pointed out.
Still, it is hard to understand exactly what his concerns are without
some specific example, even if it is written in C and not C++. We know
that C++ currently lacks complete standardization in the area of
multi-threaded programming. However, not knowing that C++ exceptions
and hardware exceptions are not the same didn't go very far to ease my
doubts that he might also have some misconceptions about what a
sequence point is.
As you say, it is a difficult thing for most programmers to understand
completely (including myself, of course). It would be great if we
could learn something here from a "non-C++ programmer". :)
--
Bob Hairgrove
[email]NoSpamPlease (AT) Home (DOT) com[/email]
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Martin Bonner
Guest
|
| Posted: Thu Jan 26, 2006 6:13 pm Post subject: Re: throw/catch and sequence points |
|
|
Nick Maclaren wrote:
| Quote: | Please do NOT answer it unless you have a more than casual knowledge
of the sequence point morass,
|
Sorry, I'm going to ignore that request.
| Quote: | The simplest example is a function that evaluates an expression that
updates an object A while (not sequence-point separated) throwing an
exception B.
|
Somebody asked for example of such a piece of code. Does the following
qualify?
int global;
void g(int,int);
void f(int i)
{
g( global++, (i > 0?i:throw "negative i") );
}
| Quote: | So I am right or confused?
or both? |
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Thu Jan 26, 2006 6:23 pm Post subject: Re: throw/catch and sequence points |
|
|
On Thu, 26 Jan 2006 17:12:31 GMT, [email]nmm1 (AT) cus (DOT) cam.ac.uk[/email] (Nick Maclaren)
wrote:
| Quote: | |> Your simplest example could be made even more simple if you could
|> provide us with a piece of code. Without code it's very difficult (for
|> me, at least) to visualize the problem and follow you. In particular, I
|> cannot figure out how an expression could update an object and throw
|> without a separating sequence-point. I'm sure you have an example ready,
|> could you post it, please?
(a = 0) + (b + c);
Where b+c overflows. There are more complex examples that can occur
even in the cleanest of code.
|
Section 5, paragraph 5 says that the above is undefined behavior if
(b+c) overflows. The standard says nothing about hardware interrupts
or exceptions here. The assumption is that there would be a sequence
point at the semicolon.
Furthermore, the order of execution is unspecified: i.e., (a=0) can
be performed either before or after (b+c) on a conforming
implementation, and if (b+c) doesn't overflow, the result is
well-defined either way. And if it does overflow, the result is
undefined, also either way.
Note that if b and c are unsigned integers, there is no overflow, but
the value wraps (check out section 3.9.1, paragraph 4, footnote 41),
thus the expression's value is also well-defined. However, the same
caveats WRT hardware exceptions or signals apply.
--
Bob Hairgrove
[email]NoSpamPlease (AT) Home (DOT) com[/email]
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Hyman Rosen
Guest
|
| Posted: Thu Jan 26, 2006 7:06 pm Post subject: Re: throw/catch and sequence points |
|
|
Nick Maclaren wrote:
| Quote: | (a = 0) + (b + c);
Where b+c overflows.
|
C++ exceptions are unrelated to overflow or other
such problems. If b+c overflows, then the code has
officially encountered undefined behavior, and the
standard says nothing at all about what this program
must do.
Some implementations do choose to convert such events
into C++ exceptions (and that's fine, since vendors
may choose to define undefined behavior for themselves),
and then you need to consult with them as to what they
have done for this case.
I would expect, given the lack of a sequence point here,
that you can make no assumptions about the state of 'a'
once the converted hardware exception is thrown.
I have argued elsewhere that the entire concept of
sequence points is misguided, and should be abandoned in
favor of a strict left-to-right order of evaluation with
side-effects happening as they are encountered. If this
were to be adopted, then you could be assured that a was
set when b + c threw. I'm glad you've added another point
in favor of my argument :-)
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted: Thu Jan 26, 2006 7:22 pm Post subject: Re: throw/catch and sequence points |
|
|
In article <1138267396.096337.220330 (AT) g47g2000cwa (DOT) googlegroups.com>,
Sean Kelly <sean (AT) f4 (DOT) ca> wrote:
| Quote: |
Why is this a problem? I would assume that in a multithreaded
environment, the exception would be handled by the same thread that
threw it, so memory synchronization should not be an issue in this
case. Is this incorrect?
|
Yes, on several grounds. Let's stick to the same thread, as it seems
that asynchronous exceptions are not something that C++ programmers
will swallow.
C/C++ sequence points apply only to one thread (obviously) and are
about memory synchronization. In particular, a compiler is allowed
to move memory operations around arbitrarily between them (subject
to doing the right operations), and is allowed to permit them to
be delayed by the hardware.
If there is no sequence point between the 'failing' function and the
handler, then the handler must not access anything accessed by the
failing function. Well, actually, if the handler is rooted at the
location of the catch, it must not access anything accessed in the
controlled clause. BAD news.
And it can get worse ....
| Quote: | What almost all systems do, after the problem has bit badly enough
that they realise it must be fixed, is to put a barrier somewhere
around the throw/catch (it doesn't matter where). Unless I have
missed something critical, C++ needs to do the same.
Can you please give us a concrete example? What kind of barrier are
you referring to?
I think he's referring to a memory barrier, which are used to order
memory accesses on SMP systems.
|
Not necessarily. The problems arise just as badly on serial systems
with loose memory ordering models, like the Alpha. If you look at
the code of pretty well any FLIH (first level interrupt handler),
you will see such things. Or, for the really ancient, the Model 91
pipeline drain instructions in IBM's Mod II Fortran library :-)
| Quote: | This seems like a gray area at the moment. Since the current spec
assumes a single-threaded model, I don't believe there is any language
describing what a sequence point means in memory synchronization terms.
|
It doesn't even make sense on a SERIAL system :-(
| Quote: | I'm not sure I entirely understand the issue Nick is describing, but I
do believe it is indicative of questions that may arise as C++ 0x
memory model talk continues.
|
Spot on. And that is what I am involved with.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [email]nmm1 (AT) cam (DOT) ac.uk[/email]
Tel.: +44 1223 334761 Fax: +44 1223 334679
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Thu Jan 26, 2006 7:23 pm Post subject: Re: throw/catch and sequence points |
|
|
On Thu, 26 Jan 2006 12:13:15 CST, "Martin Bonner"
<martinfrompi (AT) yahoo (DOT) co.uk> wrote:
| Quote: | Somebody asked for example of such a piece of code. Does the following
qualify?
int global;
void g(int,int);
void f(int i)
{
g( global++, (i > 0?i:throw "negative i") );
}
|
Did you perhaps mean ++global ... ???
--
Bob Hairgrove
[email]NoSpamPlease (AT) Home (DOT) com[/email]
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted: Thu Jan 26, 2006 7:47 pm Post subject: Re: throw/catch and sequence points |
|
|
In article <it5it1pe79fcqe7sj8vphf63tmgq293nuu (AT) 4ax (DOT) com>,
Bob Hairgrove <invalid (AT) bigfoot (DOT) com> wrote:
| Quote: | On Thu, 26 Jan 2006 12:13:15 CST, "Martin Bonner"
[email]martinfrompi (AT) yahoo (DOT) co.uk[/email]> wrote:
Somebody asked for example of such a piece of code. Does the following
qualify?
int global;
void g(int,int);
void f(int i)
{
g( global++, (i > 0?i:throw "negative i") );
}
Did you perhaps mean ++global ... ???
|
It makes no difference. Either update global, and there is no ordering
specified between that update and the conditional expression that
contains the throw.
Now, see my previous lecture about the different sequence point models
for the possible viewpoints on whether the sequence point at the '?'
is relevant or not :-)
To the other posters: please don't confuse the issue. I gave an example,
and kept it simple in order to keep it clear. Yes, I know all that,
but please see 1.9 paragraph 15 for where the standard says that this
may raise an exception. If you prefer, use the following:
(a = 0) + (throw "balls");
Yes, sequence points are fundamentally broken, but the simple solution
of lexicographic ordering conflicts with many forms of optimisation.
Simple left-to-right won't work, because of:
a = fred(a = 1);
Regards,
Nick Maclaren.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
