Dave Abrahams wrote:

on Wed Sep 28 2011, Nathan Ridge wrote:

...

...

2. The concept mechanism used by Boost should not require singular iterators to exist; the standard is obnoxious and misguided here and promotes sloppy coding.

I think the Boost authors are unlikely to decide to ignore a part of the standard just because one person believes it is obnoxious and misguided and promotes sloppy coding.

I would suggest making your case about the default constructibility of forward iterators at comp.std.c++. If you gain consensus there that this requirement is indeed misguided, then your request will carry more weight here.

I'd also like to point out that there's no rule saying default-constructed iterators must be singular.

A default-constructed iterator must be singular not because the government says so but because of logic. You usually get wet when it rains, although there is no rule saying that you must. Standard iterators are all singular by default. An exception would be an iterator to a singleton container or an iterator defined in a closure; those are, however, edge cases. IMHO, Chris

On Thu, Sep 29, 2011 at 9:50 AM, Dave Abrahams wrote:

on Thu Sep 29 2011, Krzysztof Żelechowski wrote:

...

Dave Abrahams wrote:

...

on Wed Sep 28 2011, Nathan Ridge wrote:

...

...

2. The concept mechanism used by Boost should not require singular iterators to exist; the standard is obnoxious and misguided here and promotes sloppy coding.

I think the Boost authors are unlikely to decide to ignore a part of

the

...

...

standard just because one person believes it is obnoxious and misguided and promotes sloppy coding.

I would suggest making your case about the default constructibility of forward iterators at comp.std.c++. If you gain consensus there that this requirement is indeed misguided, then your request will carry more weight here.

I'd also like to point out that there's no rule saying default-constructed iterators must be singular.

A default-constructed iterator must be singular not because the government says so but because of logic.

No. Well, we have to say what we mean by "is singular." Because the concept "singular" only contains two operations (assign and destroy), every valid iterator is-a singular iterator in some sense. But I suspect you mean "minimally singular," and there's no reason at all that a default-constructed iterator need be minimally singular. You usually can't make it usefully dereferenceable (would you want to?) but you can make it copyable, for example. A wrapper over a plain pointer could initialize the pointer to 0. Now it's a valid past-the-end iterator into an array of length zero. Such an iterator is also comparable with other iterators into the same sequence. That's actually far from being minimally singular.

I'm sorry - but regarding the statement "every valid iterator is-a singular iterator in some sense"... I thought the Standard (2003) explicitly stated that *singular *values for an iterator had all but one operation as Undefined Behavior, and the only defined operation on an iterator with a singular value was to assign it a non-singular value. (24.1, para 5) *Results of most expressions are undefined for singular values; the only exception is an assignment of a non-singular value to an iterator that holds a singular value. In this case the singular value is overwritten the same way as any other value. Dereferenceable values are always nonsingular.* Doesn't the last sentence make it true that "every valid iterator is-a *non*singular iterator"? I also thought it was the case that the latest standard defines *singular *to be the same as *uninitialized *with respect to iterators? If that's the case then we cannot call a valid iterator a singular iterator in any sense. "I am but an egg", but it seem that there's no need to create a new term when the old one is well-defined and sufficient. regards, Brian

Yes; this is a problem with negative requirements statements.  Just like you can't decrement a forward iterator, you can't dereference a singular iterator.

The characterization "just like" is a little off. Trying to decrement a forward iterator is a conceptual error. Trying to dereference an iterator with a singular value is a logic error. I think we get into trouble when we talk about "valid iterators". I don't think there's such really such a thing at all. There may be cases where it's valid to decrement an iterator, but not dereference it. There may be cases where it's valid to dereference an iterator but not decrement. A PTE iterator is well-formed, but both incrementing and dereferencing is invalid.

The point is that the OP claimed every default-constructed iterator is singular.  The only way that could be true is if you take the term "is-a" in the sense I'm using it here.  That is, I can easily create an iterator that, when default-constructed, supports a strict superset of the required operations for singular iterators.

Without any strong guarantees about the state of default constructed iterators in general, I don't think I'd try to use them in a generic algorithm. This is just begging for trouble: template<typename I> auto f() { I i; assert(*i); } // worst algorithm ever If I know that the iterator has valid operations after being default constructed, then I'll do as I like -- whatever the concept does or does not say. counting_iterator<int> i(0); cout << *i <<; // should work just fine

...

template<typename I>   auto f() { I i; assert(*i); } // worst algorithm ever

OTOH, if I know that a singular iterator of some type would have no valid operations, and the iterator is only meant to be used by algorithms, the benefit of being unable to create a singular iterator (like when the iterator in question holds a reference to supporting data used in its operation) outweighs the benefit of being able to do so.

I think I've lost the thread of the argument. Are you saying that you should *not* be able to default construct iterators?

on Sat Oct 01 2011, Krzysztof Żelechowski wrote:

Andrew Sutton wrote:

...

...

...

template<typename I> auto f() { I i; assert(*i); } // worst algorithm ever

...

OTOH, if I know that a singular iterator of some type would have no valid operations, and the iterator is only meant to be used by algorithms, the benefit of being unable to create a singular iterator (like when the iterator in question holds a reference to supporting data used in its operation) outweighs the benefit of being able to do so.

I think I've lost the thread of the argument. Are you saying that you should *not* be able to default construct iterators?

What I am saying is that iterators that are not default-constructible are sometimes more robust because an attempt to create them out of thin air results in a compile-time error.

Yes... except that they are not iterators.

I am not saying that all iterators are like that (I agree with Dave regarding his the interpretation of NULL). Moreover, such iterators sometimes come up naturally from standard components (and not some shady third-party ones, as has been suggested), as evidenced in my code that fails to compile with Boost concepts.

Sorry, which code was that?

Being a singular iterator is not a concept, it is a run-time property. The compiler cannot check whether an operator is singular, it is equivalent to the halting problem.

It can't check whether an iterator is random-access either. All (good) concepts have semantic constraints that can't be checked by the compiler. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Sun Oct 02 2011, Krzysztof Żelechowski wrote:

Dave Abrahams wrote:

...

on Sat Oct 01 2011, Krzysztof Żelechowski wrote:

...

What I am saying is that iterators that are not default-constructible are sometimes more robust because an attempt to create them out of thin air results in a compile-time error.

Yes... except that they are not iterators.

Let’s call them concrete quasi-iterators then. It is less important how you call them than what you can do with them.

...

...

I am not saying that all iterators are like that (I agree with Dave regarding his the interpretation of NULL). Moreover, such iterators sometimes come up naturally from standard components (and not some shady third-party ones, as has been suggested), as evidenced in my code that fails to compile with Boost concepts.

Sorry, which code was that?

In the opening post.

*rewinds to opening post* Lack of documentation aside, what's the underlying problem there? Oh, the result of bind1st is not default-constructible? Well, that's what you get for using deprecated components ;-) More seriously... I understand the problem. What's obnoxious is that the standard doesn't have a consistent view of the importance of Regular Types (c.f. Stepanov). Those binders are not Regular since they don't have a default-constructor... well, neither are many iterators because they don't all have a total ordering, but I think the notion of Regular may have been expanded since '98... but anyway, yeah, let's just say the standard's inconsistent view of default construction causes an interoperability problem. For the record, I'm torn about the whole "Regular Types" thing. I can see the argument for it, but it also forces weaker invariants. Now, I *think* what you want is for the Range library to "degrade gracefully" when you don't satisfy its concept requirements, and the appropriate thing to do there is shut off concept checking. If the Range library were to put its "concept checking stamp of approval" on a nonconforming iterator it would be failing to provide an assurance I want: that the resulting iterator can be used with *any* algorithm requiring iterators. If I can get an error later by passing the resulting iterator to some algorithm that happens to use default construction, then I have a right to complain that concept checking is broken.

...

...

Being a singular iterator is not a concept, it is a run-time property. The compiler cannot check whether an operator is singular, it is equivalent to the halting problem.

It can't check whether an iterator is random-access either. All (good) concepts have semantic constraints that can't be checked by the compiler.

An algorithm using a bidirectional iterator for a random-access iterator will still work, only it will take longer to accomplish.

