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

_>>COM — это всего лишь ABI, а не предметная область. Соответственно если в данной области есть кроссплатформенные библиотеки, то никаких проблем нет.
AG>Здесь вопрос не столько насчёт той либо иной предметной области, сколько в плане GUI компонентов (с которыми для Linux, IMHO, проблемы).

Вообще у нас тут разговор слегка запутался, т.к. стал затрагивать сразу две разные темы: кроссплатформенную разработку и "кросскомпиляторную". )))

Так вот последнее на мой взгляд должно быть без всяких сомнений, тем более, что сейчас с этим особых проблем нет.

А вот первое — это уже сложнее и получается без дополнительных усилий только в том случае, если в предметной области имеется достаточное количество удобных кроссплатформенных библиотек. И во многих случаях это именно так и происходит (даже просто Boost + Qt перекрывают огромную область использования OS API), но естественно не для всех. Вот какие конкретно Windows API вам приходится использовать напрямую (без удобных библиотек обёрток), получая тем самым не кроссплатформенное приложение? )

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

Верно. Но вы эту кроссплатформенность получили автоматом. Теперь следующий вопрос: почему ты думаешь, что в других частях вашего приложения (не GUI) ситуация другая? )

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

Хы, открываем файлы comutil.h и comip.h в папке include MinGW и видим там все эти типы. )))

AG>Также MSVC компилятор поддерживает директиву #import — позволяющую импортировать библиотеку типов (ActiveX/COM объект).

А вот это как раз пример вредного (не входящего в стандарт языка, т.е. нарушающего "кросскомпиляторность") расширения от MS, которое не надо использовать. Причём это самое расширение ещё и нечего особенно хорошего не делает: всего лишь генерирует нужные h файлы по заданной tlb и потом включает их в данный файл. Т.е. эта инструкция элементарно заменяется на соответствующие #include (а нужные h файлы генерируются отдельной утилитой, типа genidl из поставки MinGW). Кстати, я слышал что даже многие программисты сидящие на MSVC делают такую замену, потому что она существенно ускоряет сборку проекта (особенно параллельную).

AG>Итак, на вопрос — в чем проблема — можно ответить, что если применять, например тот же MinGW, то эти же решения там будут делаться через медленные и неуклюжие "костылики"

А может такое мнение просто от незнания реальности? )

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

Что-то не припомню не одного подобного случая. )

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

Ну лично мне обычно всё понятно. Собственно мне вообще кажется странной идея поиска в инете ошибки компилятора. )

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

Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.

Ну и потом на Windows кроме MinGW и MSVC отлично живут ещё и ICC и Clang (кстати используется в самой MS, правда только как фронтенд).

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

А этот вопрос обычно никак не связан со свойствами итогового приложения. Это влияет скорее на протекание внутренних процессов разработки и только.

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

Ну так если они не в курсе про разные компиляторы C++, то как они могут повлиять на выбор одного из них? Не очень понятно о чём речь вообще.