Topic: incrementable, dereferenceable.definition
Author: viboes <vicente.botet@wanadoo.fr>
Date: Sat, 26 Feb 2011 11:23:18 CST Raw View
In "24.2.4 Output iterators" there are 3 uses of incrementable. I've
not found the definition. Could some one point me where it is defined?
Something similar occurs with dereferenceable. While the definition is
given in "24.2.1 In general" it is used several times before.
Shouldn't these definitions be moved to some previous section?
Best,
Vicente
--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: =?windows-1252?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Sun, 27 Feb 2011 17:29:00 CST Raw View
Am 26.02.2011 18:23, schrieb viboes:
>
> In "24.2.4 Output iterators" there are 3 uses of incrementable. I've
> not found the definition. Could some one point me where it is defined?
Yep, an individual definition is missing and I think adding them would
certainly make the situation clearer.
My understanding has been that it is supposed to mean that for a
corresponding iterator category a pre-increment or post-increment
operation is well-defined. My understanding is, that this includes
the following expressions for an output iterator r:
++r
r++
*r++ = o
Whether the lack of a precise definition here is hard to say. E.g.
Table 63 basic_string(const Allocator&) effects or
[thread.mutex.requirements.mutex] p. 3 use the term "copyable", but
there is no definition of this term - does that reach the level of a
defect as well? (The core language defines the term "trivially copyable"
which is a completely different beast).
What concerns me much more for the moment now is the fact that the
output iterator requirements (Table 108) deviate completely from the
last big change caused by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html
It does not make sense that all operations have the post-conditions of
leading to an incrementable iterator and this was not suggested by n3066.
> Something similar occurs with dereferenceable. While the definition is
> given in "24.2.1 In general" it is used several times before.
>
> Shouldn't these definitions be moved to some previous section?
There is no strict requirement that a definition of some term in the
standard precedes any reference to it. I agree that such situations make
it harder to read the standard and should be prevented whenever
possible, but sometimes it would cause much more work to reword the
standard to realize this noble principle. E.g. the Swappable
requirements refer to iterator requirements and mention the term
deferencable. I find it hard to argue that this means that both the
iterator requirements and the definition of dereferencable have to occur
before the Swappable requirement set.
HTH & Greetings from Bremen,
Daniel Kr gler
--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]