是我的问题,还是Cplex Concert API需要一些改进?[英] Is it just me or could the Cplex Concert API use some improvements?

本文是小编为大家收集整理的关于是我的问题,还是Cplex Concert API需要一些改进?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。


附录:我意识到这篇文章似乎采取了咆哮的形式,但如果你能纠正我的任何误解,澄清任何事情,或者更好:帮助我解决迭代器问题,我会非常感激!我目前正在使用 cplex 9(我知道它不是最新的,它不在我的掌控之中).

只有我一个人还是 CPLEX Concert API 可以使用一些改进?说它还有很多不足之处是我目前的看法,因为它似乎违反了我所遇到的几乎所有高质量 C++ API 设计的既定做法.


  • 常量设置方法
  • operator[] 返回引用句柄对象而不是引用
  • 没有数组迭代器(即使迭代器不适用于并行编程,但在我看来,它应该仍然可供不太关键的代码使用)
  • 对于希望混合使用两者的 STL 用户(或者如果不是 STL,至少本身已经与 STL 兼容的代码,例如 Boost),开发人员极度敌视.
    • 示例:数组类中没有一个 typedef,甚至没有(绝对最小值)value_type.

我制作了一个数组包装器,这很简单.我制作的迭代器包装器,不多.由于前两点,迭代器(当前)导致代码在不应该编译的时候编译!我仍在尝试找到解决方法(我正在使用 boost.iterator_facade).

不要误会我的意思,我知道在设计 API 时需要进行权衡.我很清楚,API 旨在简化手册(对我想象的用户隐藏与语言相关的考虑).然而,这样做虽然可能简化了 C++ API 的设计,但它使我的代码编写更加复杂和耗时,以弥补我目前认为的设计错误.



编辑:我已经设法让我的 Iterator 类工作,在处理过程中,尽可能多地消除在 cplex 的对象传递设计中通过迭代器使用的极端情况可用性和正确性缺陷,在一些性能的成本(在从 const_iterator 返回之前克隆提取物).留下(我相信)只剩下第一个值得注意的缺陷,如果没有围绕 cplex api 中每个受影响类型的额外间接层,就无法纠正.不,谢谢,我只需要注意调用频率取消引用 IloExtractable 派生类型的 const_iterator.


并不是说这会对你有太大帮助,但是当我从 CPLEX 9 切换到 12 时,我不敢相信它的改进,因为 12 是免费的学术用途.



Addendum: I realize this post appears to take the form of a rant, but if you could correct any misunderstandings I have, clarify anything, or better yet: help me solve my problem with the iterator issue, I'd be very grateful! I'm currently using cplex 9 (I know it's not the latest, it's out of my hands).

Is it just me or could the CPLEX Concert API use some improvement? Saying that it leaves much to be desired would be putting it kindly in my current opinion, as it seems to violate just about every established practice for quality C++ API design that I've ever come across.


  • const setter methods
  • operator[] returning reference handle objects instead of references
  • no array iterators (even though iterators aren't great for parallel programming, it should still be available for use by less critical code in my opinion)
  • extreme developer-hostility for users of the STL who wish to mix the two (or if not the STL, at least code that is itself already STL-compatible, like Boost).
    • example: not a single typedef in the array classes, not even (at a bare and absolute minimum) value_type.

I made an array wrapper, that was easy. An iterator wrapper I've made, not so much. Because of the first two points, the iterator (currently) results in code that compiles when it shouldn't! I'm still trying to find a way around it (I'm using boost.iterator_facade).

Don't get me wrong, I understand that trade-offs need to be made when designing an API. It's fairly clear to me that the API was designed to simplify the manuals (hiding language-dependent considerations from the user I imagine). In doing so however, while it may have simplified the designing of the C++ API, it has made my code-writing more complex and time-consuming to make up for what I currently deem to be design errors.

When in Rome, do as the romans!

I would LOVE to hear the rationale for their design decisions concerning these points.

Edit: I've managed to get my Iterator class to work, in the processing eliminating as many of the corner-case usability and correctness flaws with respect to usage through iterators in cplex's object-passing design as I could, at the cost of some performance (cloning extractables before returning them from a const_iterator). leaving (I believe) only the first notable flaw remaining which can't be corrected without an extra layer of indirection around every affected type in the cplex api.. no thanks, I'll just have to be careful of the frequency of calls when dereferencing const_iterators of IloExtractable-derived types.


Not that this will help you much but I could not believe the improvements when I switched from CPLEX 9 to 12, it worked out for use since 12 is free for academic use.