Re: const question

From: Anthony Borla (ajborla_at_bigpond.com)
Date: 03/23/05 

Date: Tue, 22 Mar 2005 23:39:48 GMT

"Alf P. Steinbach" <alfps@start.no> wrote in message
news:42409422.136634828@news.individual.net...
> * Anthony Borla:
> >
> > "Mark P" <not@my.real.email> wrote in message
> > news:yK_%d.414$FN4.101@newssvr21.news.prodigy.com...
> > > I'm running into some issues with const correctness and hoping
> > > for a little clarity. Basically I have a class C which contains an
> > > STL multiset s. Within C I have a member function f() which I
> > > have declared const. In f, I obtain an interator into s via s.begin()
> > > and, on at least one compiler, this seems to give me a const_iterator.
> > > This seems overly defensive and causes me problems elsewhere.
> > >
> > > Is this supposed to happen (the SGI reference even seems to
> > > suggest that iterator and const_iterator should have the same type)
> > > and is there an way to cast away the const-ness of such an iterator?
> > >
> > Make your container instance 'mutable'. Example:
> > ...
> > mutable std::set<int, std::less<int> > mySet;
> > ...
>
> I'd advice against that. Mark's description of the case
> means that const iterator is correct, and making the set
> mutable would probably be worse than simply removing
> 'const' everywhere.
>

I don't agree. Removing 'const' on all affected member functions really
constitutes a class interface alteration [this could be asking for trouble]
whereas making a [presumably] 'private' data member 'mutable' allows those
'const' member functions to mutate *it* [but no other data members]. As long
as any such object state changes are quarantined, and don't affect clients,
I don't see why it should be a problem.

I think, also, it is a cleaner solution than trying to cast away constness
[of an iterator which I don't think can be done]. Put simply, if you want a
non-const iterator you should ask for one, and not try to subvert the
compiler into giving you one.

>
> The problems lie, as Mark writes, "elsewhere", and without
> any description of that no advice can be given.
>

Yes, I agree: lack of context means specific advice cannot be given. I
responded in a general way offering a solution that would allow use of a
non-const iterator in a 'const' member function.

Cheers,

Anthony Borla

Relevant Pages

  • Re: const question
    ... >> I'd advice against that. ... My const function is to ... There the const iterator ... it seems to me that if a member function is returning a non-const ...
    (alt.comp.lang.learn.c-cpp)
  • Re: const question
    ... > I'd advice against that. ... > than simply removing 'const' everywhere. ... There the const iterator becomes problematic. ... The problem as I understand it is that a const function won't let me ...
    (alt.comp.lang.learn.c-cpp)
  • Re: non-sorted map?
    ... A classic abuse of inheritance. ... The vector class really doesn't have that many member functions, ... The signature of this function is wrong (should be const std::string&) ...
    (comp.lang.cpp)
  • Re: mutable data structures
    ... > Chris Croughton schrieb: ... >> member functions which operate on a 'const' object but which need to ... If it's modifiable it can't be in write-protected memory, ...
    (comp.lang.c)
  • Re: const question [C++]
    ... Mark P wrote in message ... ... >> than simply removing 'const' everywhere. ... There the const iterator becomes problematic. ... >The problem as I understand it is that a const function won't let me ...
    (alt.comp.lang.learn.c-cpp)