|
Boost : |
Subject: Re: [boost] [variant] Please vote for behavior
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-01-29 18:17:35
On 1/30/13 6:50 AM, Rob Stewart wrote:
> On Jan 29, 2013, at 7:04 AM, Joel de Guzman <djowel_at_[hidden]> wrote:
>
>> On 1/29/13 6:56 PM, Rob Stewart wrote:
>>>
>>> Singular iterators are default constructed instances that represent a universal
>>> end iterator. They are not associated with any particular container, but would be
>>> returned by end(), and can be obtained by advancing a non-end iterator far enough.
>>
>> Singular valued iterators cannot be compared (*). The only valid operations are
>> assignment, destruction and move. There is no way to detect a singular valued
>> iterator.
>>
>> (* Iterators can also have singular values that are not associated with any sequence.
>> [ Example: After the declaration of an uninitialized pointer x (as with int* x;), x
>> must always be assumed to have a singular value of a pointer. âend example ] Results
>> of most expressions are undefined for singular values; the only exceptions are
>> destroying an iterator that holds a singular value, the assignment of a non-singular
>> value to an iterator that holds a singular value, and, for iterators that satisfy the
>> DefaultConstructible requirements, using a value-initialized iterator as the source
>> of a copy or move operation.)
>
> Oh, sure, slap me down with the standard! :)
>
> Seriously, I was thinking of, for example, std::istream_iterator. If the default
> constructor doesn't create a singular iterator, what is the right name? I've either
> forgotten it or long misapplied "singular" to such iterators.
Oh right. Yeah, it will work for std::istream_iterator. In that case,
no, it's not "singular valued". I think it's just default contructed,
unless I am missing a name too. Some default constructed iterators
(e.g. as you pointed out) do not result to being "singular valued".
Cheers,
-- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk