From: Christian Engström (christian.engstrom_at_[hidden])
Date: 2004-02-22 15:44:13
> 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_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
> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk