Re: Iterator implementation questions: copy constructor and postfix increment
On Sep 5, 10:32 pm, Scott Gifford <sgiff...@suspectclass.com> wrote:
I'm working on an providing an iterator interface to a database. The
basic thing I'm trying to accomplish is to have my iterator read rows
from the database and return constructed objects. My goal here is to
abstract away the database part, so that in the future these objects
could be constructed from a data source on disk, across the network,
etc. The interface I'm after is similar to the standard iterator
interface for an "input iterator":
DataSource source;
for(DataSource::iterator iter = source.findAll(); iter++; iter !==
DataSource::end()) {
/* ... */
}
The problem I'm running into is that this idiom requires that the
iterator be constructed in findAll(), then copied into a local
variable with the copy constructor. My constructor creates a database
cursor object to read rows, so my copy constructor needs to make a
copy of that cursor. However my database driver won't allow me to
copy the cursor object, or even to create a new cursor object before
the first cursor is destroyed.
In practice, this means that you can only implement an input
iterator; even a forward iterator is impossible, since it would
require being able to copy the iterator, advance the original,
and then use the copy to continue from where the iterator was
when it was copied.
I'm not sure just how useful this is. The functionality of most
of the algorithms which accept input iterators (and a lot of
those which require a higher order of iterators as well) is
subsumed by the data base.
If you do want an STL-like iterator, I think your model should
be istream_iterator. With a little work, you should even be
able to make it a template:
std::vector< RowType > dest(
(DataBaseIterator< DataSource, RowType > iter( source )),
(DataBaseIterator< DataSource, RowType >() ) ;
The solution I'm currently using is to store the cursor object in a
pointer, then have a copy constructor which takes over ownership of
the cursor, setting it to NULL in the copied object so it won't be
destoyed in the destructor. This basically works, but seems very
kludgey, and has some issues I'll address in another post,
It's not really guaranteed to work, although it might most of
the time. This is one case where reference counting is
appropriate: your iterator just contains a boost::shared_ptr to
the actual, non-copiable iterator (with the cursor, etc.), and
forward the dereference and incrementation requests to it. For
the comparison, a simple implementation trick here is to set the
pointer to null when you reach the end (effectively destructing
the real iterator). Then the operator== function becomes
simply:
bool
DataBaseIterator::operator==(
DataBaseIterator const& other ) const
{
return myImpl == other.myImpl ;
}
I'm having a similar problem implementing postfix increment
(operator++(int)). I basically need to return a copy of the iterator
at the previous position in the database, but again I can't copy the
database cursor or construct a new cursor because of driver
limitations.
Using the above technique, you simply use the standard
implementation for postfix increment.
These seem like they would be common problems. Are there common
solutions to them? Can anybody point me to a good reference for
creating iterator interfaces?
You should probably have a look at the Boost iterator
components. The STL iterator requirements can be tricky at
times, and the Boost wrappers allow you to write simply the
behavioral parts, and not worry about all of the boiler plate.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34