const总结

shan_ghost

原帖由 silverzi 于 2008-7-15 13:13 发表

const只写了一次（const A），那么成员指针变量会被如何解释？
const char *
还是
char const*
还是
const char const *

muteable能解决这个问题不？

首先，这三个写法是等价的（我记得好像const const char之类东西会被自动去掉重复的吧）
当然，我知道你想说的是 const char * const^_^


其次，对于
class A
{
   public:
        void func() const;
   private:
        char * m_S;
}

假设func内部这样使用m_S:
A::func() const
{
       //为m_S分配内存
       m_S = getMemory(BUFF_SIZE);   //1
       //为*m_S赋值
     strcpy(m_S, "test short str");     //2
       //把测试字符串拷贝给m_S;如果m_S容量过小，则用realloc重新分配足够空间后再完成拷贝
       ReallocAndCpy(&m_S, "test long long long long string");    //3
}



那么，你要问的问题应该可以清晰表达为如下几个问题吧：
1、//1、//2、//3是否都能被编译器准确阻止？
——答案是：肯定能。做不到就说明编译器不能严格符合c++标准。（亦即：func里，m_S是 const char * const）。

2、muteable能否精确的分别阻止编译器“对m_S本身的修改的报警”和“对m_S指向内容的报警”？
（或者说： 能否声明 muteable char * muteable m_S？）
——显然，支持这种声明是很自然的事；编译器作者想不区分它们恐怕反而要多花一些力气(对程序员来说，这句话想必不难理解^_^)。


当然，不同编译器对c++标准的支持程度是不同的；具体到每一个编译器上，任何较生僻的东西还是应该先做验证。

silverzi

原帖由 shan_ghost 于 2008-7-15 13:39 发表

...

1、//1、//2、//3是否都能被编译器准确阻止？
——答案是：肯定能。做不到就说明编译器不能严格符合c++标准。（亦即：func里，m_S是 const char * const）。

2、muteable能否精确的分别阻止编译器“对m_S本身的修改的报警”和“对m_S指向内容的报警”？
（或者说： 能否声明 muteable char * muteable m_S？）
——显然，支持这种声明是很自然的事；编译器作者想不区分它们恐怕反而要多花一些力气(对程序员来说，这句话想必不难理解^_^)。


当然，不同编译器对c++标准的支持程度是不同的；具体到每一个编译器上，任何较生僻的东西还是应该先做验证。

呃，用新关键字来做“位”掩码的方式，确实能解决这个问题。
受教了，多谢。

PS：不过muteable这东西我实际中从没接触过（其实现在知道了也不会用，感觉完全没可读性和移植性嘛）。

blackuhlan

c++就是要向上兼容C，所以不是纯洁的OO语言，这也是被人诟病的地方。
另外，你为什么非要将一个const的参数作为实参传给另一个函数，然后又要去修改它，这说明你的设计有问题。
const_cast如果随便用，就像goto随便用一样，全局变量随便用一样，方便了你，麻烦了别人。

blackuhlan

我觉得有些时候我们写程序的人不要总是用一种技术的心态去看问题。

shan_ghost

原帖由 blackuhlan 于 2008-7-15 20:24 发表
c++就是要向上兼容C，所以不是纯洁的OO语言，这也是被人诟病的地方。
另外，你为什么非要将一个const的参数作为实参传给另一个函数，然后又要去修改它，这说明你的设计有问题。
const_cast如果随便用，就像go ...

有多少人看到：
d:\proj\t\t.cpp(14): error C2440: “初始化” : 无法从“const int *__w64 ”转换为“int *”

会明白这是const不能隐式转换为非const所致？
又有多少人会直接了当的用个 (int*) 强制转换消除错误了事？

const_cast是C++风格转换，它本身好找、好认，并且标识了风险，因此我已经习惯用它来举例了——莫非C风格类型转换就可以随便用了？

我觉得有些时候我们写程序的人不要总是用一种技术的心态去看问题。

恰恰相反，我们写程序的必须以一种对技术精益求精的心态去看问题。
——否则，把const用C风格强制转换掉就成家常便饭了；如果有人习惯用这种风格的转换，试试看能不能在5000行代码中把所有这些风险代码都找出来。




正如我前面举的例子，传给：
void xxx(const string arg)
的字符串被莫名其妙地修改了——但怎么看，我都是在传值啊？

没办法。C/C++一向认为它的用户都是高手：他们了解一切风险，因而想做什么都可以。

常量优化——这几乎已经是C++中除指针和强制类型转换外最大的风险了。
如果没有相关知识，遇上类似故障该怎么办？！

kvxg

const 很好，但偶不经常用。

shan_ghost

其实muteable关键字（甚至常成员函数），我自己也从不用它^_^

C++为人诟病，不是因为它“纯种”与否——C还不是“纯种”的结构化语言呢。
写程序又不是养狗；程序设计语言“纯种”意味着限制，意味着种种不便，意味着效率损失——除非面对特定问题或者是给初学者学习、使用，否则“纯种”语言并没有什么先天优势。


C++的问题在于它同时支持了结构化程序设计、面向对象程序设计以及泛型编程等多种风格；再加上支持运算符重载；同时还想兼容C——这些东西相互作用起来，说好听点叫全能，说难听点就是复杂度失控。

比如const的例子。看似很简单的一个问题，由于和类、多线程等等的配合，就成了这个样子。
简单的const尚且导致复杂度被如此放大，何况其他高级特性呢？
等C++ 0X支持了（可定制的）垃圾回收，恐怕就更要复杂的不成样子了。
——开个玩笑：这种交互影响造成的复杂度增加，几乎是一个O(NlogN)甚至O(N^2)的问题



但是：
——复杂意味着不管做什么，你都能得到支持——至少是支持你从头实现一个支持特定应用的库。
——如果你想钉个钉子，打开工具箱，你不会把硫酸拎出来用；同样，绝大部分情况下，你甚至都用不着动用指针。
——既然你从来不抱怨工具箱里的东西太多，让你无所适从（恰恰相反，你总是会为缺少合适大小的改锥而发愁）；那么，为何总有人学不会合理利用C++这个大工具箱呢？
——如果java，或其他任何一种语言，也想玩到这种全面支持，恐怕（或者说显然）会比C++更加复杂。
——所以说，想用好C++，先要学会放弃；学会从各种让人眼花缭乱的支持中挑出你真正需要的东西。

yourantianya

原帖由 silverzi 于 2008-7-15 09:54 发表
补充一下，const是有传染性的

敢问这个传染性是什么意思？


另外，支持楼主

silverzi

原帖由 yourantianya 于 2008-7-16 13:15 发表



敢问这个传染性是什么意思？


另外，支持楼主

infectivity

sinboyang

原帖由 zszjxh 于 2008-7-14 16:40 发表
C和C++中的const是不一样的
const int a = 1;

switch(i)
{
    case a: ... break;
    case 2: ... break;
    default: ... break;
}
如果i等于1，不会执行case a： 后面的语句。

在C++中这句是 ...

用Ｇ＋＋　编译，也会执行到case a 分支啊。嘻嘻！