Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #12540

Re: would you consider this function const?

From Victor Bazarov <v.bazarov@comcast.invalid>
Newsgroups comp.lang.c++
Subject Re: would you consider this function const?
Date 2011-12-15 09:11 -0500
Organization A noiseless patient Spider
Message-ID <jccv7e$8if$1@dont-email.me> (permalink)
References <jcaem0$gac$1@speranza.aioe.org> <jcai9t$ee9$1@dont-email.me> <jccrkj$uec$1@speranza.aioe.org> <jccs9c$ovg$1@dont-email.me> <jcctkm$i7j$1@speranza.aioe.org>

Show all headers | View raw


On 12/15/2011 8:44 AM, john wrote:
> On 12/15/2011 8:21 AM, Victor Bazarov wrote:
>> On 12/15/2011 8:10 AM, john wrote:
>>> On 12/14/2011 11:19 AM, Victor Bazarov wrote:
>>>> On 12/14/2011 10:17 AM, john wrote:
>>> snipped ....
>>>>
>>>> IME 'const_cast' is good only for one thing: to add const where one
>>>> needs an overload resolution to go a particular way. Any other use of
>>>> 'const_cast' is an instance of abuse. That's just IME, of course.
>>>
>>> Could you give an example of the use of const_cast in this case? I do
>>> not quite follow what you are saying.
>>
>> This is from memory, I don't have a good working example right now...
>> When you want to call a const member function for a non-const object,
>> and a non-const member function also exists and overloads the const one,
>> the non-const would be picked - it's a better match. That's where you
>> could force the compiler into picking the one you want:
>>
>> #include <iostream>
>> #include <ostream>
>> struct foo {
>> void bar() const { std::cout << "const bar\n"; }
>> void bar() { std::cout << "regular bar\n"; }
>> };
>>
>> int main() {
>> // ...
>> foo f;
>> f.bar(); // non const is picked.
>> const_cast<const foo&>(f).bar(); // const version
>> }
>>
>> ..something like that, anyway. It also happens in the context of a
>> non-const member that is [partially] implemented in terms of a const
>> member function, for instance. This is artificial, of course:
>>
>> struct foo {
>> void bar() const {
>> std::cout << "const bar\n"; }
>> void bar() {
>> std::cout << "non-";
>> const_cast<const foo*>(this)->bar(); }
>> };
>>
>> HTH
>>
>>> [..]
>>
>> V
>
> I see. That makes sense.
>
> One of the issues that spurred this question (related to my func1 in the
> original post) is the following. I have a 3D mesh composed of
> Volumes/Faces/Edges/Vertices. So, I have a Volume, Face, Edge, and
> Vertex class, each derived from a base Topology class. The mesh is
> consistent, so given a particular instance of one of the classes, there
> are functions that return geometry information such as connectivity. In
> particular, each class has a virtual function (declared as pure virtual
> at the base Topology class)
>
> virtual void GetVolumes(std::set<Volume*> volumes);

That doesn't look right.  Did you lose the ampersand before the argument 
name?

>
> that returns a list of pointers to the volumes associated with the
> entity. I want to make this function 'const' since it does not change
> the element. For a Face, Edge, and Vertex, this poses no problem.
> However, for a volume instance, the function should return a pointer to
> just itself, so if GetVolumes is const, then I have
>
> void Volume::GetVolumes(std::set<Volume*> volumes) const
> {
> volumes.clear();
> volumes.insert(const_cast<Volume*>(this));
> }
>
> I do not see how to have the GetVolumes function const without the use
> of const_cast in the Volume::GetVolumes function. Is there a more
> intelligent way to get the same result?

What happens if you change the type of the argument to

   std::set<const Volume*>

?  If it's a set of constant volumes, that's what the type should 
express.  If you find it difficult to type, use a typedef *or* introduce 
some kind of 'Volume proxy' and keep that instead of the pointer to Volume.

V
-- 
I do not respond to top-posted replies, please don't ask

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

would you consider this function const? john <gh14tq5@yahoo.com> - 2011-12-14 10:17 -0500
  Re: would you consider this function const? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-14 11:19 -0500
    Re: would you consider this function const? john <gh14tq5@yahoo.com> - 2011-12-15 08:10 -0500
      Re: would you consider this function const? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-15 08:21 -0500
        Re: would you consider this function const? john <gh14tq5@yahoo.com> - 2011-12-15 08:44 -0500
          Re: would you consider this function const? Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 14:07 +0000
            Re: would you consider this function const? Leigh Johnston <leigh@i42.co.uk> - 2011-12-15 14:14 +0000
          Re: would you consider this function const? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-15 09:11 -0500
            Re: would you consider this function const? john <gh14tq5@yahoo.com> - 2011-12-15 09:30 -0500
              Re: would you consider this function const? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-15 10:06 -0500
                Re: would you consider this function const? john <gh14tq5@yahoo.com> - 2011-12-15 12:42 -0500
                Re: would you consider this function const? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-12-15 13:32 -0500
    Re: would you consider this function const? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-12-19 18:16 +0000
      Re: would you consider this function const? Tobias Müller <troplin@bluewin.ch> - 2011-12-19 19:05 +0000
        Re: would you consider this function const? Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 14:36 -0800
          Re: would you consider this function const? Tobias Müller <troplin@bluewin.ch> - 2011-12-20 06:28 +0000
            Re: would you consider this function const? Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 23:48 -0800

csiph-web