Re: string upper, string lower, string subthisforthat
From: Chris \( Val \) (chrisval_at_bigpond.com.au)
Date: 09/27/04
- Next message: Chris \( Val \): "Re: ios::failbit always true"
- Previous message: Chris \( Val \): "Re: string upper, string lower, string subthisforthat"
- In reply to: Alwyn: "Re: string upper, string lower, string subthisforthat"
- Next in thread: Alwyn: "Re: string upper, string lower, string subthisforthat"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Sep 2004 20:09:23 +1000
"Alwyn" <dt015a1979@mac.com.invalid> wrote in message
news:260920041234416918%dt015a1979@mac.com.invalid...
| In article <2rlhvrF1aavtiU1@uni-berlin.de>, Val \
| <chrisval@bigpond.com.au> wrote:
| >
| > So, it seems to me, that it is implied (by a few prominent
| > people), that the standard is wrong in this regard, and that
| > it should be corrected.
|
| I would rather say that it contains multiple deficiencies (and should
| be amended).
|
| * 'for_each' is listed among the non-modifying algorithms. It is
| nowhere defined what a non-modifying algorithm actually is.
At the moment, yes.
| * Like other 'non-modifying' algorithms, 'for_each' takes an input
| iterator. Does this imply that the function object supplied to the
| algorithm should not change values in the sequence?
Apparently not.
| * Stepanov and Lee's specification of the STL 'for_each' states:
| € UnaryFunction does not apply any non-constant operation through
| its argument.
| <http://www.sgi.com/tech/stl/for_each.html>
| This requirement appears in the public draft standard (which is what
| Stroustrup is referring to) but not in the final version. Was it a
| deliberate omission or an oversight?
I don't know to be honest.
| * The C++ standard places no restrictions on the behaviour of the unary
| function supplied to 'for_each'. Langer argues persuasively that the
| standard should state explicitly that it should not invalidate
| iterators or subranges.
Yes.
| > Can I assume that we all now agree, that 'for_each' can be
| > used to modify it's arguments, and transform cannot ?
|
| It is stated that the functions supplied to 'transform' should be free
| of side effects. For me, this is too strong a requirement. (Merely
| displaying a value is one kind of side effect, and it is harmless in
| this context.) The side effects that are not allowed should be
| specified precisely, namely that none of the sequences supplied to the
| algorithm or the values contained therein can be modified. This is
| essential, as 'transform' can be used to modify a sequence in place
| (i.e. one of the input iterators can be the same as the output
| iterator).
|
| As for 'for_each', it seems to me that the original restriction
| specified by Stepanov and Lee was removed deliberately from the draft
| standard, perhaps at Stroustrup's request, but in that case, they did
| not go far enough, perhaps because they were in a hurry. As far as I
| can see, the consensus is that modifying values within the sequence is
| harmless, while there are other side effects (i.e. modifying the
| sequence itself, adding or removing elements, invalidating iterators)
| that must not be allowed to happen.
| As things stand, a program like the one I showed elsewhere in the
| thread, which modifies elements in a sequence, cannot be shown to
| violate any official standard. I am no clairvoyant, but I would say
| that it is unlikely to do so in the future either.
Your points are well noted, and you may well be right.
I'll try to read up some more on this stuff, when I get a chance.
Thanks for your comments.
Chris Val
- Next message: Chris \( Val \): "Re: ios::failbit always true"
- Previous message: Chris \( Val \): "Re: string upper, string lower, string subthisforthat"
- In reply to: Alwyn: "Re: string upper, string lower, string subthisforthat"
- Next in thread: Alwyn: "Re: string upper, string lower, string subthisforthat"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
