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

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

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

_>А вот первое — это уже сложнее и получается без дополнительных усилий только в том случае, если в предметной области имеется достаточное количество удобных кроссплатформенных библиотек. И во многих случаях это именно так и происходит (даже просто Boost + Qt перекрывают огромную область использования OS API), но естественно не для всех. Вот какие конкретно Windows API вам приходится использовать напрямую (без удобных библиотек обёрток), получая тем самым не кроссплатформенное приложение? )
Кроме тех библиотек, которые кроссплатформенные (boost, stl) иногда, стараемся делать это как можно реже, но всё таки кое-где приходится
применять WinAPI вызовы. Это особенно относится к многопоточным реализациям (WaitForSingleObject, WaitForMultipleObjects и т.д.).
Здесь возможно и смогли бы выкрутиться через многопоточность, предусмотренную на C++11, а может и нет. Однозначно тут не скажу.
Точнее — эта та область, где WindowsAPI возможно окажется эффективнее, чем принятые в C++ классы и методы.

_>Верно. Но вы эту кроссплатформенность получили автоматом. Теперь следующий вопрос: почему ты думаешь, что в других частях вашего приложения (не GUI) ситуация другая?
Здесь по-хорошему планируем отделить GUI от вычислительной части (сделать вычислительную часть — как сервер; GUI — как клиент) это в планах.
Во всём остальном — применяется более/менее кроссплатформенные (точнее — потенциально кроссплатформенные вещи).
Как я уже сообщал выше, многопоточность для Windows возможно всё-таки потянет WinAPI (если общепринятые C/C++ решения окажутся менее эффективными). Пока здесь только мои предположения.

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 делают такую замену, потому что она существенно ускоряет сборку проекта (особенно параллельную).
Ниже и привёл ссылку (дуальные интерфейсы) — для чего применяется директива #import (да, её можно заменить и на #include, когда нужные файлы уже сгенерированы, на первом проходе именно она обеспечивает генерацию *.h файлов для компонента).

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

_>А может такое мнение просто от незнания реальности? )
Открываем Qt Creator v 4.2.1, смотрим в меню Help/About — Qt Creator собран на MSVC 2015 (32 bit).
Тот факт, что Qt Creator для Windows, компилируется в MSVC — свидетельствует о реальности очень красноречиво...

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

_>Что-то не припомню не одного подобного случая.
Если посмотреть документацию по ActiveX компонентам, то там явно описан именно тот случай:
http://helpcentral.componentone.com/nethelp/vsflexgrid8/dualinterfacesinmfc1.html
Там приводится пример для MFC, но точно так же можно было привести аналогичный пример для Qt.
Там же описывается и применение директивы #import (как сама техника применения, так и выгода от данной методики).

AG>>Если моя пользовательская аудитория — Windows users, то у меня выбор: MSVC или MinGW. При этом первый по быстродействию явно превосходит второй.
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
Тот факт, что MinGW прогрессирует есть, но насчёт сравнений со студией — тут у меня сомнения (по крайней мере в чистоте экспериментов).

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

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

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

Здесь, конечно же, еще работает и фактор привычки — студия привычна уже почти два десятилетия, всё в ней уже как-бы на автомате делаешь,
в других средах работа проходит медленнее.