Adendo: Sei que este post parece assumir a forma de um discurso retórico, mas se você puder corrigir qualquer mal-entendido que eu tiver, esclarecer alguma coisa ou melhor ainda: me ajudar a resolver meu problema com o problema do iterador, ficaria muito grato! Atualmente, estou usando o cplex 9 (sei que não é o mais recente, está fora do meu alcance).

Sou eu ou a API do CPLEX Concert pode usar alguma melhoria? Dizer que deixa muito a desejar seria gentilmente colocado na minha opinião atual, pois parece violar quase todas as práticas estabelecidas para o design de qualidade da API C ++ que eu já encontrei.

Notáveis:

métodos do set setoperador [] retornando objetos de identificador de referência em vez de referênciasO operador [] const retorna identificadores de referência que não são const,levando a possíveis erros.sem iteradores de matriz (embora os iteradores não sejam ótimos para programação paralela, ele ainda deve estar disponível para uso por código menos crítico na minha opinião)extrema hostilidade ao desenvolvedor para usuários do STL que desejam misturar os dois (ou se não o STL, pelo menos o código que já é compatível com o STL, como o Boost).exemplo: nem um único typedef nas classes da matriz, nem mesmo (no mínimo absoluto e absoluto) value_type.

Eu fiz um invólucro de matriz, isso foi fácil. Um invólucro de iterador que eu criei, nem tanto. Por causa dos dois primeiros pontos, o iterador (atualmente) resulta em código que compila quando não deveria! Ainda estou tentando encontrar uma maneira de contornar isso (estou usando o boost.iterator_facade).

Não me interpretem mal, entendo que é necessário fazer trocas ao criar uma API. É bastante claro para mim que a API foi projetada para simplificar os manuais (ocultando considerações dependentes da linguagem do usuário que eu imagino). Entretanto, embora isso tenha simplificado o design da API C ++, tornou minha escrita de código mais complexa e demorada para compensar o que atualmente considero erros de design.

Quando em Roma, faça como os romanos!

Eu adoraria ouvir a lógica de suas decisões de design em relação a esses pontos.

Edit: Eu consegui fazer com que minha classe Iterator funcionasse, no processamento, eliminando tantas falhas de usabilidade e correção quanto ao uso por meio de iteradores no design de passagem de objetos do cplex que eu pudesse, à custa de alguns performance (clonando extraíveis antes de retorná-los de um const_iterator). deixando (acredito) apenas a primeira falha notável restante que não pode ser corrigida sem uma camada extra de indireção em torno de todos os tipos afetados na API do cplex .. não, obrigado, vou ter que ter cuidado com a frequência das chamadas quando desreferenciando const_iterators de tipos derivados do IloExtractable.