[boost] Re: Proxy --- an indirect container adaptor

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
>>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