Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, jazzer, Вы писали:
J>>Отвязался (перешел на стандартную гнутую), прогнал тесты — много чего просело.
BZ>если это критично — надо писать самим. стандартные библиотеки в силу своей общности очень далеки от оптимальной реализации любого конкретного алгоритма
Ну вот когда мне будут платить за это — тогда и займусь, сразу же.
А пока платят за фичи — буду пилить фичи, а апгрейды компиляторов — это все в свободное от пиления фич время.
По той простой причине, что апгрейд компилятора сам по себе не принесет конторе больше денег, поэтому надо по крайней мере убедиться, что ты своим апгрейдом не делаешь хуже. И вот наши тесты показывают, что "не все так однозначно" и, стало быть, торопиться с апгрейдом особого смысла нету.
В С++11/14 много замечательных фишек, но они не критичны, они больше для удобства программера. Того же быстродействия можно добиться и в С++03, пусть и более многословно. тем более что весь наш имеющийся код заточен под максимальное быстродействие в режиме С++03 — так что немедленного выигрыша просто от апгрейда версии языка точно не будет — мы не возвращаем по значению огромные объекты, чтобы rvalue references автоматом все ускорили.
Так что буду помаленьку смотреть, подкручивать опции, пробовать новые версии и компилятора, и библиотек, разные режимы компиляции, пока не добьюсь скорости кода не хуже имеющейся — а вот тогда уже и апгрейдиться можно.
Потому что, к сожалению, у того же GCC сплошь и рядом в оптимизаторе что-нть косячат, посмотри сам у них список багов от версии к версии.
С++11/14 — это фронт-энд и библиотека, но они ж не только их меняют в каждой новой версии, но и бэкэнд с оптимизатором тоже.
И глюки обычно в последних (это чтобы не показалось, что я утверждаю, что С++11 хуже, чем С++03. В компиляторе много компонентов, и улучшив один, вполне могут по ходу дела сломать другой — а у нас тест просядет, и думай — это из за изменений в библиотеке или в конкретном режиме оптимизации).
