dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jan 17, 2011 at 10:17:59AM +0100, Andre Massing wrote:
> Den 15.01.11 00.08, skrev Anders Logg:
> >On Sat, Jan 15, 2011 at 12:06:54AM +0100, Anders Logg wrote:
> >>On Fri, Jan 14, 2011 at 04:47:59PM +0100, Andre Massing wrote:
> >>>Hi!
> >>>
> >>>Since we talk so much about constantness in another post :),
> >>>I am just wondering why the operator* (and related operator)
> >>>in Iterator classes sometimes returns a const reference to an entity like
> >>>inline const Facet&  operator*() { return *operator->(); }
> >>>and sometimes not as in
> >>>inline Cell&  operator*() { return *operator->(); }
> >>>
> >>>Should that not be consistent and even better should not both
> >>>version be provided, as in
> >>>inline const Facet&  operator*() const { return *operator->(); }
> >>>and				(^^^ there should be a second const)
> >>>inline Facet&  operator*() { return *operator->(); }
> >>>?
> >
> >I think the problem is that we haven't differentiated between const
> >and non-const iterators as it's done in STL.
> >
> >Wouldn't we need to have two different iterators?
> >
> >   CellIterator and
> >   ConstCellIterator etc
> >
> >?
>
> Yes, this would be a way to go, and even more explicit, since you
> could garantee constantness, whereas having both the const and non
> const version within one class would give you only the possibility
> to use certain operations within a function you passed the object as
> const reference to. In my example I have an iterator but I only want
> to use const member function such as index() of the entity. Since I
> do that via operator-> I loose constantness then and adding
> inline const Facet&  operator*() const
> would remedy this. Not sure whether this is worth to introduce
> /split iterators into to classes. I would probably go for adding
> const version.

If you want, feel free to send a patch for adding the missing const
versions. :-)

--
Anders