kuyper@wizard.net wrote:
> Daniel Kr=FCgler wrote:
>=20
>>kuyper@wizard.net wrote:
>>
>>>Daniel Kr=FCgler wrote:
>=20
> .
>=20
>>>>std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
>>>>
>>>>int i =3D 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'. I=
t
>>>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...
>=20
>=20
> '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=20
operators of 'int' can throw. My reasoning concerned the phrase=20
"operation on" which is absolutely not the same as "calling an operator=20
of". According to my understanding this means something like "any=20
function or built-in operator accessing or manipulating an object (in=20
the sense of 1.8) of the corresponding type". Is that not a valid=20
interpretation of that expression?


> 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 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=20
fool. I had a honest request and my original thread was not started to=20
play word games. You itself say 'The standard is a little confusing on=20
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=20
that at some point this confusion is so strong, that a defect report is=20
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=20
haven't taken my phrases as I said them e.g. as if I would have said=20
that either int or pointer operators would throw. I never said that! The=20
fact that no-one wonders about the statement "If any operation on T=20
throws an exception the effects are undefined." could of-course mean=20
that my translation of the english sentence into my native language is=20
defect and ambigious, while the original text is not.


Greetings from Bremen,

Daniel Kr=FCgler


---
[ 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                       ]

David Abrahams wrote:
> dsp@bdal.de (Daniel Kr=FCgler) writes:
>=20
>=20
>>msalters wrote:
>>
>>>Daniel Kr=FCgler wrote:
>>>
>>>
>>>>std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
>>>>
>>>>int i =3D 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.=20
>>
>>Where is the proof of that assertion? You have read my comment in my=20
>>original thread concerning interpretations on "operation on", didn't yo=
u?
>=20
>=20
> 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=20
an operation on cin." is not a very satisfying answer. And your=20
reasoning that "knowing how to interpret its intention" is a very=20
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=20
sentence unambigiously clear. Obviously I am the only one who sees that=20
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                       ]

Marc Schoolderman wrote:
> Daniel Kr=FCgler wrote:
>=20
>> Now the critical sentence from paragraph 2:
>> "If any operation on T throws an exception the effects are undefined."
>=20
>=20
> Note that this is paragraph 2, whereas the part enumerating the=20
> requirements on what the footnote calls "value types" is paragraph 1.
>=20
> So the requirement is not "There exist no operations on type T that=20
> might throw". It's just that (as I interpret it) nothing should be=20
> 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=FCgler

---
[ 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                       ]

dsp@bdal.de (Daniel Kr   gler) writes:

> David Abrahams wrote:
>> dsp@bdal.de (Daniel Kr   gler) writes:
>>
>>>msalters wrote:
>>>
>>> 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.

No, it is not.  But that whole line of reasoning was a red herring.
That operation can't be performed by the operations in question.

> And your reasoning that "knowing how to interpret its intention" is
> a very subjective thing.

Absolutely.

> 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.

If what you want to do is to win an argument proving that the standard
could be worded in a more unambiguous way, then, yes, that's the end
of the story.  I was under the impression that you wanted to
understand its meaning.

--
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                       ]

Daniel Kr=FCgler wrote:
> Marc Schoolderman wrote:
>=20
>> Daniel Kr=FCgler wrote:
>>
>>> Now the critical sentence from paragraph 2:
>>> "If any operation on T throws an exception the effects are undefined.=
"

[...]

>>
>> So the requirement is not "There exist no operations on type T that=20
>> might throw". It's just that (as I interpret it) nothing should be=20
>> thrown by operations performed on T by complex<> or valarray<>.
>=20
>=20
> 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*=20
thrown, not if an exception *might* be thrown.  Such an exception is=20
being thrown in the context of valarray<> or complex<> and so the=20
clarification is unnecessary.

The implementation of valarray<> and complex<> is not specified, so for=20
argument sake, they may actually call 'ostream::operator<< (int)'.  This=20
in itself is not undefined behaviour.  If at runtime=20
'ostream::operator<<(int)' does throw an exception 26.1/2 kicks in and=20
says that the behaviour is undefined.


Kind Regards,

Richard


--=20
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                       ]

Daniel Kr   gler wrote:
> kuyper@wizard.net wrote:
> > Daniel Kr   gler wrote:
> >
> >>kuyper@wizard.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.
>
> 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.8) 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.

> > 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.

> > 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.

> 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                       ]

Richard Corden wrote:
> Daniel Kr=FCgler wrote:
>=20
>> Marc Schoolderman wrote:
>>
>>> Daniel Kr=FCgler wrote:
>>>

[...]

> The implementation of valarray<> and complex<> is not specified, so for=
=20
> argument sake, they may actually call 'ostream::operator<< (int)'. =20

[...]

As pointed out in other posts - this is wrong, however the analogy=20
holds.  If 'T' is a class type, its operator+ might be defined in such a=20
way that it throws in some situations.


