只是我還是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可用於學術用途，因此可以使用。