[lug] OT: C++ question, const_iterator design

[D. Stimits]

Tkil wrote:

> >>>>>"DS" == D Stimits  writes:
>
>
> DS> To make a long story short, someone pointed out that the object I
> DS> was using had to be const, which I did not believe was the case;
> DS> however, after looking at it for a week, I found he was right. So
> DS> the whole question was pointless, the const version of begin() was
> DS> only called because the object was const, and had nothing to do
> DS> with operator= overloads, nor method signatures.
>
> Hm.  Well, as much as I enjoy being right (hoo boy, do I enjoy it), I
> think that you might be missing the forest for the trees here.

Since I'm building this template for myself, I have the option of doing 
it any way I like. Because of this, I only enjoy it if I don't have to 
compromise on anything (which might happen if there is a drop-dead 
date). Little details that irratate me I can allow to stop progress 
until I figure it out, which is mainly what this was all about.

>
> Your goal is to be able to do a simple assignment from a (non-const)
> ".begin()" call into a const_iterator.  To quote Denis Leary: "Where's
> the problem"?

There is no problem now that I found that the object itself was const. 
Seeing the separate const and non-const qualifier versions, and missing 
the const object, seemed impossible...yet it looked like it was doing it 
(calling the const or non-const version, rather than doing a 
conversion). Now I know, the itch has been scratched, and I can continue on.

>
> A const_iterator has a stronger promise than a simple iterator; as
> such, implementing a const_iterator as a dumbed-down iterator for a
> given container makes perfect sense.

I'm very aware of iterators, I've been a big template user (especially 
STL) for a long time...it is my preferred way to deal with data 
structures/containers.

>
> Which gets back to something you mentioned earlier: there's might not
> be an automatic conversion, but if you build your const_iterator
> constructor so that it can take a non-const element, you should be
> fine.

I chose the method of deriving iterator from const_iterator. I may go 
back later and alter things, but for now I'm not threading it or 
requiring performance optimizations, so this is fine.
...

>
>
> Without being able to fully parse all the underscored grotesqueness of
> that code, I'm relying on the comment to infer that this magic allows
> any normal (non-const) iterator to be promoted to a const_iterator
> (which, as explained previously, is perfectly reasonable, and ought to
> be basically automatic).

That was part of the problem, I hate the conventions they use in the STL 
code for naming...comments becoming more meaningful than the code makes 
it hard to use it for an example.
...

So all is well, and I'm using iterator derived from const_iterator, 
which is very simple.

D. Stimits, stimits AT attbi DOT com