From: David Abrahams (dave_at_[hidden])
Date: 2004-02-23 20:20:34
Christian Engström <christian.engstrom_at_[hidden]> 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
>>> Christian Engström <christian.engstrom_at_[hidden]> 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
>> 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
> 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
> 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
> 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
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
Cheers, and good luck with your design.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk