в общем проблему с производительностью я понял — да, виноват msys . но учитывая, что сам по себе mingw без msys не полный инструмент (крос-платформенные библиотеки в чистом mingw не соберутся, нужно конфигурирование и т.п.), тормоза msys накладывают отпечаток на мнение об mingw .

ну и прошу понять правильно. я не говорю, что mingw плохой. в нем есть недостатки, как и во всем другом.

зы. я сильно ждал VC++ 2013, чтобы перейти в привычную среду и получить часть новых плюшек с++11. но ведь они, редиски, сломали код который работал в 2012 (http://connect.microsoft.com/VisualStudio/feedback/details/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable#) . так что gcc пока что лучший друг -)

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

C>и виной тут не gcc сам по себе, а его прослойка mingw.
да, а как вы определили, что тормозит mingw?

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

C>в общем проблему с производительностью я понял — да, виноват msys . но учитывая, что сам по себе mingw без msys не полный инструмент (крос-платформенные библиотеки в чистом mingw не соберутся, нужно конфигурирование и т.п.), тормоза msys накладывают отпечаток на мнение об mingw.
во-первых — если рассуждать по вашему — то при использовании любого компилятора в паре с msys, то отпечаток будет наложен абсолютно на любой компилятор. ну ладно, если бы только компилятор — так любая программа которую можно использовать с msys — так же будет "отпечатана" в тормозливости. что-то тут не правильно, не находите?

во-вторых — эти два проекта между собой не имеют ничего общего. mingw — нативный компилятор для win платформы, а msys — эмулятор POSIX среды.

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

X>и вот, три человека, в течении месяца, полный рабочий день занимаются только поисками этих багов. по истечении месяца стало понятно, что ничего найти не получается. стандартные средства типа отладчика и стек-трейсера никак не помогают, а только путают. так же опробован valgrind, который, к слову, тоже только "голову морочил". не для плюсового кода он, однако.

То что в твоём конкретном случае valgrind не помог — не говорит о том что он плох. С некоторыми use-case'ами он справляется на отлично.
Также, помимо "problem"-detector, там есть полезные утилиты типа Massif.

X>и вот, как последняя надежда, решили попробовать AddressSanitizer, который был включен в gcc-4.8.х(так же был добавлен и ThreadSanitizer, но его пока не приходилось опробовать), и, с его помощью, за один день пофиксили баги.

И что характерно: и AddressSanitizer и ThreadSanitizer — оба на базе LLVM/Clang. А ты говоришь зачем он нужен

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

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

C>>и виной тут не gcc сам по себе, а его прослойка mingw.
X>да, а как вы определили, что тормозит mingw?

не правильные причинно-следственные связи . в винде gcc тормозит. на линуксе — летает -)

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

EP>То что в твоём конкретном случае valgrind не помог — не говорит о том что он плох.
в сравнении с AddressSanitizer — он плох.

EP>И что характерно: и AddressSanitizer и ThreadSanitizer — оба на базе LLVM/Clang. А ты говоришь зачем он нужен
я не говорил, что он не нужен. я лишь говорил, что он вряд ли оправдает те надежды, которые Абикс на него возлагает.

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

C>в винде gcc тормозит. на линуксе — летает -)
враки же. иначе приведите пример.

я когда-то сравнивал время сборки на венде и линуксе. разница была крайне не существенна.

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

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

C>>в винде gcc тормозит. на линуксе — летает -)
X>враки же. иначе приведите пример.

я же написал — неверные причинно-следственные связи. пример был в первом моем сообщение — icu + xerces-c
и вроде уже пришли к выводу — мешает msys.

у меня нет достаточно большого проекта для проверки. а данные примеры без msys не соберутся.

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

DE>>Вот (который с 2010 студией идёт).
X>как написано в самом sal.h: "sal.h provides a set of annotations to describe how a function uses its parameters — the assumptions it makes about them, and the guarantees it makes upon finishing." — т.е. это макросы, использующие в описании API. таким образом, они по логике не должны перетекать в пользовательский код.
X>так что да, если mingw-w64 в описании API не использует часть этих макросов, то его содержание может отличаться.
Почему не должны? Встречал, код где тоже параметры отмечались как _In_, _Out_ и т.д. Смысла может и нет, но и запрета ведь нет тоже.

Кстати, "_Inout_" как раз отсутствует.

Как-то пропустил эту темку, поэтому напишу в одном сообщение сразу все комментарии, которые возникли после её прочтения.

1. Clang потенциально имеет киллер-фичу — это выдача полноценной информации о коде наружу. Т.е. не компиляция, а парсинг. Потенциально это позволяет добавить в любой удобный редактор удобные возможности типа полноценного контекстного автодополнения, подсветки, рефакторинга и т.п., которые в данные момент являются уделом всего 3-ёх монструозных IDE. Потенциально, потому что на практике это ещё до конца не работает. Т.е. уже есть различные плагины к популярным редакторам, работающие на этих принципах, но пока они действуют только для простейшего кода. А на сложных библиотеках начинают тормозить и виснуть. Однако в потенциале это может быть прорыв для C++.

2. Clang в данный момент (ну точнее отвечаю за состояние на весну этого года) ещё не подходит для разработки под винду. Ну т.е. вообще — просто не может осилить сборку в некоторых случаях. )))



3. У MingGW действительно не всё в порядке с виндовыми заголовками. Встречаются (хотя и не часто) пробелы или проблемы (например когда библиотека рассчитана только или на linux&gcc или на win&msvc). Однако они все вполне исправимы руками и не то что бы очень долго (1 человеко-день на пересборку десятка сложнейших библиотек).

4. У MinGW есть ещё и не обсуждённые здесь проблемы, типа проблем в реализации базовой библиотеки. Например поддержка кодовых страниц и соответственно проблемы из-за этого в потоках ввода/вывода. Я уже молчу про использование древней библиотеки от msvc. Так что там ещё горы работы по доведению его до нормального состояния. Однако на мой взгляд пользоваться можно уже прямо сейчас, причём по многим пунктам он обходит всех своих конкурентов.



5. Странно слышать про невозможность использовать какую-то IDE с каким-то компилятором. Вообще говоря по нормальному процесс сборки не должен быть вообще никак завязан ни на используемый компилятор, ни на IDE, ни на ОС. И соответственно тогда мы спокойно используем любой компилятор в любой ide. Помнится в начале мы ушли с VS, но продолжали использовать cl. А какое-то время назад ушли и с cl, т.к. достало обходиться без удобных возможностей современного языка. При этом в процесс сборки считай что не пришлось вносить вообще никаких изменений. Сейчас могли бы спокойно вернуться на редактор VS+VA (если бы Netbeans не умел бы работать с кодом лучше) и для этого не пришлось бы менять компилятор.

6. Странно слышать мнения, что отладка (в смысле работы с отладчиком, а не вообще) сильнее логирования... Очевидно же, что как раз наоборот (если конечно у нас есть исходники, а мы не пытаемся поломать чужой софт ), т.к. логирование можно применить почти к любому коду, а вот отладке много чего не поддаётся. Главное преимущество отладчика в том, что он чуть быстрее — с ним не надо тратить время на расстановку точек выдачи отладочной информации. Однако на мой взгляд это не особо ценное преимущество, тем более что у больших проектов всё равно время пересборки не слабое...

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

DE>Почему не должны? Встречал, код где тоже параметры отмечались как _In_, _Out_ и т.д. Смысла может и нет, но и запрета ведь нет тоже.
если размышлять по-вашему, то и использование 'boost::asio::detail::increment()' в своем коде — является нормальным.

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

_>1. Clang потенциально имеет киллер-фичу — это выдача полноценной информации о коде наружу. Т.е. не компиляция, а парсинг.
GCC это тоже умеет при помощи плагинов.

_>3. У MingGW действительно не всё в порядке с виндовыми заголовками. Встречаются (хотя и не часто) пробелы или проблемы (например когда библиотека рассчитана только или на linux&gcc или на win&msvc). Однако они все вполне исправимы руками и не то что бы очень долго (1 человеко-день на пересборку десятка сложнейших библиотек).
чтоб не пришлось постоянно что-то фиксить руками — нужно репортовать разработчикам

_>4. У MinGW есть ещё и не обсуждённые здесь проблемы, типа проблем в реализации базовой библиотеки. Например поддержка кодовых страниц и соответственно проблемы из-за этого в потоках ввода/вывода.
о чем речь? есть ли пример, демонстрирующий проблему?

_>Я уже молчу про использование древней библиотеки от msvc.
вы про msvcrt.dll?

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

