|
|
Glas :Re: [glas] dense and sparse vectors |
From: Theodore Papadopoulo (Theodore.Papadopoulo_at_[hidden])
Date: 2005-08-16 10:28:04
On Sun, 2005-08-14 at 22:38 +0200, Toon Knapen wrote:
> Theodore Papadopoulo wrote:
>
> > Here is a very crude implementation of what I was thinking (just for
> nz
> > iterators and only for structured_vector).
>
>
> I just had a look at your patch and here's my feedback on it:
>
>
> > - Expandable iterators (create your iterator, your tag and this is
> it...
> > at least if the container class provides enought information for
> you
> > to implement your iterator).
>
>
> Indeed it is ... but note more exandable as having a 'template <class
> T>
> begin()' member-function. Actually finally the nz_iterator is calling
> this member-function. So IIUC the added-value of your approach is the
> automatic conversion from the return-value of the 'begin()' member to
> the desired iterator-type. This is indeed nice but also has the
> drawback
> of increasing the call-overhead.
I doubt that the call overhead is high if there is one at all. Any good
compiler should inline all of this and generate very similar code in the
end. The actual complexity is only a slightly more complicated
implementation IMHO (and eventually slightly more complicated error
messages).
> > Can be used with the std stuff (sorting elements, finding elements,
> > for_each,....). Well, if the iterators obey the std rules (which is
> > not yet the case with this sample code).
>
>
> But one can't call std::sort(v.begin(),v.end())' for instance because
> the sort function is passed two struct's in that case ?
Right and indeed the std lib seems to have tried to avoid assuming the
existence of the begin() and end() method as much as possible (but I
never audited the library to see how much it depends on the existence of
these methods). I might work when specitying the iterator type:
std::sort<iter>(v.begin(),v.end()) thought.
What I know is that if some class depends on a container, an iterator
type and the begin and end functions, then this scheme makes it usable.
How often in practise this happens, I do not know.
> > Let me know what you think of this idea... if it seems OK, then I'll
> try
> > to adapt more containers/iterators and eventually reorganise some of
> the
> > code).
>
> You inspired the idea of having 'begin(nz)' and 'begin(all)'. Again
> IIUC your solution is build on top of this. However I'm not convinced
> yet that the difference in notation (due to the implicit conversion)
> is worth the additional overhead.
Again, I do not think there is some overhead. I agree that this is more
some ease of use (not repeating types) and notation. I once did exactly
the begin(nz) stuff and moved to this new scheme because my (few) users
were complaining about the redundancy..