Здравствуйте, Bender, Вы писали:

B>По поводу внешнего качества кода, не рассматривая его внутреннее содержание, здесь многие уже высказались. Причём по большей части справедливо — уж извините, нет здесь никакого качества.

Я не говорил про качество, разговор только о допустимой длине.

B>Судя по топику, задача решалась больше месяца. Неужели нельзя было выделить пару часов вначале на поиск готовых решений?

Вообще то я не люблю "готовые" решения; если такие были в бусте, это вполне мог бы знать Манагер, по его рассказам уже собаку съевший на этом. Молчание доказывало, что там нечего искать. Сейчас очевидно, что его знакомство с бустом ненамного опережало мое.

B>Как раз таки наоборот, Boost.Graph построен таким образом, что его легко адаптировать к свои структурам.

Я попробую, и скажу, насколько это легко. Пока же я вижу плохую (или тяжелую) документацию. А boost у меня и не устанавливается (msvc-7.0). Рекомендуют делать build Binaries библиотек ("If you're using an earlier version of Visual C++, or a compiler from another vendor, you'll need to use Boost.Build to create your own binaries.") — но при попытке компиляции выходит в лог ошибка
builtins.c(1889) : error C2065: 'IO_REPARSE_TAG_SYMLINK' : undeclared identifier
Так что "вещь в себе" так и остается "вещью в себе".

B>Судя по тому что применяется формула Эйлера для планарных графов... Оно?
Не знаю. Формула Эйлера вообще то верна не только для планарных графов, это грани определяются в планарном графе, а в общем случае есть просто контуры — замкнутые циклы. Как в Graph определяются грани, это еще надо выяснить, — если это просто многоугольники, то это не совсем то, что мне надо. В моей задаче все ребра — произвольные кривые. Конечно, топологически можно кривую считать прямой, но что тут будет с гранями — сложно предсказать. Мне думается, проще их выявлять с помощью углов. Как в Graph, неизвестно. Нужны тесты, проверки, надо знакомиться с кодом.

Почему то библиотека не обрабатывает параллельные ребра — у меня это типичный случай, надо или игнорировать их или обрабатывать как все прочее. Exception тут не лучшее решение.

B>1. Этот алгоритм, вопреки вашим заверениям, не является неделимым. Он бьётся на вполне законченные и обособленные части, которые можно использовать повторно.

Допускаю, вопрос в том, насколько просто — разбить. Вы же не думаете, что частная задача по времени равна затратам на написание того же Grapha — или даже его одной части.

B>2. Кстати, внутри PrepareContoursMakeEquidistants лежит мина с квадратичной сложностью, причём которая элементарно обходится в первом же черновом варианте. Это всё никак не сочетается с заявкой на звание "алгоритмиста".

Не вижу квадратичной сложности. Если вы про цикл for внутри do, то при желании его можно оптимизировать, но он не пробегает по всем ребрам повторно, а только по уже найденным стилям кривых (а их в реальном чертеже не так много).

B>3. Boost.Graph был приведён во-первых в качестве демонстрации того, что части алгоритма действительно реализуются отдельно, а во-вторых — наличия уже готового решения данной "уникальной" задачи (причём наверняка есть и другие варианты).
Это еще предстоит проверить.