中国DOS联盟

c++ 仿佛带着护卫和服务员的 c, 可这开支, 我怕消受不起...呵呵

c++ 程序员可以一边悠闲地喝着咖啡一边写程序, 而 c 程序员如果这样的话就未免太不敬业了. c++ 增加了程序员的生命, 增加了产品的开发速度, 并且尽一切真实的或"虚伪的"手段减少了出错的可能性. 但是, 任何馅饼都是有价格的. 有时候太穷, 买不起.

Originally posted by jawbin at 2006-5-28 15:27:
我有时候妄图使用结构体安慰自己, 后来看到结构体("纯粹的"结构体)和类差不多, 居然潜意识中连结构体都可能排斥了, 太病态了, 哈哈

好了 ...

不使用上述高级特性的类与相应的结构体开销等价～

另外它那修饰过了的导出符号, 虽然可能会提供更多的信息, 但是看起来"很不人性化":P

我独自跑了怎么远, 呵呵

Originally posted by jawbin at 2006-5-28 15:31:
自从那时候我试验过 stream 和 异常处理都各自会很大地增加目标的 size, 我后来见到 c++ 就感到眩晕

在典型的应用中，异常对目标程序的体积影响完全可以忽略，这种开销只在 Hello World式的程序里可见。stream的情况也是类似的。为什么会这样呢？举个例子：

可以比较以下用C写的 Hello World：