Regards,

Richard

--=20
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                       ]

David Abrahams wrote:
> dsp@bdal.de (Daniel Kr=FCgler) writes:
>>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=20
>>sentence unambigiously clear. Obviously I am the only one who sees that=
=20
>>in this way, so end of the story.
>=20
>=20
> If what you want to do is to win an argument proving that the standard
> could be worded in a more unambiguous way, then, yes, that's the end
> of the story.  I was under the impression that you wanted to
> understand its meaning.

Of course I wanted to understand its meaning. My short "so end of the=20
story" is the result of a frustration due the unsatisfying replies I got
of most of the participants of this thread. So I try it in another way:

What does the sentence

"If any operation on T throws an exception the effects are undefined."

mean and do you think that this intend is unambigiously expressed in the
standard? My personal impression was (and currently still is) that it
sounds like an absolute requirement on T which is not restricted to any
operations in connection to the class templates std::valarray and
std::complex. What do you think?

Greetings from Bremen,

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                       ]

kuyper@wizard.net wrote:
> Daniel Kr=FCgler wrote:
>>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.8) of the corresponding type". Is that not a valid
>>interpretation of that expression?
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.

Thank you for this careful analyis! I see now the intend of the=20
requirements on the types of valarray and complex. But if you lean back=20
and read the mentioned sentence again: Do think that this intend is=20
expressed unambigiously? For me, the sentence sounds like an absolute
requirement on any operation on T unreleated to its usage with the
numeric container classes (my personal classification of std::complex=20
and std::valarray), but maybe this is due to my naive interpretation as
a nonnative English speaker?


>>>I don't understand your interpretation well enough to figure out how t=
o
>>>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. ...
>=20
>=20
> 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.

I accept that and apologize for my own rough tone.

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                       ]

Daniel Kr   gler wrote:
> kuyper@wizard.net wrote:
.
> Thank you for this careful analyis! I see now the intend of the
> requirements on the types of valarray and complex. ...

In that case, my response to the message that you sent just before
sending this message was unnecessary - I apologize for the duplication.

> ... But if you lean back
> and read the mentioned sentence again: Do think that this intend is
> expressed unambigiously? For me, the sentence sounds like an absolute
> requirement on any operation on T unreleated to its usage with the
> numeric container classes (my personal classification of std::complex
> and std::valarray), but maybe this is due to my naive interpretation as
> a nonnative English speaker?

I think so. Speaking as a well-read and technically literate native
speaker of English, I think the meaning is clear.

.
> I accept that and apologize for my own rough tone.

Apology accepted.


---
[ 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                       ]

dsp@bdal.de (Daniel Kr   gler) writes:

> David Abrahams wrote:
>> dsp@bdal.de (Daniel Kr   gler) writes:

> What does the sentence
>
> "If any operation on T throws an exception the effects are undefined."
>
> mean

Just what it says.  It is describing the effects of a particular call.
If that call invokes any operation on T, directly or indirectly,
and that operation throws an exception, the effects are undefined.

> and do you think that this intend is unambigiously expressed in the
> standard?

For a reasonable definition of "unambiguous," yes.  The standard is
worded to be terse.  If as many words as I used above to make it
clearer to you were required everywhere, the standard would double in
size.  It's probably already too big.

> My personal impression was (and currently still is) that it sounds
> like an absolute requirement on T which is not restricted to any
> operations in connection to the class templates std::valarray and
> std::complex.

Even if it sounds like that to you on the surface, it doesn't take
more than a few moments' thought to see that that interpretation
doesn't make any sense.

> What do you think?

Since you asked, I think it's fine as is.

--
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                       ]

Daniel Kr   gler wrote:
David Abrahams wrote:
> d...@bdal.de (Daniel Kr   gler) writes:
>>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.

I'm not sure that it is bound to it's preceeding paragraph. It may have
been intended to apply to all of the functions in section 26, whereas
the preceding and following paragraphs in section 26.1 all deal with
either <complex> or <valarray>. I've made no assumption that it is so
bound, and i've written the rest of this response on the assumption
that it applies to the functions described in 26.3, 26.4, and 26.5, as
well.

> What does the sentence
>
> "If any operation on T throws an exception the effects are undefined."
>
> mean ...

I think that if any operation on T throws, i.e. an actual throw()
statement is executed (and not caught inside T-related code), that the
effects are undefined. An implementation is free to either try to catch
the exception, or not, or to write code for the functions described in
section 26 that would misbehave badly if an exception were actually
thrown by such an operation. I think that this applies only with
respect to actual throws occurring during actual calls to functions
described by section 26, and that it therefore doesn't matter if any
operation NOT performed by those functions could throw(). Also, if an
operation that could throw() is performed, but it doesn't actually
throw(), the behavior remains defined.

