Здравствуйте, MTD, Вы писали:
_>>А мне вот не понятно, что там можно разбирать, если всё решение целиком можно записать менее чем в 20 строчек кода (причём это без всяких сторонних библиотек, с поддержкой русского utf8 и работой на всех популярных платформах), которые впечатываются наверное минуты за 3 и даже без включения мозга. ))) MTD>Пожалуйста, покажи код, буду очень признателен.
Здравствуйте, techgl, Вы писали:
T>Мне пришел позитивный ответ от школы. Вот мой вариант, без UTF-8. T>Хотелось бы услышать твое мнение про мой код.
А зачем map хранит слово и в ключе и в значение? ) Так же stringstream очевидно не нужен, т.к. у тебя нет форматирования чего-то в строку (а только добавление символа к ней).
Здравствуйте, AlexGin, Вы писали:
_>>1. Писать сейчас на C++ что-то заточенное под конкретную платформу весьма странно (если конечно же речь не о чём-то совсем системном, типа драйверов). AG> AG>Да, уважаемый alex_public, это именно так, если разрабатывать проекты уровня "Hello world!". AG>Для более-менее средних проектов (я не говорю насчёт крупных) — начинается привязка к системе. AG>В этом случае — кроссплатформенность "ради спортивного интереса" — дело весьма затратное.
А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков? Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
_>>2. ОС установленная у разработчика выбирается исключительно по его личным вкусам (как пользователя ОС, а не как программиста), а не из соображений целевой платформы для разрабатываемого им ПО. Ну а для тестирования разрабатываемого ПО очевидно должно служить множество виртуалок. ) AG> AG>Вот, например, я тимлид команды, в которой разрабатываем проект на Qt под Windows. AG>Я предположил, что в моей рабочей группе, один из девелоперов "по его личным вкусам" поставит Linux и на нем Qt Creator (это его выбор, я не мешаю). AG>Попутно заметим, что у всех остальных, в том числе и у меня, — Qt пакет на MSVC. AG>Внимание вопрос: AG>Заниматься адоптацией gcc <-> MSVC кто будет?
Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? ) Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого кода.
Здравствуйте, techgl, Вы писали:
T>>>3. Использование конкатенации на строке через += MTD>>А это, чем тебе не понравилось? T>Обычно конкатенация в цикле это плохо, я в таком случае использую строковый буфер, он оптимизирован под эту операцию.
Если строка, с которой работают определена вне тела цикла, то это скорее всего будет как раз самый оптимальный вариант. Потому как большинство операций со строкой не затрагивают capacity. Соответственно после первой итерации (и выделения памяти в ней) вся дальнейшая работа скорее всего будет происходить с фиксированным буфером.
А ещё бывает SSO и т.п., но это уже зависит от конкретной реализации. )
Здравствуйте, alex_public, Вы писали:
_>Да легко) Только я говорил что пишется не за 20 минут, а за 3 минуты. )))
Ну тут небольшое лукавство, но код отличный — лаконичный и понятный.
_>P.S. Я не в курсе умеет ли последняя версия убогого продукта от MS работу с utf8 локалями
Не умеет.
_>заменить строчку "locale::global(locale("en_US.UTF-8"));" на две строчки "setlocale(LC_ALL, ""); locale::global(locale(locale(), new codecvt_utf8<wchar_t>));".
Здравствуйте, alex_public, Вы писали:
_>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков?
Обычно, чем больше объём , тем больше вероятности того, что потребуется что-то специфическое.
Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
_>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале.
В ТЗ не заявлено ничего по данному поводу
По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
_>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? )
OK!
Вот мне нужно отобразить древовидную таблицу (иерархический грид):
Я применяю вот это (ComponentOne VsFlexGrid8): http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
Теперь насчет именно адаптации по gcc: прежде всего, меня раздражает, что в нём, при ошибке компиляции выдается скупой и зачастую малоинформативный короткий текст. Найти истинную причину (даже днём с огнёмпри помощи гугла) очень трудно
На MSVC выдаётся код ошибки, (например C2259) и далее в MSDN — полное и точное описание всех возможных причин данной ситуаций, а также и рекомендации насчёт того, как её пофиксить.
_>Если так, то это не верный подход. Ориентироваться следует исключительно на стандарт языка.
Когда у Вас, уважаемый alex_public, появится Заказчик, Вы будете ориентироваться исключительно на его требования.
_>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого.
А что же тогда, по-вашему, является лучшим выбором?
По объективным оценкам...
Здравствуйте, MTD, Вы писали:
_>>заменить строчку "locale::global(locale("en_US.UTF-8"));" на две строчки "setlocale(LC_ALL, ""); locale::global(locale(locale(), new codecvt_utf8<wchar_t>));".
MTD>:up:
`codecvt_utf8` вроде как deprecated в последней редакции Стандарта.
На сайте набор окончен, тестовое задание не вижу где скачать. Судя по решениям, там надо работать с Юникодом. На всякий случай напомню, что могут быть тонкости типа «Turkey İ Problem» или «Σ → σ, ς».
Здравствуйте, AlexGin, Вы писали:
_>>А какая вообще связь между размером проекта и появлением в нём не кроссплатформенных кусков? AG>Обычно, чем больше объём , тем больше вероятности того, что потребуется что-то специфическое.
Сомнительно. Скорее это определяется предметной областью.
AG>Кроме того, если предполагается MSVC проект (под целевую Windows), очень велика вероятность применения ActiveX (COM) etc.
COM — это всего лишь ABI, а не предметная область. Соответственно если в данной области есть кроссплатформенные библиотеки, то никаких проблем нет. Например та же SDL вполне себе работает на винде через DirectX (который как известно реализован через COM). При этом если программисту хватает для его целей возможностей SDL, то ему абсолютно не важно через что оно там реализовано на низком уровне.
_>>Последнее обычно появляется исключительно вследствие необходимости использования функций ОС, для которых нет удобных кроссплатформенных библиотек-обёрток. В этом случае или пишется своя вариация под каждую платформу (если у нас в ТЗ заявлена поддержка многих платформ) или же вот появляется такой некроссплатформенный кусок. Но с размером проекта это никак не связано, а является исключительно следствием потребности в специфическом функционале. AG>В ТЗ не заявлено ничего по данному поводу AG>По-умолчанию подразумевается Windows, затраты на разработку под Linux — НЕ смогут окупиться
Так и не надо специально стараться программировать под Линух (если это конечно не оговорено в ТЗ). Достаточно просто использовать удобные библиотеки, а не вызовы системного API. Кстати, вот у вас же почему-то используется в проекте Qt, а не win api для GUI, не так ли? ) Это же не ради кроссплатформенности (хотя вы её получается при этом автоматом), а ради удобства. Так почему в каких-то других областях должно быть по другому? )
_>>Что такое "адаптация gcc <-> MSVC"? Или вы пишете не под стандарт языка, а под конкретный компилятор? ) AG>OK! AG>Вот мне нужно отобразить древовидную таблицу (иерархический грид): AG>Image: VsFlexGrid8_1.jpg AG> Я применяю вот это (ComponentOne VsFlexGrid8): AG>http://helpcentral.componentone.com/nethelp/vsflexgrid8/componentonevsflexgridpro8.html
Хгм))) Отойдя от шока после идеи о применение ocx компонент в проекте на Qt спрошу очевидное: а в чём собственно проблема скомпилировать данное извращение другим (не MSVC) компилятором? )))
AG>Вопрос — неужели ради строгого следования стандарту C++ (что конечному пользователю вообще-то фиолетово), мне следует отказаться от этого?
Стандарт C++ ни в кое мере не запрещает использовать ocx компоненты. ))) А вот использовать не укладывающиеся в стандарт особенности компиляторов (их сейчас становится всё меньше и меньше, но всё же до сих пор встречаются) точно не стоит. )))
AG>Теперь насчет именно адаптации по gcc: прежде всего, меня раздражает, что в нём, при ошибке компиляции выдается скупой и зачастую малоинформативный короткий текст. Найти истинную причину (даже днём с огнёмпри помощи гугла) очень трудно AG>На MSVC выдаётся код ошибки, (например C2259) и далее в MSDN — полное и точное описание всех возможных причин данной ситуаций, а также и рекомендации насчёт того, как её пофиксить.
Вообще то как раз у MSVC всё гораздо печальнее в этом смысле. Т.е. да, номера ошибки по которому можно искать gcc не выдаёт. Но зато MSVC выдаёт такой бред местами, что вообще смешно. Тут как раз недавно коллега на форуме показывал скрин с диким потоком ошибок в VS в ответ на простенькую (специально допущенную для теста) ошибку. Другие компиляторы такого себе не позволяют. Ну а вообще, если главным является не быстродействие, а максимально правильные сообщения об ошибках, то однозначно надо выбирать clang.
_>>P.S. И да, MSVC сейчас явно не является лучшим выбором. Ни по поддержке стандарта, ни по быстродействию получаемого. AG>А что же тогда, по-вашему, является лучшим выбором? AG>По объективным оценкам...
Ну это смотря по каким критериям. По поддержке стандарта gcc и clang однозначно лучше msvc. По быстродействию генерируемого кода gcc и icc (во всяком случае для десктопа) так же однозначно лучше чем msvc. По сообщениям об ошибках и вообще внутренней архитектуре явно лидер clang. По количеству поддерживаемых платформ явно будет лидером gcc. В общем выбирать есть из чего, только вот msvc не является оптимальным выбором ни по какому сценарию.
Лично мой выбор в данный момент gcc, т.к. для меня актуально быстродействие. Хотя я надеюсь, что clang со временем достаточно продвинется в этом вопросе, чтобы перейти на него. Т.к. концептуально он мне нравится больше.
Да, но главный принцип нормального программиста на C++: его код должен работать нормально на любом компиляторе, заявляющем полную поддержку современного стандарта C++. Тем более, что современные системы сборки тоже позволяют элементарно собирать проекты разными компиляторами. )
Здравствуйте, Qbit86, Вы писали:
_>>>заменить строчку "locale::global(locale("en_US.UTF-8"));" на две строчки "setlocale(LC_ALL, ""); locale::global(locale(locale(), new codecvt_utf8<wchar_t>));". MTD>> Q>`codecvt_utf8` вроде как deprecated в последней редакции Стандарта.
Ну пока что нет (пока последняя редакция C++14), но в ближайшем будущем (с выходом C++17) скорее всего так и будет.
Q>На сайте набор окончен, тестовое задание не вижу где скачать. Судя по решениям, там надо работать с Юникодом.
Там было предложено сделать частотный словарь по некому английскому тексту. И предлагались дополнительные бонусы за поддержку русского текста в utf8. )))
Q>На всякий случай напомню, что могут быть тонкости типа «Turkey İ Problem» или «Σ → σ, ς».
Да, это известные проблемы. Которые полностью решаются использованием Boost.locale (скомпилированной с поддержкой icu). Однако в данном примере оно неактуально сразу по двум причинам: там требовался только русский язык и там были запрещены сторонние библиотеки (даже Boost). А так, если делать этот пример по взрослому (для любого языка и с возможностью использования Boost'a), то он выглядел быть чуть по другому, хотя и не сильно длиннее.
Здравствуйте, 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++" и т.д.
Эти люди могут даже и не знать таких "матерных" выражений
Тем не менее, это специалисты в своей области и их предложения/требования являются основополагающими на проекте.
Здравствуйте, 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++, то как они могут повлиять на выбор одного из них? Не очень понятно о чём речь вообще.
Здравствуйте, 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++, то как они могут повлиять на выбор одного из них? Не очень понятно о чём речь вообще.
В основном влияние косвенное, но это не означает, что влияния нет вообще
Здесь, конечно же, еще работает и фактор привычки — студия привычна уже почти два десятилетия, всё в ней уже как-бы на автомате делаешь,
в других средах работа проходит медленнее.
Здравствуйте, AlexGin, Вы писали:
>Если моя пользовательская аудитория — Windows users, то у меня выбор: MSVC или MinGW. При этом первый по быстродействию явно превосходит второй.
Здравствуйте, alex_public, Вы писали:
_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.
Парни, ну дайте хоть посмотреть, что за тесты и какие результаты?
А то как-то некрасиво получается...
Мне вот тоже интересно, кто же быстрее (и в каких случаях) — MS C/C++ Compiler или MinGW.
Здравствуйте, 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 является конечно же хорошим решением. Однако оно опять же никак не ограничивает в выборе компилятора. )
P.P.S. Теперь ясно, почему же среда разработки Qt Creator для Windows попадает к нам откомпилированной (авторами из независимой Qt Company), именно на таком "ненавистном" MSVC...
O>>Мне вот тоже интересно, кто же быстрее (и в каких случаях) — MS C/C++ Compiler или MinGW.
AG>Мои тесты производительности, разработанные окло года назад (вычисления по int числам, double числам и тригонометрия) — здесь: AG>https://github.com/AlexGin/Math/blob/master/mainwindow.cpp
А если убрать из теста обращение к гуёвым методам?
...
if (!(i % 100000))
{
int val = ui->progressBar->value();
ui->progressBar->setValue(++val);
}
...
Какие будут результаты?
Мне тоже любопытно, но mingw у меня не установлено.
_____________________
С уважением,
Stanislav V. Zudin
). В итоге конкурирующие продукты в начале догнали (всё же на тот момент MS были лидером) продукцию MS, а потом и заметно перегнали. Причём речь шла и о быстродействие и поддержке стандарта (особо убого тут MS стала выглядеть после выхода C++11). И в MS к этому относились спокойно, т.к. у них там была политика партии "будущее за .net". А совсем недавно (несколько лет назад) они опомнились (тут сыграли своё и перестановки в руководстве и популярность мобильных платформ и остановка роста производительности процессоров) и поняли что на самом деле разработка под C++ не просто ещё нужна, но и становится всё более важной. В итоге на развитие C++ были пущены большие силы, что позволило слегка исправить позорное положение дел (во всяком случае главные возможности текущего стандарта стали поддерживаться и быстродействие под х64 стало не совсем смешным). Однако отставание вследствие десятилетия отсутствия работы просто так за один рывок не преодолеваются, так что пока ещё MSVC в отстающих. И именно они заняты попытками догнать, а не наоборот. )))
