Why Strings as Classes? [C++ iterator]
Denis Koroskin
2korden at gmail.com
Thu Aug 28 07:39:52 PDT 2008
On Thu, 28 Aug 2008 13:47:22 +0400, Fawzi Mohamed <fmohamed at mac.com> wrote:
> 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)
>
> 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
>
Agreed. I usually write iterators that support "T geValue()", "void
moveNext()" and "bool isValid()" operations.
Also I don't like Java-style "T getNext()" iterator idiom and think it
should be split into two methods: getValue() and moveNext().
More information about the Digitalmars-d
mailing list