Приложение: я понимаю, что этот пост, похоже, принимает форму напыщенной речи, но если бы вы могли исправить любые мои недоразумения, уточнить что-нибудь или еще лучше: помогите мне решить мою проблему с проблемой итератора, я был бы очень благодарен! В настоящее время я использую cplex 9 (я знаю, что это не последний, это из моих рук).

Это только у меня или CPLEX Concert API может использовать некоторые улучшения? Сказать, что это оставляет желать лучшего, было бы любезно, на мой взгляд, потому что это нарушает практически все устоявшиеся практики качественного проектирования C ++ API, с которыми я когда-либо сталкивался.

Нотабли:

методы const setteroperator [] возвращает ссылки на объекты-указатели вместо ссылокoperator [] const возвращает дескрипторы ссылок, которые не являются константными,приводя к потенциальным ошибкам.нет итераторов массива (хотя итераторы не очень хороши для параллельного программирования, по-моему, он должен быть доступен для использования менее критичным кодом)крайняя враждебность к разработчикам для пользователей STL, которые хотят смешать их (или, если не STL, то, по крайней мере, код, который сам по себе уже является STL-совместимым, как Boost).пример: ни единой typedef в классах массива, ни даже (на голом и абсолютном минимуме) value_type.

Я сделал упаковщик массива, это было легко. Я сделал итератор, не так уж и много. Из-за первых двух пунктов, итератор (в настоящее время) приводит к коду, который компилируется, когда это не должно! Я все еще пытаюсь найти способ обойти это (я использую boost.iterator_facade).

Не поймите меня неправильно, я понимаю, что при разработке API нужно искать компромисс. Мне совершенно ясно, что API был разработан для упрощения руководств (скрывая языковые соображения от пользователя, которого я представляю). Однако при этом, хотя это могло упростить проектирование API C ++, оно сделало написание кода более сложным и трудоемким, чтобы компенсировать то, что я в настоящее время считаю ошибками проектирования.

Когда в Риме, делай, как римляне!

Я хотел бы услышать обоснование их дизайнерских решений, касающихся этих вопросов.

Редактировать: мне удалось заставить мой класс Iterator работать, при обработке устраняя как можно больше недостатков юзабилити и правильности углового случая, связанных с использованием через итераторы в структуре передачи объектов cplex, за счет некоторых затрат. производительность (клонирование извлекаемых файлов перед возвратом их из const_iterator). оставляя (я полагаю) только первый заметный недостаток, который не может быть исправлен без дополнительного слоя косвенного обращения вокруг каждого затронутого типа в API cplex ... нет, спасибо, я просто должен быть осторожным с частотой вызовов, когда разыменование const_iterators производных от IloExtractable типов.