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.
Notables:
- const setter methods
- operator[] returning reference handle objects instead of references
- operator[] const returns reference handles that aren't const, leading to potential errors.
- 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 effected 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.