问题标签 [binary-compatibility]

I am trying to compile my apps (which uses 3rd party libraries) for the x64 platform. However selecting x64 from Build Configuration Manager from my VS2008 Pro doesn't seem to work. The binary does get created but my client wasn't able to get it to run on x64.

I wonder if the 3rd party DLLs could be the cause. Anyone has any idea on this?

我很惊讶Apache Commons Collections项目仍然没有让他们的库泛型感知。我真的很喜欢这个库提供的功能，但是缺乏对泛型的支持是一个很大的障碍。Commons Collections的Lavalabs fork 确实支持 generics，这似乎声称向后兼容，但是当我尝试更新到这个版本时，我的 Web 应用程序无法启动（在 JBoss 中）。

我的问题是：

• 是否有人已成功从 Commons Collections 更新到上述分叉
• 如果 Commons Collections 有任何计划增加对泛型的支持

顺便说一句，我知道 Google 集合，但在 API 稳定之前不愿意使用它。

干杯，唐

有什么方法可以使使用不同编译器构建的 c++ dll 相互兼容？这些类可以具有用于创建和销毁的工厂方法，因此每个编译器都可以使用自己的 new/delete（因为不同的运行时都有自己的堆）。

我尝试了以下代码，但它在第一个成员方法上崩溃了：

接口.h

用VC9编译的test.cpp，test.exe

a.cpp 用 g++ 编译 g++.exe -shared c.cpp -o c.dll

编辑：我在 GCC CreateClass 方法中添加了以下行，文本被正确打印到控制台，所以它的函数调用就是杀死它。

我想知道，COM 是如何设法保持跨语言的二进制兼容性的，因为它基本上所有类都具有继承（尽管只有单个），因此是虚函数。只要我可以维护基本的 OOP 内容（即类和单一继承），如果我不能重载运算符/函数，我就不会感到非常困扰。

将新成员函数添加到 d 指针类定义中会破坏二进制兼容性吗？

例如，与原始定义相比，下面的新定义会破坏二进制兼容性吗？（附带问题，是否有工具可以告诉我新的 .so 与旧的 .so 相比是否会破坏二进制兼容性？如果没有，我该如何手动检查？）

原来的：

新的：

仅供参考：我知道 d 指针类应该在 cc 文件而不是标题中指定。上面的示例旨在关注二进制兼容性问题。

我在一个普通的 jar 中有以下类：

然后我将构造函数参数从 a 更改List为 a Collection，如下所示：

重建公共 jar 并运行系统NoSuchMethodError在调用构造函数时会在任何依赖类中导致 a，直到我重新编译该类。

我有一些想法是什么导致了这种情况，就像构造函数如何绑定在依赖类的字节码中一样，但我不是 100% 确定。

请问有人可以解释一下这里发生了什么吗？

更新

我随后做了一个快速测试并查看了字节码：

正如 Tom 所说，正如您在第 13 行所见，确切的构造函数是在编译时绑定的。

你每天学习新的东西 ：-）

.NET 中的事件有一个标准模式——它们使用一种delegate类型，该类型采用一个名为 sender 的普通对象，然后是第二个参数中的实际“有效负载”，该参数应从EventArgs.

派生第二个参数的理由EventArgs似乎很清楚（请参阅.NET Framework Standard Library Annotated Reference）。随着软件的发展，它旨在确保事件接收器和源之间的二进制兼容性。对于每个事件，即使它只有一个参数，我们也会派生一个自定义事件参数类，该类具有包含该参数的单个属性，因此我们保留了在未来版本中向有效负载添加更多属性而不破坏现有客户端代码的能力. 在独立开发组件的生态系统中非常重要。

但我发现零参数也是如此。这意味着，如果我的第一个版本中有一个没有参数的事件，我会写：

...那我做错了。如果我将来将委托类型更改为新类作为其有效负载：

...我将打破与我的客户的二进制兼容性。客户端最终绑定到一个内部方法的特定重载add_Click，EventHandler如果我更改委托类型，那么他们就找不到该重载，所以有一个MissingMethodException.

好的，那么如果我使用方便的通用版本呢？

不，仍然是错误的，因为 anEventHandler<ClickEventArgs>不是EventHandler<EventArgs>.

因此，要获得 的好处EventArgs，您必须从中派生，而不是按原样直接使用它。如果你不这样做，你也可能不使用它（在我看来）。

然后是第一个论点，sender。在我看来，这似乎是邪恶耦合的秘诀。事件触发本质上是一个函数调用。一般来说，该函数是否应该有能力从堆栈中挖掘并找出调用者是谁，并相应地调整其行为？我们是否应该强制要求接口看起来像这样？

毕竟，实现者Bar可能想知道是谁caller，所以他们可以查询更多信息！我希望你现在正在呕吐。为什么事件应该有所不同？