No. A bidirectional iterator can provide different semantics (or invoke undefined behavior) for random-access iterator operations that are not part of the bidirectional iterator concept.

Also, being a singular iterator is independent of type, while being a random-access iterator is determined by type.

No again. Objects of this type are not singular iterators: struct nonsingular { private: void operator=(nonsingular const&); }; Singular values crop up in all kinds of contexts, BTW. Do ints support division? Well, yes, unless the denominator is zero. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Sun Oct 02 2011, Andrew Sutton wrote:

...

...

Also, being a singular iterator is independent of type, while being a

...

...

random-access iterator is determined by type.

No again.  Objects of this type are not singular iterators:

  struct nonsingular   {    private:        void operator=(nonsingular const&);   };

Singular values crop up in all kinds of contexts, BTW.  Do ints support division?  Well, yes, unless the denominator is zero.

I'm sorry. This is completely wrong. 0 is value -- a state of an numeric type -- just like singularity is the state of some iterators.

Yes. I don't see that as a contradiction.

In fact, I think you actually prove Chris' point, here; you've just extended the notion of singularity from iterators to integers.

It's not like I just did something new, here!

I would take that to mean that singularity is independent of type.

Although many types have singular values with respect to certain operations (NULL is singular with respect to pointer dereference), - Not every type has singular values - Some types have multiple singular values - In general, one type's singular values are distinct from another type's singular values I don't know what you and Chris mean by "independent of type," but to me this sounds like singularity is highly dependent on type. I suspect this situation is less one of "you're completely wrong" than "you and I are understanding the same words in different ways." Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Dave Abrahams wrote:

on Sun Oct 02 2011, Andrew Sutton wrote:

...

I would take that to mean that singularity is independent of type.

Although many types have singular values with respect to certain operations (NULL is singular with respect to pointer dereference),

- Not every type has singular values - Some types have multiple singular values - In general, one type's singular values are distinct from another type's singular values

I don't know what you and Chris mean by "independent of type," but to me this sounds like singularity is highly dependent on type.

It means iterators of the same type can be singular but need not, whereas all (valid) iterators of the same type either must support random access operations or must not, depending on the type in question. Of course, the result of subtraction may be undefined, but it will not fail to compile. If you insist that random access iterators are things you can universally subtract, it will be a concept that applies to pairs, not to individual objects.

I suspect this situation is less one of "you're completely wrong" than "you and I are understanding the same words in different ways."

Probably :-( Best regards, Chris

on Mon Oct 03 2011, Jeremiah Willcock wrote:

Another complicating issue is that an iterator is singular or non-singular with respect to a particular container. For example, given the following declarations:

int a[5], b[5];

and assuming a and b are contiguous in memory, &a[5] is a singular iterator for the array a

It's a PTE iterator, which is not minimally singular. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Mon Oct 03 2011, Krzysztof Żelechowski wrote:

Dave Abrahams wrote:

...

on Sun Oct 02 2011, Andrew Sutton wrote:

...

I would take that to mean that singularity is independent of type.

Although many types have singular values with respect to certain operations (NULL is singular with respect to pointer dereference),

- Not every type has singular values - Some types have multiple singular values - In general, one type's singular values are distinct from another type's singular values

I don't know what you and Chris mean by "independent of type," but to me this sounds like singularity is highly dependent on type.

It means iterators of the same type can be singular but need not, whereas all (valid) iterators of the same type either must support random access operations or must not, depending on the type in question.

Not so, and I can think of a counterexample, but I'm getting tired of arguing about it. I don't think this is really relevant to the discussion in the end, is it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Tue Oct 04 2011, Krzysztof Żelechowski wrote:

I can think of a counterexample, but I'm getting tired of

...

arguing about it. I don't think this is really relevant to the discussion in the end, is it?

I understand that you may be tired of my questions, and I appreciate your answering them :-) Thank you very much anyway.

To clarify: I'm not tired of your questions; I'm tired of arguing about whether singularity is dependent on type. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Sun Oct 02 2011, Andrew Sutton wrote:

I think an interesting question is, "what are the general properties of iterators that causes operations on them to result in singularity?". When is *i defined?

