In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> Hi,
>
> iterator over the hash set. But that is quite complicated.
Why? the objects are owned by the container, and the container does know
how to iterate over them, so you'd merely need to typedef or wrap that
container's own iterator into your own typename. am I missing some of
your considerations?
>
> The STL-Iterator of my hash set as I have defined it in my wrapper
> class is:
>
> typename __gnu_cxx::hash_set< PointerTemplate, pointerHashFunction,
> pointerEqualityFunction >::iterator
> m_hsitIterator;
put a typedef in front of it, and the caller will have no problem with
knowing it's type definition...
>
> I have tried the following: I have created a position object, that
> stores an integer position number and a boolean bHasNext. The hash set
> object has methods "getBeginPosition()" and "getNext( Position
> position )". The advantage: this concept is very general, since I
> could use a position number for every collection type (and I intend to
> do that for a hash map wrapper class and so on).
currently I'm thinking of generalizing some algorithm for use with
containers which have more elements than does fit into 32-bit. in
such a case (for example with the container being accessed from disc
directly) you would have a problem with adapting your class to the
new container. but I guess this isn't really important for you...
however, recently I also where thinking about the concept of an
iterator: basically every set of numbers could be implemented by
a begin() function and some const_iterator-class. begin() would
only return const_iterator() and the whole work would be done
by that class. only an end()-function would be problematic, since
in most number-sets only the iterator does know when it runs out
of numbers (just think of the set containing all fibonacci-numbers
between 1 and 50). this quite sounds like a similar problem. however,
my approach was to store within the iterator some sort of indicator
which does signal that the iterator is beyond-end, and nothing
will work if that indicator set -- and end() would then return
a constant const_iterator with that indicator. that of course
does require overloading the operator==...
>
> I can use these methods now like that:
>
> CTWTHashPosition position = m_hsHashSet.getBegin();
>
> while (position.bHasNext() )
> {
> CTWTProperty *pProperty = m_hsHashSet.getNext(position );
> ...
> }
but can you then still use stl-algorithms?
>
> Very probably advance() steps through the hash set element by element
> and this will make my method very, very slow for large hash sets. Is
> that true? Is there a better way to advance? Or do you know a better
> concept?
I don't know anything about hash_set, but advance() basically should
make use of random-access if the iterator is a random-access iterator,
and should single-step when it's not. also I do not know much about
oop, and therefore do not understand: why can't you just store the
actual iterator within CTWTHashPosition, how would that break this
encapsulation-thing? when I put a typedef into my class, and I do
remember to repeat a similar typedef in all derived classes, then I
have no problem with virtual functions and stuff -- at least in the
rare occasions where I encountered such a problem...
--
Better send the eMails to netscape.net, as to
evade useless burthening of my provider's /dev/null...
P
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
