Здравствуйте, AlexGin, Вы писали:
_>>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
AG>Обычно, чем больше объём , тем больше вероятности того, что потребуется что-то специфическое.
Сомнительно. Скорее это определяется предметной областью.
AG>Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
COM — это всего лишь ABI, а не предметная область. Соответственно если в данной области есть кроссплатформенные библиотеки, то никаких проблем нет. Например та же SDL вполне себе работает на винде через DirectX (который как известно реализован через COM). При этом если программисту хватает для его целей возможностей SDL, то ему абсолютно не важно через что оно там реализовано на низком уровне.
_>>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
AG>В ТЗ не заявлено ничего по данному поводу 
AG>По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
Так и не надо специально стараться программировать под Линух (если это конечно не оговорено в ТЗ). Достаточно просто использовать удобные библиотеки, а не вызовы системного API. Кстати, вот у вас же почему-то используется в проекте Qt, а не win api для GUI, не так ли? ) Это же не ради кроссплатформенности (хотя вы её получается при этом автоматом), а ради удобства. Так почему в каких-то других областях должно быть по другому? )
_>>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
AG>OK!
AG>Вот мне нужно отобразить древовидную таблицу (иерархический грид):
AG>Image: VsFlexGrid8_1.jpg
AG> Я применяю вот это (ComponentOne VsFlexGrid8):
AG>http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Хгм))) Отойдя от шока после идеи о применение ocx компонент в проекте на Qt спрошу очевидное: а в чём собственно проблема скомпилировать данное извращение другим (не MSVC) компилятором? )))
AG>Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
Стандарт C++ ни в кое мере не запрещает использовать ocx компоненты. ))) А вот использовать не укладывающиеся в стандарт особенности компиляторов (их сейчас становится всё меньше и меньше, но всё же до сих пор встречаются) точно не стоит. )))
AG>Теперь насчет именно адаптации по gcc: прежде всего, меня раздражает, что в нём, при ошибке компиляции выдается скупой и зачастую малоинформативный короткий текст. Найти истинную причину (даже днём с огнёмпри помощи гугла) очень трудно
AG>На MSVC выдаётся код ошибки, (например C2259) и далее в MSDN — полное и точное описание всех возможных причин данной ситуаций, а также и рекомендации насчёт того, как её пофиксить.
Вообще то как раз у MSVC всё гораздо печальнее в этом смысле. Т.е. да, номера ошибки по которому можно искать gcc не выдаёт. Но зато MSVC выдаёт такой бред местами, что вообще смешно. Тут как раз недавно коллега на форуме показывал скрин с диким потоком ошибок в VS в ответ на простенькую (специально допущенную для теста) ошибку. Другие компиляторы такого себе не позволяют. Ну а вообще, если главным является не быстродействие, а максимально правильные сообщения об ошибках, то однозначно надо выбирать clang.
_>>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
AG>А что же тогда, по-вашему, является лучшим выбором?
AG>По объективным оценкам...
Ну это смотря по каким критериям. По поддержке стандарта gcc и clang однозначно лучше msvc. По быстродействию генерируемого кода gcc и icc (во всяком случае для десктопа) так же однозначно лучше чем msvc. По сообщениям об ошибках и вообще внутренней архитектуре явно лидер clang. По количеству поддерживаемых платформ явно будет лидером gcc. В общем выбирать есть из чего, только вот msvc не является оптимальным выбором ни по какому сценарию.
Лично мой выбор в данный момент gcc, т.к. для меня актуально быстродействие. Хотя я надеюсь, что clang со временем достаточно продвинется в этом вопросе, чтобы перейти на него. Т.к. концептуально он мне нравится больше.
Да, но главный принцип нормального программиста на C++: его код должен работать нормально на любом компиляторе, заявляющем полную поддержку современного стандарта C++. Тем более, что современные системы сборки тоже позволяют элементарно собирать проекты разными компиляторами. )
