iterator with special case implementation - c++

Question

Is there a way to build an iterator class that has two implementations : a general implementation for a container containing any number of elements and a special case (very fast) implementation when the container contains a single element wihtout using virtual functions and dynamic polymorphism ?
For the moment, I have :
struct Container {
struct FastIterator;
struct SlowIterator;
void add(...) { ... }
SlowIterator begin_slow() { ... }
FastIterator begin_fast() { ... }
};
instead I would like to have :
struct Container {
struct Iterator;
void add(...) { ... }
Iterator begin() { // select between fast and slow based on the contents of the container }
};
so that :
void f() {
Container c;
c.add(...);
Container::Iterator it = c.begin(); // uses FastIterator hidden by the Iterator type
}
void f2() {
Container c;
c.add(...);
c.add(...);
Container::Iterator it = c.begin(); // use SlowIterator hidden by the iterator type
}
Of course, the obvious way would be to use virtual function or a delegate in the Iterator implementation to switch from one case to the other, however I tested that this slows down a lot the iteration compared to directly using the Slow/Fast iterators.
Since all the information to decide which implementation to use is available during the call to begin(), I would think there is a way to use some kind of compile time polymorphism/trick to avoid any kind of indirection.
Also, I really don't want the user to have to decide if it should call begin_fast() or begin_slow(), this should be automatically handled and hidden by the Iterator class.
Is there a way ?
Thanks

Answer 1

Sure.
Your container becomes a std::variant of two different states, the "single element" state and the "many element" state (and maybe the "zero element" state).
The member function add can convert the zero or single-element container into a single or multi-element function. Similarly, a remove might do the opposite in some cases.
The variant itself doesn't have a begin or end. Instead, users must std::visit it with a function object that can accept either.
template<class T>
struct Container:
std::variant<std::array<T,0>, std::array<T,1>, std::vector<T>>
{
void add(T t) {
std::visit(
overload(
[&](std::array<T,0>& self) {
*this = std::array<T,1>{{std::move(t)}};
},
[&](std::array<T,1>& self) {
std::array<T,1> tmp = std::move(self);
*this = std::vector<T>{tmp[0], std::move(t)};
},
[&](std::vector<T>& self) {
self.push_back( std::move(t) );
}
),
*this
);
}
};
boost has a variant that works similarly. overload is merely
struct tag {};
template<class...Fs>
struct overload_t {overload_t(tag){}};
template<class F0, class F1, class...Fs>
struct overload_t: overload_t<F0>, overload_t<F1, Fs...> {
using overload_t<F0>::operator();
using overload_t<F1, Fs...>::operator();
template<class A0, class A1, class...Args>
overload_t( tag, A0&&a0, A1&&a1, Args&&...args ):
overload_t<F0>( tag{}, std::forward<A0>(a0)),
overload_t<F1, Fs...>(tag{}, std::forward<A1>(a1), std::forward<Args>(args)...)
{}
};
template<class F>
struct overload_t:F {
using F::operator();
template<class A>
overload_t( tag, A&& a ):F(std::forward<A>(a)){}
};
template<class...Fs>
overload_t<std::decay_t<Fs>...> overload(Fs&&...fs) {
return {tag{}, std::forward<Fs>(fs)...};
}
overload is ridiculously easier in c++17:
template<class...Fs>
struct overload:Fs{
using Fs::operator();
};
template<class...Fs>
overload->overload<Fs...>;
and use {} instead of ().
Use of this in c++14 looks like:
Container<int> bob = get_container();
std::visit( [](auto&& bob){
for (int x:bob) {
std::cout << x << "\n";
}
}, bob );
and for the 0 and 1 case, the size of the loop will be known exactly to the compiler.
In c++11 you'll have to write an external template function object instead of an inline lambda.
You could move the variant part out of the Container and into what begin returns (inside the iterator), but that would require a complex branching iterator implementation or for callers to visit on the iterator. And as the begin/end iterator types are probably tied, you'd want to return a range anyhow so the visit makes sense. And that gets you half way back to the Container solution anyhow.
You could also implement this outside of variant, but as a general rule earlier operations on a variable cannot change the later type in the same scope of code. It can be used to dispatch on a callable object passed in "continuation passing style", where both implementations will be compiled but one chosen at runtime (via branch). It may be possible for a compiler to realize which branch the visit will go down and dead-code eliminate the other, but the other branch still needs to be valid code.
If you want fully dynamicly typed objects, you are going to lose a factor of 2 to 10 speed at least (which is what languages who support this do), which is hard to recover by iteration efficiency on one element loops. That would be related to storing the variant-equivalent (maybe a virtual interface or whatever) in the iterator returned and making it complexly handle the branch at runtime. As your goal is performance, this isn't practical.
In theory, C++ could have the ability to change the type of variables based on operations on them. Ie, a theoretical language in which
Container c;
is of type "empty container", then:
c.add(foo);
now c changes static type to "single element container", then
c.add(foo);
and c changes static type to "multi-element container".
But that isn't the C++ type model. You can emulate it like above (at runtime), but it isn't the same.