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

_>COM — это всего лишь ABI, а не предметная область. Соответственно если в данной области есть кроссплатформенные библиотеки, то никаких проблем нет.

Здесь вопрос не столько насчёт той либо иной предметной области, сколько в плане GUI компонентов (с которыми для Linux, IMHO, проблемы).

_>Так и не надо специально стараться программировать под Линух (если это конечно не оговорено в ТЗ). Достаточно просто использовать удобные библиотеки, а не вызовы системного API. Кстати, вот у вас же почему-то используется в проекте Qt, а не win api для GUI, не так ли? ) Это же не ради кроссплатформенности (хотя вы её получается при этом автоматом), а ради удобства. Так почему в каких-то других областях должно быть по другому? )

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

_>Хгм))) Отойдя от шока после идеи о применение ocx компонент в проекте на Qt спрошу очевидное: а в чём собственно проблема скомпилировать данное извращение другим (не MSVC) компилятором? )))
Дело в том, что компилятор MSVC поддерживает свои специальные типы данных, предназначенные именно для ActiveX/COM объектов:
https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx (_bstr_t — представление строковых данных);
https://msdn.microsoft.com/en-us/library/0ye3k36s.aspx (_com_error — представление данных об ошибке);
https://msdn.microsoft.com/en-us/library/417w8b3b.aspx (_com_ptr_t — специальные смарт-поинтеры на COM объекты);
https://msdn.microsoft.com/en-us/library/x295h94e.aspx (_variant_t — универсальный тип данных).
Эти все типы (поддерживаемые на уровне компилятора) позволяют создавать легкие и быстрые приложения.
Также MSVC компилятор поддерживает директиву #import — позволяющую импортировать библиотеку типов (ActiveX/COM объект).
Итак, на вопрос — в чем проблема — можно ответить, что если применять, например тот же MinGW, то эти же решения там будут делаться через медленные и неуклюжие "костылики"

_>Стандарт C++ ни в кое мере не запрещает использовать ocx компоненты. )))
Я в курсе

_>А вот использовать не укладывающиеся в стандарт особенности компиляторов (их сейчас становится всё меньше и меньше, но всё же до сих пор встречаются) точно не стоит. )))

Здесь всё не так однозначно.
Если эти особенности компиляторов позволяют создать быстрый (в run-time), компактный, читаемый и хорошо поддерживаемый код, то зачем же отказываться от таких приятных бонусов?

_>Вообще то как раз у MSVC всё гораздо печальнее в этом смысле. Т.е. да, номера ошибки по которому можно искать gcc не выдаёт. Но зато MSVC выдаёт такой бред местами, что вообще смешно. Тут как раз недавно коллега на форуме показывал скрин с диким потоком ошибок в VS в ответ на простенькую (специально допущенную для теста) ошибку. Другие компиляторы такого себе не позволяют. Ну а вообще, если главным является не быстродействие, а максимально правильные сообщения об ошибках, то однозначно надо выбирать clang.
Такие ситуации на MSVC бывают, но весьма редко (можно сказать крайне редко). В то же время, для других компиляторов, где нет идентификатора ошибки, приходится постоянно напрягаться — чтобы понять "Эзопов язык" подсистемы сообщений об ошибках компиляции/линковки.

_>Ну это смотря по каким критериям. По поддержке стандарта gcc и clang однозначно лучше msvc. По быстродействию генерируемого кода gcc и icc (во всяком случае для десктопа) так же однозначно лучше чем msvc. По сообщениям об ошибках и вообще внутренней архитектуре явно лидер clang. По количеству поддерживаемых платформ явно будет лидером gcc. В общем выбирать есть из чего, только вот msvc не является оптимальным выбором ни по какому сценарию.
Если моя пользовательская аудитория — Windows users, то у меня выбор: MSVC или MinGW. При этом первый по быстродействию явно превосходит второй.

_>Лично мой выбор в данный момент gcc, т.к. для меня актуально быстродействие. Хотя я надеюсь, что clang со временем достаточно продвинется в этом вопросе, чтобы перейти на него. Т.к. концептуально он мне нравится больше.
+100500
Здесь спорить не буду: GCC — хороший выбор для Linux систем.

_>Да, но главный принцип нормального программиста на C++: его код должен работать нормально на любом компиляторе, заявляющем полную поддержку современного стандарта C++. Тем более, что современные системы сборки тоже позволяют элементарно собирать проекты разными компиляторами. )
Уважаемый alex_public, так как любое приложение, на любом языке, создаётся прежде всего для ПОЛЬЗОВАТЕЛЯ, то IMHO главный принцып любого программиста должен быть: удобство и комфорт конечного пользователя — превыше всего.

P.S. Очень часто люди, работающие с нашими приложениями, абстрагируются от таких понятий как "компилятор C++", "поддерживаетмый стандарт C++" и т.д.
Эти люди могут даже и не знать таких "матерных" выражений
Тем не менее, это специалисты в своей области и их предложения/требования являются основополагающими на проекте.