----- Mensaje original ----- De: Jonathan Turkanis <technews@kangaroologic.com> Fecha: Jueves, Mayo 12, 2005 10:15 pm Asunto: [boost] Re: [repost][interfaces] would the following work?

JOAQUIN LOPEZ MU?Z wrote:

[Sorry I didn't answer sooner; I'm reviewing a long manuscript]

...

Allow me to repost this, since given the current traffic in the list it could well have passed unnoticed.

Is (the proposed) Boost.Interfaces lib able to handle the following scenario?

template<typename T> interface IIterator { T& operator*()const; ... };

template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... };

...

It is not the issue of specifying an operator as part of the interface> IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that?

This is one of the main motivating examples for introducing operator overloading and self-referential interfaces. Unfortunately, it's not done yet, but it's the first or second thing on my list. The implicit conversion from an iterator of the underlying container shouldn't be difficult. Iterators with operatorsreturning proxies may be a problem. Another issue is that IIterator<T> must clone the underlying iterator; otherwise you will often end up with pointers to deallocated objects.

I'm thinking of using the following syntax for polymorphic container wrappers (stealing from Andrei):

sequence - sequence of anything sequence::of<T> - sequence of T's iterator - any iterator (more or less) iterator::over<T> (or of<T>) - any iterator over T's

Is this container wrapper stuff further elaborated somewhere I can take a look at?

This allows sequence and iterator to be typedefs for template specializationsinvolving allocator policies.

...

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

PS: Just for motivation, I' think this idiom could be taken advantage> of in a possible implementation of a dynamic multi- index container.

Sounds great!

The rationale is, in a multi-index container where indices are added at run-time, some sort of dynamic polymorphism is called for when retrieveing and using the indices, much in the vein of the poly container wrappers. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo