Сообщение Re[15]: Школа С++ от UNIGINE от 10.03.2017 13:54
Изменено 10.03.2017 13:56 AlexGin
Re[15]: Школа С++ от UNIGINE
Здравствуйте, alex_public, Вы писали:
_>Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).
+100500
Спасибо, буду в курсе!
_>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.
Можете посоветовать что-то конкретное?
_>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт
Теоретически да...
_>>>А вот это как раз пример вредного (не входящего в стандарт языка, т.е. нарушающего "кросскомпиляторность") расширения от MS, которое не надо использовать. Причём это самое расширение ещё и нечего особенно хорошего не делает: всего лишь генерирует нужные h файлы по заданной tlb и потом включает их в данный файл. Т.е. эта инструкция элементарно заменяется на соответствующие #include (а нужные h файлы генерируются отдельной утилитой, типа genidl из поставки MinGW). Кстати, я слышал что даже многие программисты сидящие на MSVC делают такую замену, потому что она существенно ускоряет сборку проекта (особенно параллельную).
AG>>Ниже и привёл ссылку (дуальные интерфейсы) — для чего применяется директива #import (да, её можно заменить и на #include, когда нужные файлы уже сгенерированы, на первом проходе именно она обеспечивает генерацию *.h файлов для компонента).
_>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?
Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
Применение директивы препроцессора #import:
https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
В данной ветке я уже привёл результаты
Дальнейшее обсуждение данной темы, уважаемый alex_public, мы вполне можем переносить в КСВ.
_>Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).
+100500
Спасибо, буду в курсе!
_>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.
Можете посоветовать что-то конкретное?
_>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт
Теоретически да...
_>>>А вот это как раз пример вредного (не входящего в стандарт языка, т.е. нарушающего "кросскомпиляторность") расширения от MS, которое не надо использовать. Причём это самое расширение ещё и нечего особенно хорошего не делает: всего лишь генерирует нужные h файлы по заданной tlb и потом включает их в данный файл. Т.е. эта инструкция элементарно заменяется на соответствующие #include (а нужные h файлы генерируются отдельной утилитой, типа genidl из поставки MinGW). Кстати, я слышал что даже многие программисты сидящие на MSVC делают такую замену, потому что она существенно ускоряет сборку проекта (особенно параллельную).
AG>>Ниже и привёл ссылку (дуальные интерфейсы) — для чего применяется директива #import (да, её можно заменить и на #include, когда нужные файлы уже сгенерированы, на первом проходе именно она обеспечивает генерацию *.h файлов для компонента).
_>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?
Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
Применение директивы препроцессора #import:
https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
В данной ветке я уже привёл результаты
Автор: AlexGin
Дата: 10.03.17
, доказывающие что MSVC в полтора/два раза эффективнее, нежели MinGW Дата: 10.03.17
Дальнейшее обсуждение данной темы, уважаемый alex_public, мы вполне можем переносить в КСВ.
Re[15]: Школа С++ от UNIGINE
Здравствуйте, alex_public, Вы писали:
_>Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).
+100500
Спасибо, буду в курсе!
_>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.
Можете посоветовать что-то конкретное?
_>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт
Теоретически да... ...это как в анекдоте — чем отличается теория, от практики...
_>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?
Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
Применение директивы препроцессора #import:
https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
В данной ветке я уже привёл результаты
Дальнейшее обсуждение данной темы, уважаемый alex_public, мы вполне можем переносить в КСВ.
_>Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).
+100500
Спасибо, буду в курсе!
_>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.
Можете посоветовать что-то конкретное?
_>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт
Теоретически да... ...это как в анекдоте — чем отличается теория, от практики...
_>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?
Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
Применение директивы препроцессора #import:
https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
В данной ветке я уже привёл результаты
Автор: AlexGin
Дата: 10.03.17
, доказывающие что MSVC в полтора/два раза эффективнее, нежели MinGW Дата: 10.03.17
Дальнейшее обсуждение данной темы, уважаемый alex_public, мы вполне можем переносить в КСВ.