Two separate questions. PTE iterators are "nonsingular" (i.e. support a superset of the operations required of singular iterators) but you can't dereference them. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Mon Oct 03 2011, Krzysztof Żelechowski wrote:

Dave Abrahams wrote:

...

*rewinds to opening post*

Lack of documentation aside, what's the underlying problem there? Oh, the result of bind1st is not default-constructible? Well, that's what you get for using deprecated components ;-)

It would help if you could offer a replacement that does the same thing, compiles in traditional mode and does not involve defining a dedicated iterator class.

You could pass it through boost::function. I'm not sure if boost::bind makes default-constructible things... nor am I sure about phoenix/lambda.

...

Now, I *think* what you want is for the Range library to "degrade gracefully" when you don't satisfy its concept requirements, and the appropriate thing to do there is shut off concept checking.

Do not switch all concept checking off if it fails; switch default constructibility check off always.

Yes, but that would be wrong, if the library is going to advertise that it checks for the standard iterator concepts. On the other hand, if the library doesn't advertise its checks, then that's up to the author.

...

If the Range library were to put its "concept checking stamp of approval" on a nonconforming iterator it would be failing to provide an assurance I want: that the resulting iterator can be used with *any* algorithm requiring iterators. If I can get an error later by passing the resulting iterator to some algorithm that happens to use default construction, then I have a right to complain that concept checking is broken.

My point is, I am unable to imagine an algorithm that requires constructing iterators out of thin air. Some algorithms do that, for no other reason than the programmer did not know better, and they can be fixed to avoid this construct, and when they get fixed, the code gets better. So requiring default construction of iterators leads to looser library code. If you happen to know such an algorithm, please share it with us.

I don't. It doesn't matter whether the requirement was wrong, though.

...

...

An algorithm using a bidirectional iterator for a random-access iterator will still work, only it will take longer to accomplish.

No. A bidirectional iterator can provide different semantics (or invoke undefined behavior) for random-access iterator operations that are not part of the bidirectional iterator concept.

But I can use the operations defined on a bidirectional iterator to simulate the operations of a random access iterator, can’t I?

No; you can't measure the distance between two arbitrary bidirectional iterators unless you know which one comes first. But my point is that if the iterator is truly bidirectional but it advertises itself to be random-access, you have no way of knowing to use multiple ++ invocations instead of one +=, and += could do something arbitrarily horrible.

...

...

Also, being a singular iterator is independent of type, while being a random-access iterator is determined by type.

No again. Objects of this type are not singular iterators:

struct nonsingular { private: void operator=(nonsingular const&); };

Why do you call this thing an iterator?

Exactly my point; I don't. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Thu, Sep 29, 2011 at 3:59 PM, Dave Abrahams wrote:

on Thu Sep 29 2011, Brian Allison wrote:

...

On Thu, Sep 29, 2011 at 9:50 AM, Dave Abrahams wrote:

I'm sorry - but regarding the statement "every valid iterator is-a singular iterator in some sense"... I thought the Standard (2003) explicitly stated that singular values for an iterator had all but one operation as Undefined Behavior, and the only defined operation on an iterator with a singular value was to assign it a non-singular value. (24.1, para 5)

Yes; this is a problem with negative requirements statements. Just like you can't decrement a forward iterator, you can't dereference a singular iterator. However, a bidirectional iterator, which you can decrement, is-a forward iterator. In the same way, a valid iterator is-a singular iterator.