main()
{
printf("Hello Word!\n";
}

和用汇编直接调用OS字符串输出API写的等价代码，你会发现用C写的那个大了几十甚至几百倍！

这并不能说C编译生成的汇编码就是比手写的差几百倍，产生这种状况的原因是linker在连接C代码的时候把printf这个标准c调用的完整实现连接到了目标代码中。而printf实际上是一个功能很强大的输出函数，这个程序其实只用到了它的百分之一不到而已！

而在一个哪怕典型的，那盘就几千行代码的小型应用中，printf中的大部分代码基本都会被用到，这个时候再去比较它们的等效汇编实现就会发现它们的体积已经很接近了～

C和C＋＋的比较同样也是类似的。不要在一个hello world式的程序里比较它们～

哎, 我就是对 size 极其过敏, 而且由于前面提到的"移植性"问题, 我对 stream 和 异常处理目前还是敬而远之.
stream 和 异常处理 和 printf 可以比较, 但是, 在我看来, 我需要它们的强烈程度不一样, 就造成了我的取舍.

[ Last edited by jawbin on 2006-5-28 at 16:07 ]

Originally posted by jawbin at 2006-5-28 15:46:
另外它那修饰过了的导出符号, 虽然可能会提供更多的信息, 但是看起来"很不人性化"

我独自跑了怎么远, 呵呵

呵呵，名称粉碎不是给人读的，人类可以通过标准dump工具读出翻译后的函数声明。

例如VC粉碎的：
?_RecvAsync@CSocket@BaiY@@IBEXABV?$CHandle@VTAsyncIoCommand@BaiY@@U?$Deletor@VTAsyncIoCommand@BaiY@@@2@@2@@Z

用Dependency Walker看到就是：
void BaiY::CSocket::_RecvAsync(class BaiY::CHandle<class BaiY::TAsyncIoCommand,struct BaiY:eletor<class BaiY::TAsyncIoCommand> > const &

这甚至比C的Export更友善一些，我们再不用去猜这个export接口的返回值和参数了，对吧～

是的, 有更多的信息, 能用程序读出也是真的(例如, 用 depends 可以读出一个 c++ 函数的签名, 但是, 所读出的 c 的就"不完整", 反过来说, 好象相当遗憾), 但是更遗憾的是, c++ 的导出符号的修饰方式没有统一的标准, 各厂商之间可能无法通用. 不过, 这是个小问题. 因为现在库的格式就没有统一, 光导出符号一致也未必有什么意义.

所以只能力求在 source 上"移植"了, 虽然给 c++ 外表裹一层 c 接口来达到重用可能可以, 但是未免感觉有点醉糊涂了.

Originally posted by jawbin at 2006-5-28 15:58:
哎, 我就是对 size 极其过敏, 而且由于前面提到的"移植性"问题, 我对 stream 和 异常处理目前还是敬而远之.
stream 和 异常处理 和 printf 可以比较 ...

嗯，C＋＋标准库的厂商扩充自部分，如：hash_map、hash_set 之类，还有各编译器对不同C＋＋特性的支持程度，例如：模板的嵌套和部分实例化等等，确实给移植带来的一些不大不小的困难。

不过当前不支持异常的编译器不多了，呵呵。而且C本身也是有些移植问题的，比如不同编译器对64位整型的支持（有的不支持，有的是long, 还有的是longlong，另一些是 long long，还有一些是__int64....）等等。

当然这些问题C＋＋里也有，但是大部分情况下，C＋＋可以在不损失时空效率的前提下比较好的封装这些问题，比如：定义一个INT64类，重载所有64位整型的算术和逻运算。在支持int64的环境中，这些重载都直接内联而不损失效率；在不支持int64的编译环境，用两个32位整型和自定义的数逻运算提供支持。

Originally posted by jawbin at 2006-5-28 15:37:
另外还有一点, c++ 可以接受 c 代码, 反过去却不行

还有一个现成的样例: win16 及 win32 核心(Kernel, User, Gdi) APIs 均使用了 c, 而且据说为了效率, 还用了 ...

实际上，MS声称Win32是使用C＋＋和面向对象体系开发的。但是Win32 API必须是标准C接口，这是为了对C和其它语言（如Pascal，ada、cobol等）提供支持。

仔细看 Win32 API 会发现无处不在的 HANDLE 就是 this 指针，呵呵

Originally posted by jawbin at 2006-5-28 15:22:
正在下载中.... 看来asbai 兄 来头大大的大..

瀑布汗，，自己瞎写的文档而已，到让 jawbin 兄见笑了～

很好, 提到这个 INT64, 我想先说说这些基本类型的"定义". 先不管 .Net 等对这些基本类型提供了相应的类. 仅仅就说基本数据类型. 也不谈运行时泛型, 仅仅谈设计时或"编译时".

WORD 最初可能是认为"泛型", 目前我不清楚, 它是所谓的字长. 可能随着 CPU 的发展而不同. 使用它似乎也是为了代码移植, 而不是为了在运行时能进行什么对泛型的"真正充分利用".

而相应地, "具型"呢, 更清晰, 不会让人觉得含糊不清. 而且不用担心 WORD 型 "移植" 过去之后可能发生的不良结果.

那么, 通常, 基本数据类型, 也许该"具型", 我就是这样用的. 而另一个打算"移植的", 就使用一个"泛型样的", 例如, 可能为颜色专门指定一个类型, 在 Windows 系统之中有个 COLORREF 吧. 不过真正要"移植的"时候, 恐怕已经对颜色有多得多的要求了, 例如不同的颜色空间啊什么的, 不是早先所"泛型"出来的那个类型所能表达, 那么扩展将受阻碍. 所以, 在这种情况下, 有点两难. 望 asbai 兄能有所指点!

在这个时候, 可能类倒是一种希望了,我讽刺我自己,哎..

[ Last edited by jawbin on 2006-5-28 at 16:34 ]

Originally posted by asbai at 2006-5-28 04:14 PM:
无处不在的 HANDLE 就是 this 指针 ...

asbai 兄不是指在 MFC 中吧, 如果是, 那可是不作数的哦.

另外 asbai 兄太过谦了!

事实上, 我在当初还考虑了字节顺序, 所以, 在类型上还"添足"了很多. 只是后来还没使用, 因为一直使用的是 intel 兼容的 CPU.