X>чтоб не пришлось постоянно что-то фиксить руками — нужно репортовать разработчикам
ну или мне.

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

NB>опыта работы в больших компаниях не имею
это наверно главное

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

X>GCC это тоже умеет при помощи плагинов.

Ммммм, а точно умеет именно тоже самое? ) А то я во все эти нюансы не вникал, но вижу что существует уже множество плагинов к редактором и ide (sublime, emacs, vim, Kate, CodeLite и т.п.) основанных на clang'e и при этом не слышал вообще ни про один подобный плагин основанный на gcc...

X>чтоб не пришлось постоянно что-то фиксить руками — нужно репортовать разработчикам

Нуу там много по мелочам. К примеру speech api помнится нет. Потом какие-то библиотеки использовали эти самые сомнительные макросы из sal.h. Понятно что они все вырезаются из кода одной операцией, но это как бы тоже не дело. Да, кстати, самое забавное что если вставить sal.h из windows sdk, то там один из макросов конфликтует с каким-то формальным параметром в библиотеке потоков, так что всё работает только если вставлять его везде в заголовка после iostream. В общем веселье в полный рост, но всё по каким-то незначительным мелочам, которые в итоге правятся через глобальную замену.

X>о чем речь? есть ли пример, демонстрирующий проблему?

А как раз про это я уже давным давно писал здесь: http://www.rsdn.ru/forum/cpp.applied/5210748.flat#5210748

Автор: alex_public
Дата: 25.06.13

X>вы про msvcrt.dll?

Именно)

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

NB>>опыта работы в больших компаниях не имею
V>это наверно главное

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

Ну, вы знаете, я вот в свое время на спектруме обходился в ассемблере GENS кошмарнейшим редактором (он был однострочный!) и тоже без дебаггера. Однако это вовсе не означает что это есть хорошо.
Дебаггер — это отличнейшее подспорье в работе. Хотя никто не утверждает, что это единственный инструмент отладки, т.к. логи очень полезны на живом работающем коде, куда ни IDE, ни отладчик не установишь (даже remote debugger, в случае msvc).
Так что каждый инструмент полезен...

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

T>Ну, вы знаете, я вот в свое время на спектруме обходился в ассемблере GENS кошмарнейшим редактором (он был однострочный!) и тоже без дебаггера. Однако это вовсе не означает что это есть хорошо.
T>Дебаггер — это отличнейшее подспорье в работе. Хотя никто не утверждает, что это единственный инструмент отладки, т.к. логи очень полезны на живом работающем коде, куда ни IDE, ни отладчик не установишь (даже remote debugger, в случае msvc).

черт, опять религиозный вопрос затронул
сойдемся на том, что каждому свое

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

_>6. Странно слышать мнения, что отладка (в смысле работы с отладчиком, а не вообще) сильнее логирования... Очевидно же, что как раз наоборот (если конечно у нас есть исходники, а мы не пытаемся поломать чужой софт ), т.к. логирование можно применить почти к любому коду, а вот отладке много чего не поддаётся. Главное преимущество отладчика в том, что он чуть быстрее — с ним не надо тратить время на расстановку точек выдачи отладочной информации. Однако на мой взгляд это не особо ценное преимущество, тем более что у больших проектов всё равно время пересборки не слабое...

Не странно.

Отладка — это не только возможность посмотреть последовательность выполнения и значения переменных.
Это ещё возможность изменять переменные, изменять последовательность выполнения (например, повторять уже выполненный код), и даже изменять выполняемый код без пересборки.

Да даже если только смотреть значения переменных, вот залогировали что-то, оказалось, не всё, что нужно, придётся дописывать логирование, а "время пересборки у больших проектов не слабое".

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

AG>Не странно.

AG>Отладка — это не только возможность посмотреть последовательность выполнения и значения переменных.
AG>Это ещё возможность изменять переменные, изменять последовательность выполнения (например, повторять уже выполненный код), и даже изменять выполняемый код без пересборки.

AG>Да даже если только смотреть значения переменных, вот залогировали что-то, оказалось, не всё, что нужно, придётся дописывать логирование, а "время пересборки у больших проектов не слабое".

Ну так я это и сказал, что преимущество в скорости. Но это только в тех случаях, когда вообще применима отладка. Для многопоточного или реалтайм кода она вообще ни о чём становится... )