Each function described in section 26 has only a limited number of
operations on T that it's permitted to assume are available for
user-defined types. complex<> and valarray<> are allowed to assume the
existence of the constructors and destructors and assignment operations
mentioned in 26.1p1. complex<> is allowed to assume that T is float,
double, or long double, with all that this implies. The generalized
numeric functions are allowed to assume the existence of the operations
implied by the names used by the standard for the template arguments,
according to the conventions used in section 25 (26.4p1). Each function
described in section 26 is allowed to assume support for whatever
operations are used to describe the defined behavior of that function.
In general, no other operations may be assumed to exist, and therefore
it cannot matter whether or not those operations throw().

It would be feasible for an implementation to specialize one of these
functions for a standard-defined type, and take advantage of some
operation defined by the standard for that type which is not otherwise
allowed. However, since the defined behavior is in terms of specific
operations, if those operations don't throw, and an alternative
operation does throw, the implementation is required to catch such
exceptions, and  make the final result appear as if everything was done
using only the specified operations.

> ... and do you think that this intend is unambigiously expressed in the
> standard? ...

Yes, except for the fact that it's unclear whether 26.1p2 applies only
to <complex> and <valarray>, like the rest of 26.1, or whether it
applies to all of the functions defined in section 26.


---
[ 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                       ]

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                       ]

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.

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                       ]

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.

> 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.

> (*): 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                       ]

Daniel Kr=FCgler 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=20
requirements on what the footnote calls "value types" is paragraph 1.

So the requirement is not "There exist no operations on type T that=20
might throw". It's just that (as I interpret it) nothing should be=20
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                       ]

msalters wrote:
> Daniel Kr=FCgler wrote:
>=20
>=20
>>std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
>>
>>int i =3D 0;
>>
>>std::cin >> i;
>>
>>This proves that there exists at least one operation on int that can
>>throw an exception.
>=20
>=20
> No, that's an operation on cin.=20
>=20

Where is the proof of that assertion? You have read my comment in my=20
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                       ]

kuyper@wizard.net wrote:
> Daniel Kr=FCgler wrote:
>=20
>>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 instantiat=
e
>>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 =3D 0;
>>
>>std::cin >> i;
>>
>>This proves that there exists at least one operation on int that can
>>throw an exception.
>=20
>=20
> 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=20
your interpretation? But see below...

>>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?
>=20
>=20
> 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.
>=20

OK, that is your interpretation. But lets see further..


>>(*): 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.
>=20
>=20
> 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=20
I must conclude the following:

I was wrong, because I interpreted the meaning of "sequence" as meaning=20
the interpretation of "range" (pair of iterators, with some requirements=20
on them). It is funny, that the standard says "[..] algorithmic=20
operations on containers [..] and other sequences." because
not **a single function in chapter 25** does make an operation on a=20
Container nor on a Sequence according to the definition of Sequence and=20
Container from chapter 23. So there is no member function call on=20
sequences in algorithms as your answer implies.

The only operational semantic which is demanded is those "inherited"=20
from iterators according to the definition of iterators in ch. 24. So=20
there are "member" functions called from iterators (and functors), not=20
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=20
during IO-streaming) ;-)

- to the interpretation that pointers are no valid arguments for algorith=
ms.

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=20
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                       ]

Marc Schoolderman wrote:
> Daniel Kr=FCgler wrote:
>=20
>> Now the critical sentence from paragraph 2:
>> "If any operation on T throws an exception the effects are undefined."
>=20
>=20
> Note that this is paragraph 2, whereas the part enumerating the=20
> requirements on what the footnote calls "value types" is paragraph 1.
>=20
> So the requirement is not "There exist no operations on type T that=20
> might throw". It's just that (as I interpret it) nothing should be=20
> thrown by operations performed on T by complex<> or valarray<>.
>=20

Right. "throws" means actually throwing something at runtime. It is=20
ordinary English, not the sloppy shorthand of saying "throws" to mean=20
"could throw."

--=20

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                       ]

"Daniel Kr=FCgler" <dsp@bdal.de> wrote in message=20
news:432e6a4e$0$307$4d4ebb8e@businessnews.de.uu.net...

> 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 =3D 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=20
operation throws an exception" rather than "if any operation is potential=
ly=20
capable of throwing an exception, even if it doesn't do so in this contex=
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

dsp@bdal.de (Daniel Kr=FCgler) writes:

> msalters wrote:
>> Daniel Kr=FCgler wrote:
>>=20
>>>std::cin.exceptions(std::ios_base::failbit | std::ios_base::eofbit);
>>>
>>>int i =3D 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.=20
>
> Where is the proof of that assertion? You have read my comment in my=20
> original thread concerning interpretations on "operation on", didn't yo=
u?

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,
--=20
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                       ]

Daniel Kr   gler wrote:
> kuyper@wizard.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.

.
> 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.

> 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.

> 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.

> 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                       ]