因此，即使我准备为EventArgs我声明的每个事件创建一个独立的派生类，只是为了让它值得我使用EventArgs，我肯定更愿意放弃 object sender 参数。

Visual Studio 的自动完成功能似乎并不关心您为事件使用的委托 - 您可以键入+= [hit Space, Return]并为您编写一个与它碰巧匹配的处理程序方法。

那么偏离标准模式会失去什么价值呢？

作为一个额外的问题，C#/CLR 4.0 会做些什么来改变这一点，也许是通过代表的逆变？我试图对此进行调查，但遇到了另一个问题。我最初将问题的这一方面包含在另一个问题中，但它在那里引起了混乱。把它分成三个问题似乎有点多……

更新：

事实证明，我想知道逆变对整个问题的影响是正确的！

正如其他地方所指出的，新的编译器规则在类型系统中留下了一个在运行时爆炸的漏洞。EventHandler<T>通过对 的不同定义，该孔已被有效地堵塞Action<T>。

所以对于事件，为了避免你不应该使用的那种类型的洞Action<T>。这并不意味着您必须使用EventHandler<TEventArgs>; 这只是意味着如果您使用通用委托类型，请不要选择启用逆变的类型。

欢迎任何演示源兼容性被破坏但二进制兼容性保持的示例。

在重构方法时，很容易在 Java 中引入二进制不兼容（与以前版本的代码）。

考虑更改方法以将其参数类型扩大到父接口：

使用此方法的所有代码将继续编译而无需更改，但确实需要重新编译（因为旧的二进制文件将因 MethodNotFoundError 而失败）。

将方法拉到父类中怎么样。这需要重新编译吗？

该方法已从 B 移至父 A。它还将可见性从受保护更改为公开（但这不是问题）。

我需要在 B 中维护一个“二进制兼容性包装器”，还是它会继续工作（自动分派给父类）？

我目前正在为需要预编译二进制/DLL（它将是跨平台的）的产品设计面向公众的 C++ API。我希望 API 允许用户使用我们支持的任何 POD（如果适用），但基本要求是最大的灵活性和二进制兼容性。我正在做一些类似于 CPLEX 的 API 的事情（这是几个灵感之一），但我认为指定类型信息的方式可能比他们所做的更好（关于 IloInt、IloNum、IloAny、Ilo* var等，见链接（希望）用于 IloExtractable 分支）而不会弄乱二进制兼容性。我错了吗？我有一些想法，但我不记得它是什么，或者它是否会起作用，我相信它类似于访问者或装饰者模式，但对于类型，有人可以在这个问题上启发我吗？我面前有一本由 GoF 编写的设计模式书。

注意：这里可能出现的任何语法错误都不是当前问题的一部分。

我认为我不能使用的示例以及原因：

可能......但这可能会使表达式树变得复杂。

可能会影响未来的扩张。

丑陋如罪，可能会引起很多微妙的问题。

编辑：作为对 Mads Elvheim 的回应（在找到此链接后），我现在意识到我不需要从我的可能性中排除模板，这很好，但我仍然不确定这是最好的主意 - 至少对于 Constraints 类（即使它在概念上是合理的），请原谅我没有我想的那么清楚。

为了使我的 API 易于使用，我使用 bnf 定义了语法（这对我来说相当新）。这导致了表达式、约束和其他将与约束交互的类的抽象语法树。因为其他类将与约束交互，所以我宁愿避免在“最后一分钟”之前尽可能多地传递类型信息。可以这么说。我觉得我可能错过了一个抽象层次。

学习 CPLEX 给我的印象是，他们通过遵循数字域（整数和实数）、线性方程表达式（当然）以及相应的可能性来建模他们的类型，这绝对是有道理的，嗯……

（显然我不能发布多个链接，因为我是新用户。）

编辑 2：作为第一步，我决定ConstraintExpressionArgument在 Constraint 和 Expression 类之间添加一个，这样我仍然可以在我的表达式树中识别一个约束，而无需知道它所操纵的类型是好的。

我可能忽略提及的另一个细节是，与在 CPLEX 中 Constraint 类本身不可用的情况不同，我的 Constraint 类目前是一个可用的用户类，但就像在 CPLEX 中一样，我也想留出扩展空间（因此是打字问题）。 ..

无论如何，目前我有相当于

我正在做一个被我不认识的人使用的项目。我们在降低 CheckStyle 警告方面做得相当不错，而且在不破坏二进制兼容性的情况下，它会达到一个低水平。

大多数剩余警告是由缺少 final 关键字的常量（public static final）引起的。常量的命名清楚地表明开发人员希望它们是只读的，但它们根本没有最终定义。

除非开发人员正在编写一些非常糟糕的代码来利用这种疏忽，否则如果我们添加它们，他们的代码不会中断。

当前版本号为 1.2.1。您会应用更改并转到 2.0，还是应用更改并将其作为 1.3 推出。需要完整的 2.0 似乎是一个很小的变化。

我该怎么办？