 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daniel Krügler
Guest
|
 Posted: Tue Sep 20, 2005 3:28 am Post subject: Unrealistic requirements on types? |
 |
|
Hello,
last night I stumbled about a statement of 26.1 (Numeric type
requirements), which seems very questionable to me. Before I quote the
relevant sentence I would like to introduce with the beginning of the
corresponding section:
"The complex and valarray components are parameterized by the type of
information they contain and manipulate. A C++ program shall instantiate
these components only with a type T that satisfies the following
requirements: (footnote 253)"
with footnote 253: "In other words, value types. These include built-in
arithmetic types, pointers, the library class complex, and
instantiations of valarray for value types."
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
I don't believe that this sentence is formulated to express the intend
of the commitee. If taken literally, there exists practically no type
which fulfills these requirements, because we all know that even the
following streaming operation snippet **on an int type** can throw,
depending on the users input: (*)
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
I assume the intend was to say something like:
"If any of the operations of T described in clause 1, that is either
assignment, copy construction, default construction, or destruction,
throws an exception the effects are undefined."
Or what was the intend?
Greetings from Bremen,
Daniel Krügler
(*): The meaning of "operation on" is not precisely defined in the
Standard, at least I could not find such a definition. But the usage of
this phrase in the standard implies, that it is not necessarily
restricted to the meaning of "calling any non-static member function
of". For example chapter 25 (Algorithms library) p.1 says: "This clause
describes components [..] to perform algorithmic operations on
containers [..] and other sequences." and none of the algorithm
functions are member functions of containers or sequences.
---
[ 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 |
|
 |
msalters
Guest
|
| Posted: Tue Sep 20, 2005 2:53 pm Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: |
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
|
No, that's an operation on cin.
HTH,
Michiel Salters
---
[ 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 |
|
|
Marc Schoolderman
Guest
|
| Posted: Wed Sep 21, 2005 4:19 am Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: | Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
|
Note that this is paragraph 2, whereas the part enumerating the
requirements on what the footnote calls "value types" is paragraph 1.
So the requirement is not "There exist no operations on type T that
might throw". It's just that (as I interpret it) nothing should be
thrown by operations performed on T by complex<> or valarray<>.
~Marc.
---
[ 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 |
|
|
kuyper@wizard.net
Guest
|
| Posted: Wed Sep 21, 2005 4:20 am Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: | Hello,
last night I stumbled about a statement of 26.1 (Numeric type
requirements), which seems very questionable to me. Before I quote the
relevant sentence I would like to introduce with the beginning of the
corresponding section:
"The complex and valarray components are parameterized by the type of
information they contain and manipulate. A C++ program shall instantiate
these components only with a type T that satisfies the following
requirements: (footnote 253)"
with footnote 253: "In other words, value types. These include built-in
arithmetic types, pointers, the library class complex, and
instantiations of valarray for value types."
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
I don't believe that this sentence is formulated to express the intend
of the commitee. If taken literally, there exists practically no type
which fulfills these requirements, because we all know that even the
following streaming operation snippet **on an int type** can throw,
depending on the users input: (*)
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
|
That doesn't throw an exception because of an operation on an 'int'. It
throws because of an operation on std::cin.
| Quote: | I assume the intend was to say something like:
"If any of the operations of T described in clause 1, that is either
assignment, copy construction, default construction, or destruction,
throws an exception the effects are undefined."
Or what was the intend?
|
I'm fairly certain that they mean not only the operations you
described, but also all of the the applicable arithmetic operators,
whether or not they are implemented as member functions. I'm not so
sure about conversion operators, conversion constructors, and
conversion assignement. In practice, I think it's safe to use a
user-defined type with an operator overload that does throw, so long as
it's guaranteed to be the case that the operator overload isn't
actually used. But the ones that are used can't throw.
| Quote: | (*): The meaning of "operation on" is not precisely defined in the
Standard, at least I could not find such a definition. But the usage of
this phrase in the standard implies, that it is not necessarily
restricted to the meaning of "calling any non-static member function
of". For example chapter 25 (Algorithms library) p.1 says: "This clause
describes components [..] to perform algorithmic operations on
containers [..] and other sequences." and none of the algorithm
functions are member functions of containers or sequences.
|
No, but they call member functions of containers and sequences, and
that is the sense in which they are "operations on" the containers or
sequences. I will agree that this is slightly inconsistent usage.
However, in a document this big, with so many different authors
contributing to the mix, I wouldn't recommend deriving any great
signficance from this difference in the way the words are used.
---
[ 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 |
|
|
Daniel Krügler
Guest
|
| Posted: Wed Sep 21, 2005 6:10 am Post subject: Re: Unrealistic requirements on types? |
|
|
msalters wrote:
| Quote: | Daniel Krügler wrote:
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
No, that's an operation on cin.
|
Where is the proof of that assertion? You have read my comment in my
original thread concerning interpretations on "operation on", didn't you?
Greetings,
Daniel
---
[ 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 |
|
|
Daniel Krügler
Guest
|
| Posted: Wed Sep 21, 2005 6:56 am Post subject: Re: Unrealistic requirements on types? |
|
|
[email]kuyper (AT) wizard (DOT) net[/email] wrote:
| Quote: | Daniel Krügler wrote:
Hello,
last night I stumbled about a statement of 26.1 (Numeric type
requirements), which seems very questionable to me. Before I quote the
relevant sentence I would like to introduce with the beginning of the
corresponding section:
"The complex and valarray components are parameterized by the type of
information they contain and manipulate. A C++ program shall instantiate
these components only with a type T that satisfies the following
requirements: (footnote 253)"
with footnote 253: "In other words, value types. These include built-in
arithmetic types, pointers, the library class complex, and
instantiations of valarray for value types."
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
I don't believe that this sentence is formulated to express the intend
of the commitee. If taken literally, there exists practically no type
which fulfills these requirements, because we all know that even the
following streaming operation snippet **on an int type** can throw,
depending on the users input: (*)
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
That doesn't throw an exception because of an operation on an 'int'. It
throws because of an operation on std::cin.
|
That is not a convincing argument for me. What is your reference for
your interpretation? But see below...
| Quote: | I assume the intend was to say something like:
"If any of the operations of T described in clause 1, that is either
assignment, copy construction, default construction, or destruction,
throws an exception the effects are undefined."
Or what was the intend?
I'm fairly certain that they mean not only the operations you
described, but also all of the the applicable arithmetic operators,
whether or not they are implemented as member functions. I'm not so
sure about conversion operators, conversion constructors, and
conversion assignement. In practice, I think it's safe to use a
user-defined type with an operator overload that does throw, so long as
it's guaranteed to be the case that the operator overload isn't
actually used. But the ones that are used can't throw.
|
OK, that is your interpretation. But lets see further..
| Quote: | (*): The meaning of "operation on" is not precisely defined in the
Standard, at least I could not find such a definition. But the usage of
this phrase in the standard implies, that it is not necessarily
restricted to the meaning of "calling any non-static member function
of". For example chapter 25 (Algorithms library) p.1 says: "This clause
describes components [..] to perform algorithmic operations on
containers [..] and other sequences." and none of the algorithm
functions are member functions of containers or sequences.
No, but they call member functions of containers and sequences, and
that is the sense in which they are "operations on" the containers or
sequences. I will agree that this is slightly inconsistent usage.
However, in a document this big, with so many different authors
contributing to the mix, I wouldn't recommend deriving any great
signficance from this difference in the way the words are used.
|
I think, if I take your words and those of the Standard literally, than
I must conclude the following:
I was wrong, because I interpreted the meaning of "sequence" as meaning
the interpretation of "range" (pair of iterators, with some requirements
on them). It is funny, that the standard says "[..] algorithmic
operations on containers [..] and other sequences." because
not **a single function in chapter 25** does make an operation on a
Container nor on a Sequence according to the definition of Sequence and
Container from chapter 23. So there is no member function call on
sequences in algorithms as your answer implies.
The only operational semantic which is demanded is those "inherited"
from iterators according to the definition of iterators in ch. 24. So
there are "member" functions called from iterators (and functors), not
from containers.
But iterators **can** be pointers, which have no member functions and
algorithms perform (at least to my interpretation) "operations on" them.
So I should just adjust my heretic question to
- the same proof that an operation on a pointer could throw (e.g. used
during IO-streaming) ;-)
- to the interpretation that pointers are no valid arguments for algorithms.
I'm sure that you understand that both interpretations are ridiculous,
but to my opionion the meaning of "operation on" has lack of definition
in the Standard and my interpretation seems to be as valid as the
interpretation of others from which (in the moment I write this answer)
not a single one has any proof or reference for they opinion. At least I
tried a proof, although we both can agree that this proof is not
fool-proof  due to another looseness in wording of the Standard.
I would suggest that the standard should say that algorithms act on
ranges and not on sequences/containers (which exclude pointer, because
they don't fulfill those requirements).
Thank you for your detailed answer,
Daniel
---
[ 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 |
|
|
Pete Becker
Guest
|
| Posted: Wed Sep 21, 2005 6:38 pm Post subject: Re: Unrealistic requirements on types? |
|
|
Marc Schoolderman wrote:
| Quote: | Daniel Krügler wrote:
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
Note that this is paragraph 2, whereas the part enumerating the
requirements on what the footnote calls "value types" is paragraph 1.
So the requirement is not "There exist no operations on type T that
might throw". It's just that (as I interpret it) nothing should be
thrown by operations performed on T by complex<> or valarray<>.
|
Right. "throws" means actually throwing something at runtime. It is
ordinary English, not the sloppy shorthand of saying "throws" to mean
"could throw."
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Thu Sep 22, 2005 5:21 am Post subject: Re: Unrealistic requirements on types? |
|
|
[email]dsp (AT) bdal (DOT) de[/email] (Daniel Krügler) writes:
| Quote: | msalters wrote:
Daniel Krügler wrote:
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
No, that's an operation on cin.
Where is the proof of that assertion? You have read my comment in my
original thread concerning interpretations on "operation on", didn't you?
|
Daniel, you won't find proof for any of this. Understanding the
standard depends on knowing how to interpret its intention, and that
partly comes from some degree of cultural exposure to the process of
working on it. Everyone who has replied to you in this thread (that
I've seen, anyway) is taking a view that's more-or-less aligned with
the committee's intention during drafting of the standard.
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Andrew Koenig
Guest
|
| Posted: Thu Sep 22, 2005 5:22 am Post subject: Re: Unrealistic requirements on types? |
|
|
"Daniel Krügler" <dsp (AT) bdal (DOT) de> wrote
| Quote: | Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
I don't believe that this sentence is formulated to express the intend
of the commitee. If taken literally, there exists practically no type
which fulfills these requirements, because we all know that even the
following streaming operation snippet **on an int type** can throw,
depending on the users input: (*)
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
|
Only if you execute it :-)
In other words, I would be inclined to read this sentence as "if any
operation throws an exception" rather than "if any operation is potentially
capable of throwing an exception, even if it doesn't do so in this context."
---
[ 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 |
|
|
kuyper@wizard.net
Guest
|
| Posted: Thu Sep 22, 2005 5:30 am Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: | kuyper (AT) wizard (DOT) net wrote:
Daniel Krügler wrote:
..
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
That doesn't throw an exception because of an operation on an 'int'. It
throws because of an operation on std::cin.
That is not a convincing argument for me. What is your reference for
your interpretation? But see below...
|
'int' is a built-in type. None of the operators that are defined for
'int' itself throw. The throw() can only occuring inside <iostream>
code.
..
| Quote: | on them). It is funny, that the standard says "[..] algorithmic
operations on containers [..] and other sequences." because
not **a single function in chapter 25** does make an operation on a
Container nor on a Sequence according to the definition of Sequence and
Container from chapter 23. So there is no member function call on
sequences in algorithms as your answer implies.
|
The standard is a little confusing on the term "sequence". It has at
least two different meanings. It sometimes refers to objects which meet
the Sequence requirements from 23.1.1. However, unless specifically
indicated otherwise, the standard usually uses "sequence" in a more
general sense that is NOT intended to imply conformaance with those
requirements, and which can, among other things, refer to a consecutive
series of objects bounded by a pair of iterators.
The overwhelming majority of the functions defined in chapter 25 take
(at least) two iterator arguments that identify a range. That range can
be contained in a container or sequence, and that's the only sense in
which those algorithms operate on containers or sequences. It would be
more accurate for the text you're quoting to say that these algorithms
act on the contents of a container or a sequence, rather than saying
that they operate on the containers or sequences themselves. So I will
agree that there's poor wording here.
| Quote: | But iterators **can** be pointers, which have no member functions and
algorithms perform (at least to my interpretation) "operations on" them.
So I should just adjust my heretic question to
- the same proof that an operation on a pointer could throw (e.g. used
during IO-streaming)
|
There's not a single operation on pointers that is defined as throwing
an exception (though the undefined behavior that is permitted in
certain circumstances might take the form of throwing an exception).
There's many functions that throw that take pointer arguments, but they
don't constitute operations on the pointer itself.
| Quote: | I'm sure that you understand that both interpretations are ridiculous,
but to my opionion the meaning of "operation on" has lack of definition
|
Agreed.
| Quote: | in the Standard and my interpretation seems to be as valid as the
interpretation of others
|
I don't understand your interpretation well enough to figure out how to
tell you that it's wrong. But since your interpretation leads you do
claim obviously incorrect things, I must assume that it's incorrect.
---
[ 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 |
|
|
Daniel Krügler
Guest
|
| Posted: Fri Sep 23, 2005 2:57 am Post subject: Re: Unrealistic requirements on types? |
|
|
[email]kuyper (AT) wizard (DOT) net[/email] wrote:
| Quote: | Daniel Krügler wrote:
[email]kuyper (AT) wizard (DOT) net[/email] wrote:
Daniel Krügler wrote:
.
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
That doesn't throw an exception because of an operation on an 'int'. It
throws because of an operation on std::cin.
That is not a convincing argument for me. What is your reference for
your interpretation? But see below...
'int' is a built-in type. None of the operators that are defined for
'int' itself throw. The throw() can only occuring inside
code.
|
I understand that and I was aware of the fact, that none of the
operators of 'int' can throw. My reasoning concerned the phrase
"operation on" which is absolutely not the same as "calling an operator
of". According to my understanding this means something like "any
function or built-in operator accessing or manipulating an object (in
the sense of 1. of the corresponding type". Is that not a valid
interpretation of that expression?
| Quote: | There's not a single operation on pointers that is defined as throwing
an exception (though the undefined behavior that is permitted in
certain circumstances might take the form of throwing an exception).
There's many functions that throw that take pointer arguments, but they
don't constitute operations on the pointer itself.
|
I would correct that and say: "There is no operator on pointers.."
| Quote: | I don't understand your interpretation well enough to figure out how to
tell you that it's wrong. But since your interpretation leads you do
claim obviously incorrect things, I must assume that it's incorrect.
|
That is a very unfair statement which attempts to represent me as a
fool. I had a honest request and my original thread was not started to
play word games. You itself say 'The standard is a little confusing on
the term "sequence"' and I say: The standard is also little confusing in
26.1/p.2. There exist indeed a list of people which have the opinion
that at some point this confusion is so strong, that a defect report is
appropriate. I am not in the position to decide that, so I posted
this as a pre filtering. Regrettably I have the feeling, that most
haven't taken my phrases as I said them e.g. as if I would have said
that either int or pointer operators would throw. I never said that! The
fact that no-one wonders about the statement "If any operation on T
throws an exception the effects are undefined." could of-course mean
that my translation of the english sentence into my native language is
defect and ambigious, while the original text is not.
Greetings from Bremen,
Daniel Krügler
---
[ 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 |
|
|
Daniel Krügler
Guest
|
| Posted: Fri Sep 23, 2005 2:58 am Post subject: Re: Unrealistic requirements on types? |
|
|
David Abrahams wrote:
| Quote: | dsp (AT) bdal (DOT) de (Daniel Krügler) writes:
msalters wrote:
Daniel Krügler wrote:
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
No, that's an operation on cin.
Where is the proof of that assertion? You have read my comment in my
original thread concerning interpretations on "operation on", didn't you?
Daniel, you won't find proof for any of this. Understanding the
standard depends on knowing how to interpret its intention, and that
partly comes from some degree of cultural exposure to the process of
working on it. Everyone who has replied to you in this thread (that
I've seen, anyway) is taking a view that's more-or-less aligned with
the committee's intention during drafting of the standard.
|
David, thank you for your answer. But a single sentence like "No, that's
an operation on cin." is not a very satisfying answer. And your
reasoning that "knowing how to interpret its intention" is a very
subjective thing. To my opinion the originally discussed sentence
"If any operation on T throws an exception the effects are undefined."
is not strongly enough bound to its preceeding paragraph to make this
sentence unambigiously clear. Obviously I am the only one who sees that
in this way, so end of the story.
Daniel
---
[ 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 |
|
|
Daniel Krügler
Guest
|
| Posted: Fri Sep 23, 2005 2:58 am Post subject: Re: Unrealistic requirements on types? |
|
|
Marc Schoolderman wrote:
| Quote: | Daniel Krügler wrote:
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
Note that this is paragraph 2, whereas the part enumerating the
requirements on what the footnote calls "value types" is paragraph 1.
So the requirement is not "There exist no operations on type T that
might throw". It's just that (as I interpret it) nothing should be
thrown by operations performed on T by complex<> or valarray<>.
|
Yes, that is a valid (and probably the intended) interpretation. But
for me it seemed as if the current sentence is meant in a more general
way and it should be clarified that it is bound to operations occuring
in the context of valarray<> or complex<>.
Greetings from Bremen,
Daniel Krügler
---
[ 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 |
|
|
Richard Corden
Guest
|
| Posted: Fri Sep 23, 2005 1:34 pm Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: | Marc Schoolderman wrote:
Daniel Krügler wrote:
Now the critical sentence from paragraph 2:
"If any operation on T throws an exception the effects are undefined."
|
[...]
| Quote: |
So the requirement is not "There exist no operations on type T that
might throw". It's just that (as I interpret it) nothing should be
thrown by operations performed on T by complex<> or valarray<>.
Yes, that is a valid (and probably the intended) interpretation. But
for me it seemed as if the current sentence is meant in a more general
way and it should be clarified that it is bound to operations occuring
in the context of valarray<> or complex<>.
|
I think you've missed what Pete Becker says.
The standard is describing the behaviour if an exception is *really*
thrown, not if an exception *might* be thrown. Such an exception is
being thrown in the context of valarray<> or complex<> and so the
clarification is unnecessary.
The implementation of valarray<> and complex<> is not specified, so for
argument sake, they may actually call 'ostream::operator<< (int)'. This
in itself is not undefined behaviour. If at runtime
'ostream::operator<<(int)' does throw an exception 26.1/2 kicks in and
says that the behaviour is undefined.
Kind Regards,
Richard
--
Richard Corden
---
[ 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 |
|
|
kuyper@wizard.net
Guest
|
| Posted: Fri Sep 23, 2005 2:36 pm Post subject: Re: Unrealistic requirements on types? |
|
|
Daniel Krügler wrote:
| Quote: | kuyper (AT) wizard (DOT) net wrote:
Daniel Krügler wrote:
[email]kuyper (AT) wizard (DOT) net[/email] wrote:
Daniel Krügler wrote:
.
std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
int i = 0;
std::cin >> i;
This proves that there exists at least one operation on int that can
throw an exception.
That doesn't throw an exception because of an operation on an 'int'. It
throws because of an operation on std::cin.
That is not a convincing argument for me. What is your reference for
your interpretation? But see below...
'int' is a built-in type. None of the operators that are defined for
'int' itself throw. The throw() can only occuring inside <iostream
code.
I understand that and I was aware of the fact, that none of the
operators of 'int' can throw. My reasoning concerned the phrase
"operation on" which is absolutely not the same as "calling an operator
of". According to my understanding this means something like "any
function or built-in operator accessing or manipulating an object (in
the sense of 1. of the corresponding type". Is that not a valid
interpretation of that expression?
|
I don't think so. Keep in mind the context - it's saying that the
complex<> and valarray<> have undefined behavior if any operation on
type T throws. What you're supposed to understand here is that it's
talking specifically about operations carried out by the functions that
make complex and valarray work as defined by the standard. By that, I
mean not only the member functions of complex<> and valarray<>
themselves, but also those of any other associated classes or
functions, called directly or indirectly, that are defined by the
implementation, including friend functions and non-member operator
overloads.
There's limits to the operations that can be performed on an object of
type T by those functions. They're permitted to assume that the
constructors, destructors and assignment operations exist for T as
described in 26.1p1. The definition of the particular complex<> and
valarray<> operations and member functions require additional
operations on T to exist, such as +, -, *, /, etc.
An implementation of any the complex<> or valarray<> functions can only
use the operations that are required to exist for that function, and
it's only those operations that render the behavior undefined if they
throw. It's the actual throwing that matters: if you instantiate
valarray() with a type for which one of those operations can throw, the
behavior is undefined ONLY if it that operation actually throws during
a particular application of that operation by one of the functions
associated with complex<> or valarray<>, not just because it can throw.
| Quote: | There's not a single operation on pointers that is defined as throwing
an exception (though the undefined behavior that is permitted in
certain circumstances might take the form of throwing an exception).
There's many functions that throw that take pointer arguments, but they
don't constitute operations on the pointer itself.
I would correct that and say: "There is no operator on pointers.."
|
I'll stand by my original wording.
| Quote: | I don't understand your interpretation well enough to figure out how to
tell you that it's wrong. But since your interpretation leads you do
claim obviously incorrect things, I must assume that it's incorrect.
That is a very unfair statement which attempts to represent me as a
fool. ...
|
Even the wisest people misinterpret the standard from time to time;
I've done it myself more often than I'd like to admit. That reveals
that you're a fool, only if you routinely misinterpret it. I hadn't
intended to label you as such a fool.
| Quote: | that either int or pointer operators would throw. I never said that! The
fact that no-one wonders about the statement "If any operation on T
throws an exception the effects are undefined." could of-course mean
that my translation of the english sentence into my native language is
defect and ambigious, while the original text is not.
|
I think that might be the case. As a native speaker of english, I find
the meaning clear, and the meaning is one that makes sense in context.
That's partly because I'm applying a context-sensitive interpretation
to the words.
---
[ 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
