ABI是个多大的事儿？

[pongba]

我曾经在多处地方听到关于ABI的缺失是C++的一个大问题的说法，Bjarne在一篇很久以前的访谈里面也提到这个问题。
ABI缺失的本质问题在于不同编译器编译出来的目标文件没法互相链接。
那么，现实中究竟有多少项目居然使用大于一个编译器的呢？（分布式编译？）

跟Module的缺失相比，我倒觉得ABI问题不值一提了。

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[Googol Lee]

基本上，除了嵌入式项目，所有的都不敢保证是同一个编译器吧？谁能保证windows的dll是vs2005编的？linux上的那些so呢？
（linux，如果有瘾且有时间有空间的话，还是能保证的......）

windows还可以保证dll都是c接口的，linux上就不一定了，一个基础gui qt是c++的。

嵌入式倒是一般从头编到尾，不用太多考虑这个问题。不过像symbian，windows mobile，甚至monavista的linux，好像也
都是先编译好的......

[pongba]

On Nov 14, 2007 7:00 PM, Googol Lee <goog...@gmail.com> wrote:

基本上，除了嵌入式项目，所有的都不敢保证是同一个编译器吧？谁能保证windows的dll是vs2005编的？linux上的那些so呢？
（linux，如果有瘾且有时间有空间的话，还是能保证的......）

windows还可以保证dll都是c接口的，linux上就不一定了，一个基础gui qt是c++的。

呃.. 你是说第三方发布的二进制库。我问题里面没考虑这个。不过话说回来 ，install第三方库的时候用你项目所用的编译器编译一遍也不是什么太大的问题吧。反正也就O(1)的复杂度，虽然编译时间长了点，但是刚好可以抽个空去火星上参观一下:P

[CAXSOFT]

Do you use IncredBuild?

在07-11-14，pongba <pon...@gmail.com> 写道：

[red...@gmail.com]

这关系到厂家以二进制的方式提供库的兼容性.
进一步就影响到厂家和用家采用这个语言的积极性.

没有 ABI, 同一个编译器不同版本之间都未必能够兼容, 还是麻烦.


pongba 写道:

[red...@gmail.com]

这关系到厂家以二进制的方式提供库的兼容性.


pongba 写道:

[pongba]

On Nov 14, 2007 8:27 PM, CAXSOFT <myt...@gmail.com> wrote:

Do you use IncredBuild?

Heard of it before. Never used it.

[red...@gmail.com]

现在这个问题不严重了:

1. com, mozilla 里面的xpcom & 脚本集成, , 甚至是 xml, SOA 等等, 使得厂家之间的产品, 很可能不需要用连接的方式弄在一起了
2. C++ 也不是商用环境的主流了
3. C++ 编译器种类比起十年前少了, 而且小份额的厂家, 自己会主动去适应 vc 或者 gcc 了.

但当年, 曾经碰到过一个国外大厂家提供的工业控制设备的编程 API 库, 支持的是 msc++ 6, 我们很不喜欢的编译器, 那能怎么办 ?

[yq chen]

小份额的厂家, 自己会主动去适应 vc 或者 gcc 了。

 

看来一方做大是有好处的。呵呵。

 

不过虽然有COM和XPCOM，但是这些都不是C++的解决方案。

 

在07-11-15，red...@gmail.com <red...@gmail.com> 写道：

[Jian Wang]

把所有库都编译一边，在很多情况下作不到．
１．要求有所有库的ｓｏｕｒｃｅ．
２．所有库的ｓｏｕｒｃｅ都必须是跨编译器的．包括可以在各个版本的编译器上编译．
３．你有能力构筑所有库的编译环境．

在 07-11-14，pongba<pon...@gmail.com> 写道：

[oldrev]

1. C++ 库没source 几乎是没法用的，光调试就是一个很大的问题，要不怎么就连
小气的MS都在 VC里附带了 CRT和MFC/ATL的源码
2. 跨编译器是库开发者应该尽可能做到的，再说目前两大家 VC/GCC 就是各自平
台事实上的标准，谁的编译器要是不支持它们就是没事找抽。
3. 一般的C++项目都只会用一个框架型库加上一个或多个业务库要不就是彻底从零
开始，一个项目只会说一种方言，你用了MFC就不大可能再扯上Qt，所以编译不是
问题。

--
"Live Long and Prosper"
- oldrev

[Googol Lee]

1 ms那套调试库和最终release的链接库不是一套啊，谁能保证release的那套库的编译器和你编译环境的编译器是一样的？
2 vc和gcc不同版本间的问题呢？印象里gcc在3->4中就有了点小改动。
3 第三方库还是要用很多的，有源码的qt，ace，boost，没源码的，比如字体渲染库（嵌入式平台常用到），db（倒是也可以找有源码的......）

On Nov 15, 7:46 pm, oldrev <old...@gmail.com> wrote:
> 1. C++ 库没source 几乎是没法用的，光调试就是一个很大的问题，要不怎么就连
> 小气的MS都在 VC里附带了 CRT和MFC/ATL的源码
> 2. 跨编译器是库开发者应该尽可能做到的，再说目前两大家 VC/GCC 就是各自平
> 台事实上的标准，谁的编译器要是不支持它们就是没事找抽。
> 3. 一般的C++项目都只会用一个框架型库加上一个或多个业务库要不就是彻底从零
> 开始，一个项目只会说一种方言，你用了MFC就不大可能再扯上Qt，所以编译不是
> 问题。
>
>
>
> On Thu, 2007-11-15 at 20:28 +0900, Jian Wang wrote:
> > 把所有库都编译一边，在很多情况下作不到．
> > １．要求有所有库的ｓｏｕｒｃｅ．
> > ２．所有库的ｓｏｕｒｃｅ都必须是跨编译器的．包括可以在各个版本的编译器上编译．
> > ３．你有能力构筑所有库的编译环境．
>
> > 在 07-11-14，pongba<pon...@gmail.com> 写道：
>