想象一下,在C ++中,有两个类名为derived
,另一个名为base
,它们是第一个类的基类。如果我有以下代码,那么首选:
base *b = init_value_here;
const derived *d = static_cast<derived *>(b);
或
base *b = init_value_here;
const derived *d = static_cast<const derived *>(b);
换句话说,最好在不需要时在静态强制转换中排除const
,因为编译器可以提升为常量,或者是否更好地包含它以放宽对b
这样的限制可以在将来更容易制作const
吗?
答案 0 :(得分:8)
如果可能的话,都不是。设计您的类,以便基类定义一个完全有用的接口,并仅使用基类指针。
但是有时你会遇到遗留代码,在这种情况下我会明确说明你将它转换为const。
编辑:我应该清楚地表明,偶尔出现非多态性情况并且使用演员表的解决方案是合适的。一般来说,向下倾斜可能是一种设计气味,但并不总是表明某些东西肯定是错误的。
答案 1 :(得分:3)
嗯,要明确的是,他们做同样的事情。
现在,如果您要从const base *
转换为const derived *
,则只有后者才有效,而前者也需要const_cast
。如果您要从base *
转换为derived *
,则只有前者有效,否则您需要丢弃您的演员刚刚添加的const
。< / p>
我的偏好是避免在演员表中使用const
修饰符,除非明确需要。保持代码就像编译器允许的那样简单。换句话说。
当然,如果dynamic_cast<>
可能是另一个派生类的实例,那么在这种情况下你应该使用static_cast<>
而不是b
。
答案 2 :(得分:3)
对于一行代码我不会太担心。如果您将来确实将b
更改为const base*
,那么编译器会告诉您确切的行是什么以及要更改的内容。因此,无论哪种方式都可以获得极大的好处 - 其中一个让线条更短,另一个可能将来在您已经处于相同功能变化的情况下为您节省几秒钟的工作时间代码。如果发生这种情况,我会把const
放进去,因为它会略微减少一行代码对另一行细节的依赖。但如果代码已经写完,我就不会不去改变它。
如果您正在设计API,那么您可以将const
放在尽可能的地方,因为更改API可能会很痛苦。我不认为这种潜在的未来变化是痛苦的。
答案 3 :(得分:3)
如果可能的话,我努力做尽可能少的显式演员表,其他一切都是隐含的。
所以我会使用前者(即不包括演员中的const
)。
但这只是我的意见。你也可以在那里写const
,因为它符合你的口味。