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


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

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 10:06 -0500
Organization A noiseless patient Spider
Message-ID <jcd2dn$r0e$1@dont-email.me> (permalink)
References (2 earlier) <jccrkj$uec$1@speranza.aioe.org> <jccs9c$ovg$1@dont-email.me> <jcctkm$i7j$1@speranza.aioe.org> <jccv7e$8if$1@dont-email.me> <jcd09b$umt$1@speranza.aioe.org>

Show all headers | View raw


On 12/15/2011 9:30 AM, john wrote:
>>>
>>> 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?
>>
>
> Yes, it should be
>
> virtual void GetVolumes(std::set<Volume*>& volumes);
>
>
>>>
>>> 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.
>
> I will have to look at whether I can do that or not. My guess is that,
> for the most part, I will need non-const Volume*'s. It's a huge code
> base, so a change like that could ripple to a lot of places.

Well, depending on the domain and the purpose for which the pointers are 
collected, it might be OK to const_cast them like that.  After all, it 
is unlikely that any object of your Volume class is ever created in a 
constant memory, so the 'const' here is just a pretense.  Keep in mind, 
however, that const_cast can be abused.  And don't abuse it.  If you can 
rework your design in such a way that wouldn't call for the use of 
'const_cast' to cast *away* any constness, it could lead to a more 
robust system, methinks.

I wonder (not that you need to explain, just wonder along with me), how 
is Volume and, say, Edge derive from the same class.  What is common 
about them (aside from 'GetVolumes')?  Also, can you have nested 
Volumes?  You know, an egg inside a duck inside a hare hidden in a 
trunk...  Seems like if your answer is 'no', then a Volume cannot derive 
from Topology since you essentially make Topology aware of a type that 
will be derived from it, which is usually a no-no...

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