Why Strings as Classes? [C++ iterator]

[Fawzi Mohamed]

On 2008-08-28 13:31:26 +0200, "David Wilson" <dw at botanicus.net> said:

> 2008/8/28 Fawzi Mohamed <fmohamed at mac.com>:
>> On 2008-08-28 00:24:50 +0200, Dee Girl <deegirl at noreply.com> said:
>> 
>>> Derek Parnell Wrote:
>>> 
>>>> On Wed, 27 Aug 2008 17:08:47 -0400, Nick Sabalausky wrote:
>>>> 
>>>>> The way I see it, encapsulation is all about the black box idea. And the
>>>>> only things you can see from outside the black box are the inputs and
>>>>> outputs.
>>>> 
>>>> Well said.
>>> 
>>> I am sorry I will say my opinion. This sounds good but is simplistic.
>>> Black box is good in principle. But it assume you found right interface for
>>> the black box. If you define bad interface you have a bad black box. Also
>>> please remember that iterator is black box also. But it defines right
>>> interface.
>> 
>> I agree with the meaning, but I disagree with the example.
>> I think that iterators are an example of bad interface, as also others
>> brought up the iterator as good example I though that I should say
>> something.
>> 
>> An iterator should be like a generator, have a method next, and one at_end
>> or something similar packaged (and maybe prev() and at_start() if it can
>> also go back) in a single struct, furthermore it should work seamlessly with
>> a kind of for_each(x;iterator) construct.
>> 
>> Instead C++ choose to have begin & end iterators, simply because with that
>> construct it is trivial for the compiler to optimize it for arrays, and you
>> can use pointers as iterators without a cast/constructor.
>> 
>> This means a worse interface for 99% of the uses, apart form arrays and
>> vectors I think one is better off without end iterator, and even when this
>> is not the case writing something like for_each(x;FromTo(a,b)), with FromTo
>> constructing a generator is (I think) better than
>> for(i=t.begin();i!=t.end();++t), and the implementation of an a generator
>> itself is easier (no ==,!=,increment, decrement(pre/post),... for
>> performance reasons)
> 
> It is worse in simple "for each element" uses, but one of the cooler
> things about C++ iterators is exactly that they are exchangeable for
> any pointer-like object, and that it's trivial to iterate over a
> subset of a container. Emulating pointers means that in some ways,
> once you grok how they work, they are more trivial than e.g. Python or
> D since there is no further specialised syntax beyond "*", "++", and
> maybe "--".
> 
> I love the concise D and Python syntaxes, just playing devil's advocate 
> here. :)

I appreciate it, and in fact a general iterator is more powerful than 
the simple interface I gave.
And the iterator concept *is* a powerful one.
The thing is a general random iterator can also be implemented as a 
single structure (not a pair, start and end), you just need more 
methods (and a comparison operator if you want to compare iterators).
Indeed you have a little overhead for arrays and vectors (you also 
store the end), but I think that in most cases the real difference is 
0, and a nicer handling of the most common case more than offsets all 
these considerations (and it is also nicer to implement a new iterator).

> 
>> As I believe that the optimizations to make the better interface be as
>> efficient as the iterator one are perfectly doable (some work, yes, but not
>> extremely much so), I see no good reason for C++ design.
>> 
>> Fawzi