David Abrahams wrote: I seriously have to wonder if I'm being trolled, here...
No, you're not being trolled, you're being presented with a design idea that is new and uses the C++ language in unconventional ways. I know that the design violates many of the rules of thumb that C++ programmers (quite sensibly) normally choose to follow, which makes it very easy to fall into the trap of rejecting it outright, without actually taking the time to evaluate it properly to see if it is in fact consistent after all. I'll immediately concede that the design *is* very bold and unusual, and that it could well be the case that it does in fact contain some fatal inconsistency that invalidates it. But at least so far, I note that neither you nor anybody else has been able to point at such a flaw in the design, so at least for the moment, I think that your dismissive tone is uncalled for. I have in good faith presented an idea that has an obvious bearing on library design if it does turn out to be solid. It is yet too early to tell if this is the case or not, but until you or somebody else has come up with a more substantive objection than "I don't think many people will like it", I don't see why I should have to accept being called a troll just for suggesting it.
Christian Engström <christian.engstrom@glindra.org> writes:
Okay, so a more accurate way of describing the problem would be:
"Due to a glitch in the formal specification for iterators in STL, algorithms are allowed to place semantic restrictions on the -> operator when it exists, even though the algorithm can never acutally use the operator in question, since is not actually required to exist at all.
David Abrahams wrote:
And what about a third-party algorithm that iterates over classes and happens to use operator-> ? That's no bug?
Does this mean that we are now in agreement that all of the STL algorithms will in fact work with proxy_iterator:s, despite your earlier reservations? Regarding other algorithms that iterate over the objects container and use the -> operator, they will work the same with proxy iterators on a proxy_container as they would with ordinary iterators on a direct container --- that's the whole point of the design. So no, that's not a bug.
Are you trying to write a library (if not, this whole discussion is OT), or is this just for yourself?
As stated above, I am trying to present a design idea that I hope might be useful in the context of building general libraries, like the ones in Boost. I am confident that you are not trying to suggest that that kind of discussion is OT on the Boost list, even if you personally happen to dislike the idea as such. Whether it will be just for myself or for others as well depends on whether somebody else will find the idea interesting enough to explore it further. If so, they are free to use the idea as such and/or the files I posted in the Yahoo files section in whatever way they want, including writing a library based on the design and submitting it to Boost. If not, it will just be for myself, and then of course I won't discuss it any further in this forum.
How long do you think this list of exceptions has to to be before the component is of no interest to anyone other than yourself? After you responded to "it's not an iterator" with one caveat, my eyes glazed over (not to mention, "I just did it that way because I don't know how to make it properly according to modern standards"). I'm sure it won't take most people much longer to realize that it's obviously not built "properly according to modern standards" when they see a list of 3 or more subtle/not-so-subtle ways in which it isn't an iterator.
As I very explicitly said in my very first post, I am presenting a design idea for discussion, together with a draft implementation that serves to illustrate that idea. The use of the word "draft" was deliberate, and was intended to convey the message that the implementation did not claim to be ready to be put in production in its current state, but that my primary interest at this point in time was not to examine the various implementation details, but to discuss the validity of the underlying design idea. So far, all of your objections that could not be solved by clarifying the documentation have been related to implementation details, and not the design as such. (Except, of course, your repeated assertion that you don't think many people will be interested in the idea, but I don't really count that as a particularly technical point.) While your observations on the shortcomings of the implementation are valid and true as such, they don't relate to the validity of the design, so unless you have already decided to go ahead and write a production grade implementation (which of course you quite obviously haven't :-) ), they are at the very least somewhat premature at this moment. However, as they are completely valid and quite valuable from an implementation perspective, I am nevertheless grateful to you for taking the time to make them.
It took me about 3 seconds to notice that your iterator is broken in another way: it assumes the operators on the underlying iterators are implemented as member functions and not free functions.
Good point, but again it relates to the draft implementation, and not to the underlying design.
Why you wouldn't just build a conforming iterator the easy way is beyond me.
Because the traditional container interfaces do not offer the convenience of being able to provide the same interface for indirect and direct containers, and to make it possible to switch between them by changing a single typedef. If it turns out to be possible to write a library that allows users to do this, whatever effort went designing the library will be well worth it because of the time such a library would save for its users. This is the same underlying arithmetic that serves as the foundation for any library, including all the libraries that are currently part of Boost. I am very saddened by the hostile tone that I think you have chosen to adopt in this discussion, and quite frankly rather surprised by it, since I know that this is not how you normally prefer to carry yourself on this list. It's just an unusual idea that may or may not be valid, that's all --- it's not an attack on anything or anybody, so there's no need to get upset. If you don't like the idea you don't have to, but I really can't see why this means that you should have accuse me of trolling or question the sincerity of my motives for presenting it on the Boost list. /Christian