从 const 成员函数调用非常量成员函数
我想知道是否可以从 const 成员函数调用非常量成员函数。在下面的示例中,首先给出了编译器错误。我明白为什么会出现错误,我想知道是否有办法解决它。
class Foo
{
const int& First() const
{
return Second();
}
int& Second()
{
return m_bar;
}
int m_bar;
}
我真的不想讨论这样做是否明智,我很好奇它是否可能。
I would like to know if its possible to call a non-const member function from a const member function. In the example below First gives a compiler error. I understand why it gives an error, I would like to know if there is a way to work around it.
class Foo
{
const int& First() const
{
return Second();
}
int& Second()
{
return m_bar;
}
int m_bar;
}
I don't really want to discuss the wisdom of doing this, I'm curious if its even possible.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
然后,静静地哭。
Then cry, quietly.
这是可能:
我不推荐这样做;它丑陋且危险(任何使用
const_cast
都是危险的)。最好将尽可能多的常用功能转移到辅助函数中,然后让 const 和非常量成员函数各自执行尽可能少的工作。
对于像这样的简单访问器,从两个函数
返回 m_bar;
与从另一个函数调用一个函数一样容易。It is possible:
I wouldn't recommend this; it's ugly and dangerous (any use of
const_cast
is dangerous).It's better to move as much common functionality as you can into helper functions, then have your const and non-const member functions each do as little work as they need to.
In the case of a simple accessor like this, it's just as easy to
return m_bar;
from both of the functions as it is to call one function from the other.根据
const
的定义,函数不应该修改对象的状态。但如果它调用另一个非常量成员,则对象的状态可能会改变,因此是不允许的。我知道你说过你不想听到这个,但我认为这对于其他遇到这个问题的人来说很重要。
By the definition of
const
, a function should not modify the state of an object. But if it calls another non-const member, the object's state might get changed, so it's disallowed.I know you said you didn't want to hear about this, but I think it's important for others that happen upon the question.
const 成员方法的限制来自编译时。如果你能欺骗编译器,那么是的。
这实际上废除了const成员函数的目的,因此在设计新类时最好不要这样做。知道有一种方法可以做到这一点并没有什么坏处,特别是它可以用作这些旧类的解决方法,这些旧类在 const 成员函数的概念上没有很好地设计。
The restriction of const member methods are came from compile time. If you can fool the compiler, then yes.
This actually abolishes the purpose of const member function, so it is better not to do it when design a new class. It is no harm to know that there is a way to do it,especially it can be used as an work-around on these old class that was not well designed on the concept of const member function.
重载
const
:您可以添加此方法并保留原始的非常量版本。
Overload on
const
:You can add this method and keep the original non-const version.
迭代器在这方面是类似的并且进行了有趣的研究。
const 迭代器通常是“非 const”迭代器的基础,并且您经常会发现 const_cast<>() 或 C 样式转换用于从基类中丢弃 const,并在子类中使用访问器。
编辑:
评论是
这通常是错误的继承结构(如果你说我认为你是什么),原因是孩子不应该比父母受到更少的限制。
假设您有某种算法采用 zip 迭代器,将 const 迭代器传递给非 const 是否合适?
如果您有一个 const 容器,则只能要求它提供一个 const 迭代器,但是 const 迭代器是从迭代器派生的,因此您只需使用父级上的功能即可进行非 const 访问。
以下是遵循传统 stl 模型的建议继承的快速概述
iterators are similar in this and make an interesting study.
const iterators are often the base for 'non const' iterators, and you will often find
const_cast<>()
or C style casts used to discard const from the base class with accessors in the child.Edit:
Comment was
This would generally be the wrong inheritence structure (if your saying what I think you are), the reason being that children should not be less restrictive than parents.
say you had some algorithm taking your zip iterator, would it be appropriate to pass a const iterator to a non const ?
if you had a const container, could only ask it for a const iterator, but then the const iterator is derived from an iterator so you just use the features on the parent to have non const access.
Here is a quick outline of suggested inheritence following the traditional stl model
我发现自己试图调用一个继承的非常量成员函数,但由于我使用的 API,它实际上是 const。最后我选择了一个不同的解决方案:重新协商 API,以便我继承的函数是正确的 const。
并不总是可以协商对其他函数的更改,但在可能的情况下这样做似乎比需要使用 const_cast 更干净、更好,并且它也有利于其他用户。
I found myself trying to call a non-const member function that was inherited, but was actually const because of the API I was using. Finally I settled on a different solution: re-negotiate the API so that the function I inherit is properly const.
It won't always be possible to negotiate changes to others' functions, but doing so when possible seems cleaner and nicer than needing to use const_cast and it benefits other users as well.