Re: container cursor type cannot be tagged

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:c8utnmednhss.tg5692sifke0$.dlg@40tude.net...
> On Thu, 28 Aug 2014 15:25:59 -0500, Randy Brukardt wrote:
>
>> If it was me, I'd put a container parameter on every operation (which 
>> would
>> be the prefix), and cursors would work soley like array indexes.
>
> Huh, remember our discussion about cursor/iterator being a bad idea?

No sorry, I don't. But I do know that I was against that model of cursors 
from the beginning; I just wasn't able to explain why well enough to 
convince anyone else.

> That is another of multiple reasons why. Cursor tend to become a full 
> class
> with descendants and primitive operations which ends up in multiple
> dispatch, for whatever reason not available. An index almost always can be
> a "final" type which makes everything a lot easier.

But please note that iterators are a very different case. They necessarily 
encapsulate some state and that state is intimately tied to the container --  
it doesn't make sense to separate them.

Also note that a cursor would always need to include some indication of the 
container it belongs to, in order that the library can prevent using the 
cursor with the wrong container. Since these are almost always going to be 
implemented as wrapped access types, using one with the wrong container 
would lead to havoc. (And one of the most important properties of the Ada 
containers is that they never cause more havoc than a bare, fully checked 
array could.)

The problem comes from using the cursor separately from the container, not 
so much from the fact that cursors know their containers. (The indication 
does not need to be a pointer in this model, a serial number would be 
enough, so just because there is an indication doesn't mean that one could 
use the cursor without the container.)

                                                        Randy.