只是我还是Cplex Concert API可以使用一些改进？

Question

附录：我意识到这篇文章似乎采取了一种咆哮的形式，但是如果你能纠正我有的任何误解，请澄清一下，或者更好：帮助我解决我在迭代器问题上的问题，我会非常感激！我目前正在使用cplex 9（我知道这不是最新的，它不在我的手中）。

仅仅是我还是CPLEX Concert API可以使用一些改进？说它留下了许多不足之处，我认为这很有帮助，因为它似乎违反了我曾经遇到过的优质C++ API设计的每一个惯例。

著名作品：

• 常量setter方法
• 操作符[]返回参考手柄对象而不是引用
  • 操作符[] const返回参考手柄未const的，leading to potential errors。
• 没有数组迭代器（即使迭代器是不太适合并行编程，它仍然应该是在我看来，可使用由更少的关键代码）
• 极端开发商，敌意谁希望的STL的用户混合两者（或者如果不是STL，至少是本身已经STL兼容的代码，比如Boost）。
  • 示例：在数组类中不是一个单独的typedef，甚至不是（在裸的和绝对最小的）value_type。

我提出的阵列封装器，这很简单。我所做的迭代器封装，并不是那么多。由于前两个点，迭代器（当前）导致编译时不应该编译的代码！我仍然试图找到一种方法（我使用boost.iterator_facade）。

不要误解我的意思，我知道在设计API时需要权衡取舍。我相当清楚，API旨在简化手册（隐藏用户想象中的与语言相关的考虑因素）。但是，尽管它可能简化了C++ API的设计，但它使我的代码写入更加复杂和耗时，以弥补我目前认为的设计错误。

在罗马时，做罗马人！

我很想听听他们有关这些要点的设计决定的理由。

编辑：我设法让我的迭代器类工作，在处理过程中尽可能多地消除了cplex对象传递设计中迭代器的使用情况和正确性缺陷。某些性能的成本（在从const_iterator返回它们之前克隆可抽取项）。留下（我相信）只剩下第一个明显的缺陷，如果在cplex api的每个受影响类型周围都没有额外的间接层，就不能纠正。不，谢谢，我只需要小心调用的频率取消引用IloExtractable派生类型的const_iterator。

Answer 1

这不会对您有多大帮助，但我无法相信从CPLEX 9切换到12时的改进，因为12可用于学术用途，因此可以使用。