Your ontology seems to have no basis in the ontology of the standard. The last sentence I quoted: *Dereferenceable values are always nonsingular.* This sentence doesn't leave room for a statement like "every valid iterator is-a singular iterator in some sense", given that dereferenceable iterators are valid, and the standard explicitly states that they are non-singular. Your definition of "in a sense" and "in teh same way" are then in contradiction to the standard. You can't modify that requirement of the standard to behave as a parent class acts in a type algebra, where a subclass can override the superclass - unless there is another part of the standard which allows such a replacement [is there?]. Rather, this particular definition seems to set "singular" values apart from defined (whether or not they're safe to dereference) values. If we want to map the concepts to a type algebra, then a singular value would correspond to a "final" type that prohibits subclassing. If we want to be precise about the three partitions of iterators, we should use "singular" in the way that the standard uses it. We could easily use two more terms: Dereferenceable & Nonsingular, where the former is a proper subset of the latter. But the standard seems to explicitly make Singular iterators a non-intersecting set with the Nonsingular set, and all iterators must belong to exactly one of Singular or Nonsingular.

...

Results of most expressions are undefined for singular values; the only exception is an assignment of a non-singular value to an iterator that holds a singular value. In this case the singular value is overwritten the same way as any other value. Dereferenceable values are always nonsingular. Doesn't the last sentence make it true that "every valid iterator is-a nonsingular iterator"?

(it doesn't, even by logic, since some valid iterators are not dereferenceable, but that aside...). In the sense I'm using is-a, a nonsingular iterator is-a singular iterator. How's that for fun logic? :-)

Your ontology seems to require an overriding of the standard - which part of the standard allows for that overriding?

When the standard says "that's a singular iterator" it's saying you can only assume it supports two operations. That doesn't mean it can't support more operations. It's a constraint on the user, not on the iterator.

But when it says "*Dereferenceable values are always nonsingular.*", that seems to be a constraint on the iterator. Being X or Non-X are mutually exclusive.

In the sense of concept requirements, you can. Any valid iterator supports a superset of the requirements on singular iterators

If you're only concerned with the positive requirements of a concept, then yes. But we must be concerned with both positive and negative requirements - since the standard explicitly excludes dereferenceable values from being singular, then being "singular" doesnt' really map well to concept requirements [if I understand your contextual use of the term].

The point is that the OP claimed every default-constructed iterator is singular. The only way that could be true is if you take the term "is-a" in the sense I'm using it here. That is, I can easily create an iterator that, when default-constructed, supports a strict superset of the required operations for singular iterators.

But I could make an iterator type whose constructor would throw() if it were not to a valid member. A contrived example, but then there would be a type which would refute OP's claim while adhering to the standard. Hence, the OP's claim is in error. Curiosity: why are you trying to form an algebra in which the OP's claim is correct?

On Fri, Sep 30, 2011 at 11:22 AM, Dave Abrahams wrote:

on Thu Sep 29 2011, Brian Allison wrote:

...

On Thu, Sep 29, 2011 at 3:59 PM, Dave Abrahams wrote:

Your ontology seems to have no basis in the ontology of the standard. The last sentence I quoted:

Dereferenceable values are always nonsingular.

This sentence doesn't leave room for a statement like "every valid iterator is-a singular iterator in some sense", given that dereferenceable iterators are valid, and the standard explicitly states that they are non-singular. Your definition of "in a sense" and "in teh same way" are then in contradiction to the standard.

Not if a nonsingular iterator is-a singular iterator. That way of using is-a is the only sense that makes the OP's claim true. Either you have to accept that way of using is-a or you have to reject the OP's claim. I'm able to use and think about "is-a" that way, and if you chafe at the idea that a nonsingular iterator is-a singular iterator, that's fine with me. I think that means you have to reject the claim that all default-constructed iterators are singular, which is also fine with me.

It's not an issue of chafing, but accepting the OPs claim to be true requires the quoted sentence to be nonsensical. I'm not sure of any useful algebra where a member can be both X and non-X simultaneously. If there is one, please share? However, refuting the OPs claim has not even an apparent contradiction either to the standard or to my own understanding of fundamental logic.

Dave Abrahams wrote:

make it copyable, for example. A wrapper over a plain pointer could initialize the pointer to 0. Now it's a valid past-the-end iterator into an array of length zero. Such an iterator is also comparable with other iterators into the same sequence. That's actually far from being minimally singular.

I doubt there may be a sequence of length 0 at NULL. How would you allocate such a sequence? Chris

on Fri Sep 30 2011, Brian Allison wrote:

That's not what he said.

As an aside though, recall that char foo[0]; is a valid declaration of a zero-length aray.

Not in C++98, IIRC. Did that change, or am I mistaken? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2011/9/30 Krzysztof Żelechowski :

Dave Abrahams wrote:

...

make it copyable, for example.  A wrapper over a plain pointer could initialize the pointer to 0.  Now it's a valid past-the-end iterator into an array of length zero.  Such an iterator is also comparable with other iterators into the same sequence.  That's actually far from being minimally singular.

I doubt there may be a sequence of length 0 at NULL.  How would you allocate such a sequence?

You don't need to allocate anything if your sequence is of length 0, since a NULL pointer is comparable, destroyable and copyable. It can't be dereferenced nor incremented but if the sequence has length 0 you can't anyway.

Chris

-- Felipe Magno de Almeida

On Fri, Sep 30, 2011 at 11:24 AM, Andrew Sutton wrote:

...

I doubt there may be a sequence of length 0 at NULL.  How would you allocate such a sequence?

Actually, every iterator (singular, initialized, pointing to viable memory or not) defines its own empty range. That is, for every i, [i, i) is an empty range, which means that, if all you know is that you have that range, then it is not valid to increment, decrement, or dereference. You can certainly construct an empty range on nullptr.

You can't equally-compare a singular iterator. -- Felipe Magno de Almeida

On Fri, Sep 30, 2011 at 12:06 PM, Andrew Sutton wrote:

...

You can't equally-compare a singular iterator.

Why not? Isn't an object equal to itself?

Because a singular iterator can be a uninitialized variable and you can't equally-compare a uninitialized variable, nor copy it. All you can do is assign and destroy it. Regards, -- Felipe Magno de Almeida

On Fri, Sep 30, 2011 at 12:31 PM, Andrew Sutton wrote:

...

...

Why not? Isn't an object equal to itself?

Because a singular iterator can be a uninitialized variable and you can't equally-compare a uninitialized variable, nor copy it. All you can do is assign and destroy it.

I know what the standard says, but shouldn't this always return true?

It should what the standard says. If it says anything can happen, then anything can happen. Including crashing. It is perfectly possible for a CPU to trap on uninitialized variables for example.

int* i; assert(i == i);

Regardless of the actual value? It seems to me that this is a pretty fundamental property: an object is always equal to itself*. If you believe it, then you're allowed to construct empty bounded ranges of singular values [i, i).

* Excluding volatile objects.

Regards, -- Felipe Magno de Almeida

On Fri, Sep 30, 2011 at 11:06 AM, Andrew Sutton wrote:

...

You can't equally-compare a singular iterator.

Why not? Isn't an object equal to itself?

There's nothing in the standard to say that an uninitialized variable must be equal to itself. Especially since the standard states that the only defined operation on a singular iterator is ... assignment. If a clever compiler computed the lifespan of all memory usage, is there anything in the standard which would keep it from using the memory of Singular Iterators as temporary storage? Or randomly bit-twiddling the bits in them while they are Singular?

On Fri, Sep 30, 2011 at 12:08 PM, Andrew Sutton wrote:

...

There's nothing in the standard to say that an uninitialized variable must be equal to itself.

Especially since the standard states that the only defined operation on a singular iterator is ... assignment.

Again, I'm not talking about the standard. I'm talking about basic expectations.

If your basic expectations do not take the standard into account then your expectations may lead you to Undefined-Behavior-Land.

...

If a clever compiler computed the lifespan of all memory usage, is there anything in the standard which would keep it from using the memory of Singular Iterators as temporary storage? Or randomly bit-twiddling the bits in them while they are Singular?

I think any argument that starts with the phrase "If a clever..." is automatically suspect. There are lots of clever things that might be done, but I wonder at what cost. Would you trust your hypothetical compiler to get lifetime right? Do you really want this compiler to modify values behind your back?

Optimizations are clever, and used to be viewed with suspicion.

On Fri, Sep 30, 2011 at 12:45 PM, Andrew Sutton wrote:

...

If your basic expectations do not take the standard into account then your expectations may lead you to Undefined-Behavior-Land.

Again, the standard is too strict with this limitation; it can be relaxed. Objects of regular types should always be equal to themselves even when they are uninitialized or have singular value.

When discussing what is allowed on a type T, you're intrinsically discussing the standard. When discussing what a compiler allows, you're not. When discussing what you'd *like *to be allowed, you're not. I had thought we were discussing what was allowed on type T.

...

Optimizations are clever, and used to be viewed with suspicion.

I don't think that this is an unreasonable position.

Yet "any sentence that starts with 'a clever compiler' should be viewed with suspicion" contradicts the very position you think is reasonable, and was stated as an answer to an example of an optimization a clever compiler might make.

http://lists.boost.org/mailman/listinfo.cgi/boost-users

I read that as a comment about a hypothetical perfect compiler. One that completely complied with The Standard, and had perfect optimization. Such a compiler would nevertheless be allowed to fiddle with the iterator and be compliant. While providing an iterator that could not be compared to itself (not releiably). Probably, Richard.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Andrew Sutton Sent: 30 September 2011 18:09 To: boost-users@lists.boost.org Subject: Re: [Boost-users] A forward iterator need not be default-constructible

...

I had thought we were discussing what was allowed on type T.

Sure, but that doesn't invalidate my statement that the standard's limitations are too strict. I'm just thinking ahead.

...

Yet "any sentence that starts with 'a clever compiler' should be viewed with suspicion" contradicts the very position you think is reasonable, and was stated as an answer to an example of an optimization a clever compiler might make.

I think you may have misunderstood. I think that it is a reasonable position to view some optimizations as suspicious. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

on Fri Sep 30 2011, Andrew Sutton wrote:

...

If your basic expectations do not take the standard into account then your expectations may lead you to Undefined-Behavior-Land.

Again, the standard is too strict with this limitation; it can be relaxed.

Not if you want pointers to be iterators, and we do. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

...

Actually, every iterator (singular, initialized, pointing to viable memory or not) defines its own empty range.

No, I don't believe that's quite correct.  There are lots of things one can do with iterators in a range that one cannot do with a minimally-singular iterator.

Well, two anyways: == and !=. Given that the standard doesn't allow those on singular-valued iterators, you're right. I think the standard is a little too strict, here.

On Sep 30, 2011, at 12:29 PM, Andrew Sutton wrote:

Well, two anyways: == and !=. Given that the standard doesn't allow those on singular-valued iterators, you're right. I think the standard is a little too strict, here.

The underlying values that would need to be compared are potentially "trap" values (c.f. C++99/6.2.6/5). Present commodity hardware typically leads toward different representation requirements for explicitly capturing things like the existance of uninitialized data, resulting in runtime distinctions between normal and debug iterators, for example. However, there has existed (and may still, or may again in the future) hardware implementations which provided direct support for this sort of thing, potentially giving one improved error checking directly by, for example, producing a hardware exception any time a trap value is read. This sort of thing might even be accomplished with present commodity hardware, by doing things like fiddling with parity bits. The standard even alludes to such an approach; see C++99 footnote 44. I would guess that the standard is written the way it is in the area under discussion specifically to support various error checking approaches such as these, and disagree that the standard is too strict in this area.

The underlying values that would need to be compared are potentially "trap" values (c.f. C++99/6.2.6/5).

Ah... That's very informative. I don't have a C standard on hand. Thanks.

Nathan Ridge wrote:

I would suggest making your case about the default constructibility of forward iterators at comp.std.c++. If you gain consensus there that this requirement is indeed misguided, then your request will carry more weight here.

Greater minds than mine did and failed (by being ignored); who am I to confront such a valiant enemy? My only hope is to smuggle common sense under the radar ;-) Chris

2011/9/29 Krzysztof Czainski <1czajnik@gmail.com>

I disagree. I think requiring default-constructed iterstors to be singular would make plain old pointers not meet the requirements. For example: vector<int>::iterator a; // (1) vector<int>::iterator b = a; // (2)

Correct me if I'm wrong: line (1) is legal, and the value of a may be singular, or a may be uninitialized. Therefore line (2) is undefined behavior.

However, if we change the example a bit to make a value-initialized: vector<int>::iterator a = vector<int>::iterator(); // (3) vector<int>::iterator b = a; // (4)

In C++11 singular means what you call uninitialized. iterator.requirements.general p5 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. [ Note: This guarantee is not offered for default initialization, although the distinction only matters for types with trivial default constructors such as pointers or aggregates holding pointers. — end note ] In these cases the singular value is overwritten the same way as any other value. Dereferenceable values are always non-singular. Roman Perepelitsa.