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

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

Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).

Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.

AG>Точнее — эта та область, где WindowsAPI возможно окажется эффективнее, чем принятые в C++ классы и методы.

Ну на низком уровне то windows реализации всех этих библиотек очевидно используют тоже самое WinAPI, так что по эффективности вряд ли будет какая-то разница — это всё скорее вопрос красоты и лаконичности кода.

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

Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт)

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

Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива? )

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

Хы, а у меня вот QtCreator 64-х битный) И собран GCC. )))

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

Там описана выгода в применение нормального COM по отношению к медленному COM Automation (разработанного для функционирования VB). Только непонятно какое отношение это имеет к применению #import, если ты можешь использовать и нормальный COM и COM Automation без неё.

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

Какое прогрессирует? GCC (а работа оптимизатора связна не с ОС, а с архитектурой процессора) уже лет 10 как намного опережает MSVC. И произошло это по вполне очевидной причине: в начале 2000-ых в MS просто забросили развитие C++ (там буквально отдел поддержки C++ в VS сократился до нескольких человек, выполняющих ритуальные действия), сделав ставку на .Net (если ты помнишь, там же даже ОС будущего планировали писать на C# ). В итоге конкурирующие продукты в начале догнали (всё же на тот момент MS были лидером) продукцию MS, а потом и заметно перегнали. Причём речь шла и о быстродействие и поддержке стандарта (особо убого тут MS стала выглядеть после выхода C++11). И в MS к этому относились спокойно, т.к. у них там была политика партии "будущее за .net". А совсем недавно (несколько лет назад) они опомнились (тут сыграли своё и перестановки в руководстве и популярность мобильных платформ и остановка роста производительности процессоров) и поняли что на самом деле разработка под C++ не просто ещё нужна, но и становится всё более важной. В итоге на развитие C++ были пущены большие силы, что позволило слегка исправить позорное положение дел (во всяком случае главные возможности текущего стандарта стали поддерживаться и быстродействие под х64 стало не совсем смешным). Однако отставание вследствие десятилетия отсутствия работы просто так за один рывок не преодолеваются, так что пока ещё MSVC в отстающих. И именно они заняты попытками догнать, а не наоборот. )))

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

Эээ что? Интеловский — это когда надо максимальную производительность любой ценой. Чаще применяется во всяческих числодробилках и т.п. приложениях.

А что такое "нишевое решение"? ) Clang — это сейчас один из самых чистых фронтендов к C++. В сочетание с LLVM и стандартными библиотеками он даёт полноценный стек C++ компилятора. В MS его используют чуть по другому, со своим бэкендом (вместо LLVM) и своим рантаймом. Ну это их право, однако это не делает Clang каким-то неполноценным решением. )))

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

Если в компании действуют какие-то внутренние стандарты на средства разработки, то понятно что тут нет вопросов — их надо соблюдать. Но если же такого нет и набор инструментов подбирает руководитель проекта, то выбор решения не от MS может быть как раз более удобен в этом смысле (всегда можно подготовить и выложить некий zip архивчик, гарантирующий беспроблемную сборку вашего проекта на любой (в том числе с чистой установкой винды) машине).

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

Ну во-первых вопрос IDE никак не связан с вопросом компилятора. Можно легко работать с gcc в VS (поставив VisualGDB) и легко работать с cl например в QtCreator (или любой другой мощной C++ IDE).

А во-вторых VS для C++ опять же не самая сильная IDE (вследствие описанных выше причин), так что и её выбор сомнителен. Хотя говорят что с выходом ReSharper C++ уже стало вполне ничего, на уровне лучших. Но это получается несколько странно — заплатить деньги, чтобы достичь уровня предлагаемого конкурентами бесплатно. ))) Но если эта IDE так привычна и денег руководству не жалко, то VS+ReSharper является конечно же хорошим решением. Однако оно опять же никак не ограничивает в выборе компилятора. )