Christian Engström <christian.engstrom@glindra.org> writes:
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.
Not really; it just uses the term "iterator" 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.
Whether the problems are fatal or not clearly depends on how many caveats you're willing to tolerate.
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
The flaws I pointed out are fatal from my point of view.
, so at least for the moment, I think that your dismissive tone is uncalled for.
I tried to help you improve the component; you dismissed my suggestion that you use indirect_iterator.
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",
You clearly don't think any of my technical objections are substantive. I am done looking for new ways to object.
I don't see why I should have to accept being called a troll just for suggesting it.
I didn't call you a troll. I honestly wondered if that was happening to me.
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?
No. I don't know what gave you that idea. It may or may not be true for existing implementations of the algorithms, but that's not the same question as whether "the algorithms work with proxy_iterators".
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.
Not if they make the allowed assumption that p->x and (*p).x have corresponding meanings.
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.
No I am not.
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.
OK, I'm done discussing this, so we can see if anyone else says they're interested. <snip>
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.)
You can "solve" any arbitrarily bad problem with any component by documenting the limitation that you can't use it that way.
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.
Suggestion: ask yourself why this objection is an implementation detail, while the inability to "proxy-ize" a pointer is not. Both are soluble problems.
Why you wouldn't just build a conforming iterator the easy way is beyond me.
Because the traditional container interfaces
I wasn't talking about container interfaces. I was talking about iterators.
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.
You obviously haven't looked carefully at indirect_iterator. If I didn't think these capabilities were valuable, I wouldn't have written it. In fact, it was the original motivation for the whole iterator adaptors library. <snip>
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.
I don't know what I did to make you think I was hostile, but whatever it was, I apologize. And that's really the only reason I took the time to respond to your post.
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.
I wondered whether I was being trolled because I found myself compulsively wasting lots of time (time I can't afford to spend) trying to convince you of various things I consider obvious, and making no progress. I began to think someone was just yanking my chain. Cheers, and good luck with your design. -- Dave Abrahams Boost Consulting www.boost-consulting.com