[ann] Visual C++ Compiler November 2013 CTP - C/C++

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

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

S>>>Ну и вообще, нельзя быть таким категоричным, вот чужой код, это чей?

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

S>Ну и к чему тогда было заявление про логирование, которого в теории хватает, но на практике за чередой всевозможных "если", кейс с достаточностью одного лишь логирования никогда не выполняется?

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

gcc-4.9 развивается весьма шустро. даже полиморфные лямбды реализовали. релиз намечается на март 2014. как заявляют разрабы, в этом релизе будет полная поддержка C++14.

список уже проделанного можно увидеть тут:
http://gcc.gnu.org/gcc-4.9/changes.html

кстати, в следующем году истекает патент на SEH. так что мингв станет поддерживать SEH и на 32ух битах. наконец-то можно будет избавиться от SJLJ/DWARF.
(поддержка SEH для 32ух бит — уже запилена, если что. просто отключена, чтоб не ничего не нарушать.)

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

A>>и можно будет благополучно забыть про mingw.
X>оно будет хуже мингва, по ряду причин, которые, как мне кажется, они не будут спешить исправлять.
X>а что таки с мингвом не так? само название не нравится?

Отладчик. Ужасный тормознутый отладчик, который выполняет элементарные действия минутами(!) или вообще зависает.
Возможно, я не умею с ним работать (работаю из qt creator). Но даже на примитивных проектах оно тормозит и когда я пытаюсь пройти по шагам простейший код, иногда между шагами такие паузы, что qt creator'y надоедает ждать и он выводит соответствующее сообщение

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

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

X>gcc-4.9 развивается весьма шустро.

clang тоже. надеюсь они таки портируют libc++ под винду, и можно будет благополучно забыть про mingw.
только тема не про это.

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

A>>для разработки под Windows нужны расширения компилятора, а в mingw всех нужных расширений нет.
X>о чем речь?
примерно о всем чем cl.exe отличается от g++.exe . начиная от поведения catch(...) и заканчивая интеропом с .NET

A>>по пунктам:
A>>- моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
X>это твой недостаток, не не мингва.
тебе бы софт для юзеров пописать, ты бы им рассказывал что проблемы юзабитили это проблемы юзеров

A>>- я не могу собрать mingw мой код который использует библиотеку "X", расширение С++ "Y", код на C++/CLI (внезапно в реальном мире оказывается есть легаси код)
X>опять же, это твой недостаток, и недостаток твоего кода. зачем писать непереносимый код? в чем смысл?
ты следующий раз до конца строчку читай, и то что в скобках тоже читай.
"легаси код" — это не код написанный лично мной. это код 10 лет назад написанный индийским подразделением компании, и разрабами китайской компании-партнера.

A>>- предупреждения сделаны неюзабельно (я не хочу писать скобки в A|B&C)
X>на то есть причины, думаю я. вряд ли msvc хоть в чем-то лучше соответствует стандарту.
при чем тут стандарт? это *предупреждение*. в VC++ есть похожее предупреждение, только они наверное считают что разработчик должен знать порядок выполнения операций & и | так же как он знает порядок * и +

A>>- niXman говорит что у кланга нет своего рантайма, тогда почему mingw юзает доисторическую версию Microsoft Visual C++ Runtime?
X>C-runtime, не С++.
ты вообще смотрел что там есть? или в Си появились исключения и RTTI?
X>я уже объяснял неоднократно %)
сначала разберись с матчастью, потом объясняй
X>1. вот я только что посмотрел список зависимостей explorer.exe в win7, и там оказалась msvcrt.dll. так как же так получается, что не самая старая версия венды, юзает "доисторическую версию" msvcrt.dll ?
а версию компилятора, которым собирали explorer.exe в win7 — смотрел?
X>2. msvcrt.dll не предоставляет необходимого compiler-intrinsics, который нужен, сам знаешь для чего.
я хз о чем ты, но intrinsics это не часть рантайма, это intrinsics

A>>- код компилируется медленно
X>ну да, слышал уже неоднократно)
X>намного медленнее?
чем что, чем кланг? хз. у меня большие проекты только VC++ собираются

A>>- где .pdb? где post-mortem отладка?
X>там же, где и у шланга. врятли оно когда-нибудь появится.
в D как-то появилось.

X>>> большая часть тулчейна основанного на clang будет использовать компоненты написанные такими проектами как gcc/mingw-w64/binutils/gdb/etc
A>>- нафига мне этот gdb если мне нужен отладчик и надо собирать крешдампы с юзеров?
X>по правде сказать, я не копал в этом направлении, и, признаться, не уверен что это такое... это типа core-dump`ов?
это такая штука, которая тебе понадобилась бы, если бы ты писал closed-source код для юзеров. какой-нить небольшой проект типа фаерфокса, с миллионами юзеров. он бы у них падал, юзеры бы тебя засыпали багрепортами, а ты бы им говорил — ой ребята, а я хз как вам помочь, но зато у меня код собирается mingw!

A>>- mingw так же как и D — вроде он и есть, и уже много лет есть, а юзать его почему-то никто не хочет
X>ты живешь в своем, выдуманом мирке...
конечно я всё это выдумал.

X>посмотри хотя бы сюда:
X>http://mingw-w64.sourceforge.net/
X>табличку видишь? не могу найти правильную ссылку на полную таблицу. и еще большая присутствует на сайте старого мингва.
и это... всё?
я уже упоминал фаерфокс, и вот почему-то я его там не вижу. и хромиума не вижу. и я вот игры иногда играю, они тоже все почему-то собираются VC++. акробаты всякие с фотошопами — ну ты понял, да?
вообще есть какая популярная крупная виндовая программа которая юзает mingw?

A>>- дальше я забыл, но суть в том, что у меня есть куча проектов, и я либо не могу использовать mingw, либо использование mingw значительно снизит продуктивность работы/усложнит ALM
X>опять же — это твои личные недостатки.

знаешь, я тут успел немного поработать С++ программистом в нескольких конторах, недавно вот еще по собеседованиям походил, и представляешь, почему-то нигде не юзают mingw. наверное это заговор!

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

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

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

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

Не странно.

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

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

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

EP>Я видел случаи где Clang оптимизировал лучше GCC, например.
отрепортовал. исправят.

A> (Proposed for C++17) Resumable functions and await

Эта штука у них спорная получилась. Надо будет кинуть в [std-proposals] сравнение pros/cons с этим.
Например они предлагают помечать функции keyword'ом:

future<int> abs(future<int> i_op) resumable
{
    int i = await i_op;
    return (i < 0) ? -i : i;
}

крайне спорный вариант (особенно учитывая то что, как я понял, они у них stackful), да и keyword для await тоже особо не нужен.
Например C++11 потоки могут работать с любыми функциями, без дополнительных ~~buzz~~keyword'ов, их не надо никак дополнительно помечать, хотя по смыслу потоки такие же resumable. Дополнительное разделение функций по сути является усложнением языка — часть функций resumable, часть нет.
В общем моё ИМХО: stackful coroutine должны иметь "library-only" интерфейс, близкий к Boost.Coroutine.

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

X>просто мне непонятны мечтания об использовании clang...

В смысле? Clang потихоньку начинает поддерживать Microsoft Extensions, и соответственно начинает прожевывать всякие win-spefic header'ы — в итоге может вырасти полноценная замена MSVC

X>большая часть тулчейна основанного на clang будет использовать компоненты написанные такими проектами как gcc/mingw-w64/binutils/gdb/etc... так а зачем в этом случае clang?

Во-первых, Clang здорово расшевелил всю эту тусовку (например) — это несомненно плюс.
Во-вторых, Clang предоставляет адекватный интерфейс для создания утилит. А в GCC (слайды 6-7):

“... is there a reason for not making the [GCC] front ends dynamic libraries which could be linked by any program that wants to parse source code?”
“One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage...” — Richard Stallman

В-третьих, чем больше разных реализаций, тем быстрее находятся всякие неоднозначности в стандарте.
В-четвёртых, Clang изначально заточен под LLVM, и соответственно прекрасно дружит с проектами которые работают с LLVM (например компиляция Clang++ -> LLVM -> JavaScript). А вот на каком уровне поддержка LLVM у GCC я не знаю

X>или это типа как в мире линукс дистрибутивов: 100 дистров, и ни одного хорошего?

Clang это не просто косметическая переделка как большинство дистрибутивов Linux. Если использовать такое сравнение, то Clang это скорее новое ядро(а-ля GNU Hurd), которых намного меньше чем дистрибутивов.

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

X>и еще несколько мыслей.
X>1. не вижу смысла использовать инструмент, который привязывает тебя к платформе. как и писать код, привязанный к платформе. по крайней мере, у меня такого в жизни не случалось, хоть я и работаю с linux/bsd/qnx.
всё зависит от задачи.
для каких-то задач можно позволить себе писать кроссплатформенный код.
для других задач, писать кроссплатформенный бессмысленно. неоправданно дорого, сложно и неэффективно.
представь что тебе надо написать ActiveX компонент к Internet Explorer. который должен в фоне скачиваться/обновляться. часть юзеров сидит в африке и у них медленно модемное соединение, а другие юзеры юзают 2G-интернет от слоуфона.
и ты внезапно понимаешь, что например использование платформозависимой функции UrlDownloadToFile является лучшим решением, чем пихать в бинарник 500Кб boost.asio и ее зависимостей.

X>2. признаюсь, но среди моих знакомых нет никого, кто бы использовал msvc. наверное, что-то в наших с тобой жизнях пошло по разным направлениям.
дело не в тебе и во мне,
дело в том что есть такой факт — под виндой сидит больше половины пользователей, и кто-то пишет для них софт, и это делается на С++, и это делается в MSVS.
то что среди твоих знакомых нет таких людей, это не отменяет того факта, что например есть Google Chrome, и что его компилят VC++2010.

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

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

A>примерно о всем чем cl.exe отличается от g++.exe . начиная от поведения catch(...) и заканчивая интеропом с .NET
так а зачем использовать такие, непереносимые технологии?
это тоже самое, как и ругать GCC за то, что он предоставляет свои расширения, которые не поддерживают другие компиляторы. нелогично же?

A>тебе бы софт для юзеров пописать, ты бы им рассказывал что проблемы юзабитили это проблемы юзеров
при чем тут среда разработки, и юзабилити конечного продукта?
есть кросплатформенные библиотеки/фреймворки, предоставляющие возможность писать переносимый GUI. или речь не об этом?

A>ты следующий раз до конца строчку читай, и то что в скобках тоже читай.
да, прости.

A>"легаси код" — это не код написанный лично мной. это код 10 лет назад написанный индийским подразделением компании, и разрабами китайской компании-партнера.
опять же — чем виноват мингв?

A>>>- niXman говорит что у кланга нет своего рантайма, тогда почему mingw юзает доисторическую версию Microsoft Visual C++ Runtime?
X>>C-runtime, не С++.
A>ты вообще смотрел что там есть? или в Си появились исключения и RTTI?
я знаю что там есть, но тем не менее оно зовется C-runtime, ибо есть действительно C++-runtime, и зовется — msvcp*.dll

A>а версию компилятора, которым собирали explorer.exe в win7 — смотрел?
я не знаю, как.

A>я хз о чем ты, но intrinsics это не часть рантайма, это intrinsics
все ты понял, не прикидывайся. (или просто придираешься к словам.(ничего другого похоже не получается.))

A>чем что, чем кланг? хз. у меня большие проекты только VC++ собираются
да, чем шланг.
ну если ты не пытался сравнивать, зачем тогда приводить такой аргумент?

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

A>это такая штука, которая тебе понадобилась бы, если бы ты писал closed-source код для юзеров. какой-нить небольшой проект типа фаерфокса, с миллионами юзеров. он бы у них падал, юзеры бы тебя засыпали багрепортами, а ты бы им говорил — ой ребята, а я хз как вам помочь, но зато у меня код собирается mingw!
да, похоже ты про core-dumps.

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

A>и хромиума не вижу.
хромиум вроде не собирается. по крайней мере, я об этом не слышал.

A>и я вот игры иногда играю, они тоже все почему-то собираются VC++.
я тоже иногда играю, и некоторые из них собраны мингвом.

A> акробаты всякие с фотошопами — ну ты понял, да?
наверное просто лень допиливать код для поддержки другого компилятора? ну, или, как ты раньше писал, может используют что не переносимое...

A>вообще есть какая популярная крупная виндовая программа которая юзает mingw?
я хз — я не особо пользую венды...

A>знаешь, я тут успел немного поработать С++ программистом в нескольких конторах, недавно вот еще по собеседованиям походил, и представляешь, почему-то нигде не юзают mingw. наверное это заговор!
хз что тебе сказать... возможно потому, что конторы волокут код написанный *надцать(ибо *надцать лет назад, мингв был еще ой как плох) лет назад, и который использует что-то там M$ специфичное?

A>не, серьезно. я хз чем ты там занимаешься, но ты попробуй всетаки поинтересоваться как и на чем пишется коммерческий софт для домашних пользователей. геймдев под винду, всякие сд-эжекторы.
мне не нужно интересоваться, ибо я сам работаю в геймдеве(правда не по части гуя), и знаю, что использует соседний отдел: qt+mingw.
к примеру, клиентская часть написанная на C++ с использованием Qt, имеет(имела три недели назад) ~135000 loc. конторе, правда, три года от роду.

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

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

X>>и еще несколько мыслей.
X>>1. не вижу смысла использовать инструмент, который привязывает тебя к платформе. как и писать код, привязанный к платформе. по крайней мере, у меня такого в жизни не случалось, хоть я и работаю с linux/bsd/qnx.
A>всё зависит от задачи.
A>для каких-то задач можно позволить себе писать кроссплатформенный код.
A>для других задач, писать кроссплатформенный бессмысленно. неоправданно дорого, сложно и неэффективно.
так не нужно изобретать фреймворки/библиотеки! они же уже есть готовые!

A>представь что тебе надо написать ActiveX компонент к Internet Explorer. который должен в фоне скачиваться/обновляться. часть юзеров сидит в африке и у них медленно модемное соединение, а другие юзеры юзают 2G-интернет от слоуфона.
A>и ты внезапно понимаешь, что например использование платформозависимой функции UrlDownloadToFile является лучшим решением, чем пихать в бинарник 500Кб boost.asio и ее зависимостей.
это не совсем правильный пример, но суть понял...
думаю, я бы поступил так же, но заранее бы подумал о том, что такой код должен абстрагироваться от платформы, и, наверняка, написал бы функцию-врапер, типа url_download_to_file(). ну и условная компиляция...

A>то что среди твоих знакомых нет таких людей, это не отменяет того факта, что например есть Google Chrome, и что его компилят VC++2010.
я не уверен, что есть реальное препятствие этому. причин выбора msvc может быть несколько, вплоть до "так решили сверху".

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

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

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

EP>>>http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
X>>там не говорится ни о каких расширениях микрософт.
X>>да и о win-spefic хидерах — тоже.

EP>http://clang.llvm.org/docs/UsersManual.html#clang-cl
это можно сделать. оно вообще хоть кому-то реально нужно?

EP>http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
из этого, наверное нужно 'pragma pack' и 'pragma comment' ?

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

A>>для разработки под Windows нужны расширения компилятора, а в mingw всех нужных расширений нет.
X>о чем речь?
ATL хедеры mingw, вроде, не переваривает.
Плюс некоторые виндовые хедеры из тех, что с твоим mingw идут не полные.

Ну и как-то мелкий проект было желание на mingw перевести, получил "out of memory allocating x bytes". К сожалению, разбираться некогда было. Тем более, майкросовтовский компилятор собирал нормально. Ну и так и осталось.

A>>- моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
X>это твой недостаток, не не мингва.
Ну хз. Если один инструмент позволяет использовать привычное окружение, а другой нет, то первому одножначно плюс.

A>>- я не могу собрать mingw мой код который использует библиотеку "X", расширение С++ "Y", код на C++/CLI (внезапно в реальном мире оказывается есть легаси код)
X>опять же, это твой недостаток, и недостаток твоего кода. зачем писать непереносимый код? в чем смысл?
Смысл в том, что код уже написан. Переделывать его никто не будет. В итоге остаётся или использовать майкросовтовский компилятор. Или если цланг подсуетится, то можно и его. Ну и такое отношение весьма показательно, не находишь?

X>опять же — это твои личные недостатки.
Ну и такое отношение весьма показательно, не находишь?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

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

Если точки останова меняют поведение кода, то значит в коде "гонка" и её надо исправлять, иначе она выстрелит в таком месте, где совсем этого не ожидаешь.

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

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

A>>>clang тоже. надеюсь они таки портируют libc++ под винду
X>>там все гораздо хуже, у них даже рантайма своего нет.
X>>на своих презентациях они говорят об одном, но в списке разработчиков правду, о положении вещей

A>>>и можно будет благополучно забыть про mingw.
X>>оно будет хуже мингва, по ряду причин, которые, как мне кажется, они не будут спешить исправлять.
X>>а что таки с мингвом не так? само название не нравится?

A>TL;DR: всё не так.
A>для разработки под Windows нужны расширения компилятора, а в mingw всех нужных расширений нет.

A>по пунктам:
A>- моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
поддерживает

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

A>как интегрировать SCons в MSVS ?
A>чтоб например я мог переименовать .cpp файл в solution explorer'e, нажать F7 и у меня бы собрался проект?

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

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

EP>Эта штука у них спорная получилась. Надо будет кинуть в [std-proposals] сравнение pros/cons с этим.
ссылки одинаковые

EP>учитывая то что, как я понял, они у них stackful
странно. я думал что эти сопрограммы с await будут stackless, как в С#.

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

EP>>Эта штука у них спорная получилась. Надо будет кинуть в [std-proposals] сравнение pros/cons с этим.
A>ссылки одинаковые

не-до-копипастил, вот вторая ссылка.

EP>>учитывая то что, как я понял, они у них stackful
A>странно. я думал что эти сопрограммы с await будут stackless, как в С#.

Я тоже сначала думал что stackless — тут-то пометка функции keyword'ом более-менее объяснима (функция не обычная, стэка нет, превращается в объект и т.п.).
Вот видео с GoingNative 2013, где один из разработчиков Microsoft объясняет этот C++ async/await. На 11 слайде (10:26 на видео) как раз говорится, что их C# async/await это stackless, с явным переписыванием функции в state-machine, а версия C++ — stackful.

Более того, в их stackful корутинах await может быть только в внутри resumable функциях (то есть ограниченно одним уровнем).

In the case of ‘await,’ it is only reserved within the body of a resumable function; since there are no existing resumable functions, its introduction is not a breaking change.

То есть они дизайнили-дизайнили, и в итоге собрали все недостатки/потеряли все преимущества stackless и stackful:

stackless порождает объект state-machine, можно представить, что в C++ такой объект можно было бы перемещать/копировать. используя stackful реализацию — они лишают нас этой возможноти

небольшие stackless генераторы могут быть крайне эффективными — не нужно скакать по стэку, оптимизатор можно всё отлично заинлайнить. Их stackful всё это убивает на корню.

stackful требует аллокации стэка, причём нужного размера (у них ведь не реализован segmented stack?) — что без специального контроля может отъедать много памяти/адресного пространства и т.п.

у stackful есть killer-feature — yield/await может находится на произвольной глубине call stack, причём в этом call stack'е может быть чужой код. НО, их stackful ограничен одним уровнем.

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

EP>Я тоже сначала думал что stackless — тут-то пометка функции keyword'ом более-менее объяснима (функция не обычная, стэка нет, превращается в объект и т.п.).
EP>Вот видео с GoingNative 2013, где один из разработчиков Microsoft объясняет этот C++ async/await. На 11 слайде (10:26 на видео) как раз говорится, что их C# async/await это stackless, с явным переписыванием функции в state-machine, а версия C++ — stackful.

угу. создал отдельную тему про этот фейл — http://rsdn.ru/forum/cpp.applied/5366761.1

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

A>clang тоже. надеюсь они таки портируют libc++ под винду
там все гораздо хуже, у них даже рантайма своего нет.
на своих презентациях они говорят об одном, но в списке разработчиков правду, о положении вещей

A>и можно будет благополучно забыть про mingw.
оно будет хуже мингва, по ряду причин, которые, как мне кажется, они не будут спешить исправлять.
а что таки с мингвом не так? само название не нравится?

к тому же, не представляю, зачем компилятор у которого качество оптимизации и годогенерации на уровне 2000`ых =)

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

X>к тому же, не представляю, зачем компилятор у которого качество оптимизации и годогенерации на уровне 2000`ых =)

Я видел случаи где Clang оптимизировал лучше GCC, например.
Каких-то примеров показывающих что у Clang кодогенерация "на уровне 2000`ых" не видел, хотя специально тесты не проводил. Если и есть какие-то области где Clang отстаёт по кодогенерации — то скорей всего за пару лет он сможет наверстать (учитывая темпы его развития).

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

EP>Я видел случаи где Clang оптимизировал лучше GCC, например.
ничто не идеально.

просто мне непонятны мечтания об использовании clang...
хотя абикс и не знает, но тулчейн это не только "окошко куда пишут код"(с) — это множество дополнительных компонентов, которых у clang пока нет, и не предвидится =)
большая часть тулчейна основанного на clang будет использовать компоненты написанные такими проектами как gcc/mingw-w64/binutils/gdb/etc... так а зачем в этом случае clang? или это типа как в мире линукс дистрибутивов: 100 дистров, и ни одного хорошего?

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

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

X>>просто мне непонятны мечтания об использовании clang...

EP>В смысле? Clang потихоньку начинает поддерживать Microsoft Extensions
о чем речь?

EP>и соответственно начинает прожевывать всякие win-spefic header'ы
о чем речь?

EP>Во-первых, Clang здорово расшевелил всю эту тусовку (например) — это несомненно плюс.
это же ссылка на страничку GCC. он это тоже поддерживает.

EP>Во-вторых, Clang предоставляет адекватный интерфейс для создания утилит. А в GCC (слайды 6-7):
во-первых — над этим уже работают.
во-вторых — мы про компиляторы, а не про тулзы.

EP>В-третьих, чем больше разных реализаций, тем быстрее находятся всякие неоднозначности в стандарте.
это да.

EP>В-четвёртых, Clang изначально заточен под LLVM, и соответственно прекрасно дружит с проектами которые работают с LLVM (например компиляция Clang++ -> LLVM -> JavaScript).
gcc этого не умеет.

EP>А вот на каком уровне поддержка LLVM у GCC я не знаю

и я хз. а оно надо? есть ли реальный смысл, кроме академического?

EP>Clang это не просто косметическая переделка как большинство дистрибутивов Linux. Если использовать такое сравнение, то Clang это скорее новое ядро(а-ля GNU Hurd), которых намного меньше чем дистрибутивов.
ну хз...

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

X>>>просто мне непонятны мечтания об использовании clang...
EP>>В смысле? Clang потихоньку начинает поддерживать Microsoft Extensions
X>о чем речь?
EP>>и соответственно начинает прожевывать всякие win-spefic header'ы
X>о чем речь?

http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

EP>>Во-первых, Clang здорово расшевелил всю эту тусовку (например) — это несомненно плюс.
X>это же ссылка на страничку GCC. он это тоже поддерживает.

Так о том и речь — GCC начал сравнивать свою диагностику с Clang. Скорей всего он и подтянул её из-за соперничества с Clang.

EP>>Во-вторых, Clang предоставляет адекватный интерфейс для создания утилит. А в GCC (слайды 6-7):
X>во-первых — над этим уже работают.

Из-за пинка от Clang?
Почему раньше не работали? Сейчас бы было больше разных tools.

X>во-вторых — мы про компиляторы, а не про тулзы.

Clang широко используется, его интерпретация ISO постоянно шлифуется, это сказывается и на tools'ах.

EP>>В-четвёртых, Clang изначально заточен под LLVM, и соответственно прекрасно дружит с проектами которые работают с LLVM (например компиляция Clang++ -> LLVM -> JavaScript).
X>gcc этого не умеет.
EP>>А вот на каком уровне поддержка LLVM у GCC я не знаю

X>и я хз. а оно надо? есть ли реальный смысл, кроме академического?

Смысл в том, что я могу взять код который компилируется Clang'ом, и перенести его в Web, через Emscripten (который работает с LLVM).

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

EP>http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
там не говорится ни о каких расширениях микрософт.

EP>Так о том и речь — GCC начал сравнивать свою диагностику с Clang. Скорей всего он и подтянул её из-за соперничества с Clang.
ну да, сначала это появилось в шланге, а потом в гцц.

EP>Из-за пинка от Clang?
думаю, да...

EP>Почему раньше не работали? Сейчас бы было больше разных tools.
работали, только в другом направлении. в версии 4.4.х, добавили поддержку плагинов. на этой основе написано немало тулзов.

EP>Смысл в том, что я могу взять код который компилируется Clang'ом, и перенести его в Web, через Emscripten (который работает с LLVM).
я не особо понимаю, какой в этом смысл, и как оно работает?
как будет перенесен код, использующий boost.filesystem?
да и вообще, как быть с сисколами?

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

X>там не говорится ни о каких расширениях микрософт.
да и о win-spefic хидерах — тоже.

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

A>>clang тоже. надеюсь они таки портируют libc++ под винду
X>там все гораздо хуже, у них даже рантайма своего нет.
X>на своих презентациях они говорят об одном, но в списке разработчиков правду, о положении вещей

A>>и можно будет благополучно забыть про mingw.
X>оно будет хуже мингва, по ряду причин, которые, как мне кажется, они не будут спешить исправлять.
X>а что таки с мингвом не так? само название не нравится?

TL;DR: всё не так.
для разработки под Windows нужны расширения компилятора, а в mingw всех нужных расширений нет.

по пунктам:
— моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
— я не могу собрать mingw мой код который использует библиотеку "X", расширение С++ "Y", код на C++/CLI (внезапно в реальном мире оказывается есть легаси код)
— предупреждения сделаны неюзабельно (я не хочу писать скобки в A|B&C)
— документация к компилятору говно, коммьюнити — идиоты: я спрашивал как уменьшить .exe если я компилю его с ключом -s, все хором говорили "юзай strip" и никто не в курсе что делает ключ -s
— niXman говорит что у кланга нет своего рантайма, тогда почему mingw юзает доисторическую версию Microsoft Visual C++ Runtime?
— код компилируется медленно
— где .pdb? где post-mortem отладка?
X> большая часть тулчейна основанного на clang будет использовать компоненты написанные такими проектами как gcc/mingw-w64/binutils/gdb/etc
— нафига мне этот gdb если мне нужен отладчик и надо собирать крешдампы с юзеров?
— mingw так же как и D — вроде он и есть, и уже много лет есть, а юзать его почему-то никто не хочет
— дальше я забыл, но суть в том, что у меня есть куча проектов, и я либо не могу использовать mingw, либо использование mingw значительно снизит продуктивность работы/усложнит ALM

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

A>для разработки под Windows нужны расширения компилятора, а в mingw всех нужных расширений нет.
о чем речь?

A>по пунктам:
A>- моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
это твой недостаток, не не мингва.

A>- я не могу собрать mingw мой код который использует библиотеку "X", расширение С++ "Y", код на C++/CLI (внезапно в реальном мире оказывается есть легаси код)
опять же, это твой недостаток, и недостаток твоего кода. зачем писать непереносимый код? в чем смысл?

A>- предупреждения сделаны неюзабельно (я не хочу писать скобки в A|B&C)
на то есть причины, думаю я. вряд ли msvc хоть в чем-то лучше соответствует стандарту.

A>- документация к компилятору говно, коммьюнити — идиоты: я спрашивал как уменьшить .exe если я компилю его с ключом -s, все хором говорили "юзай strip" и никто не в курсе что делает ключ -s
и я не уверен, для чего '-s'. я, по всей видимости, тоже идиот. (догадываюсь, что эта опция запускает strip)

A>- niXman говорит что у кланга нет своего рантайма, тогда почему mingw юзает доисторическую версию Microsoft Visual C++ Runtime?
C-runtime, не С++.
я уже объяснял неоднократно %)
1. вот я только что посмотрел список зависимостей explorer.exe в win7, и там оказалась msvcrt.dll. так как же так получается, что не самая старая версия венды, юзает "доисторическую версию" msvcrt.dll ?
2. msvcrt.dll не предоставляет необходимого compiler-intrinsics, который нужен, сам знаешь для чего.
3. msvcrt.dll используется пока. но как я уже писал ранее — мы работаем над своей версией CRT, взамен msvcrt.dll, которая сильно ограничена, в виду принадлежности к M$, и, таким образом, обязывает городить костыли, хотя бы для того, чтоб сделать printf() C99-совместимым.

A>- код компилируется медленно
ну да, слышал уже неоднократно)
намного медленнее?

A>- где .pdb? где post-mortem отладка?
там же, где и у шланга. врятли оно когда-нибудь появится.

X>> большая часть тулчейна основанного на clang будет использовать компоненты написанные такими проектами как gcc/mingw-w64/binutils/gdb/etc
A>- нафига мне этот gdb если мне нужен отладчик и надо собирать крешдампы с юзеров?
по правде сказать, я не копал в этом направлении, и, признаться, не уверен что это такое... это типа core-dump`ов?

A>- mingw так же как и D — вроде он и есть, и уже много лет есть, а юзать его почему-то никто не хочет
ты живешь в своем, выдуманом мирке...
посмотри хотя бы сюда:
http://mingw-w64.sourceforge.net/
табличку видишь? не могу найти правильную ссылку на полную таблицу. и еще большая присутствует на сайте старого мингва.

A>- дальше я забыл, но суть в том, что у меня есть куча проектов, и я либо не могу использовать mingw, либо использование mingw значительно снизит продуктивность работы/усложнит ALM
опять же — это твои личные недостатки.

и еще несколько мыслей.
1. не вижу смысла использовать инструмент, который привязывает тебя к платформе. как и писать код, привязанный к платформе. по крайней мере, у меня такого в жизни не случалось, хоть я и работаю с linux/bsd/qnx.
2. признаюсь, но среди моих знакомых нет никого, кто бы использовал msvc. наверное, что-то в наших с тобой жизнях пошло по разным направлениям.

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

NC>но там еще компилятор, как я понимаю, под винду не сделали.
биткод — он кроссплатформенный, нужен рантайм/стандартная библиотека

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

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

NC>>но там еще компилятор, как я понимаю, под винду не сделали.
A>биткод — он кроссплатформенный, нужен рантайм/стандартная библиотека

Ну это понятно. Я имел в виду простую возможность скачать с официального сайта (иногда для организаций это важно) официальную сборку для Windows, и чтобы была какая-то (тоже официальная и без шаманств) инфраструктура со стороны сред разработки (того же qt creator).

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

NC>Отладчик. Ужасный тормознутый отладчик, который выполняет элементарные действия минутами(!) или вообще зависает.
ну это враки же =)
или приведи пример.

NC>Возможно, я не умею с ним работать (работаю из qt creator). Но даже на примитивных проектах оно тормозит и когда я пытаюсь пройти по шагам простейший код, иногда между шагами такие паузы, что qt creator'y надоедает ждать и он выводит соответствующее сообщение

попробуй поработать не из под криейтора — тогда будет выявлен виновник.

NC>Жду, может у шланга будет нормальный отладчик под винду... но там еще компилятор, как я понимаю, под винду не сделали.
к которому прикрутят некоторую IDE, и получится тоже самое, что и сейчас.

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

NC>>>но там еще компилятор, как я понимаю, под винду не сделали.
A>>биткод — он кроссплатформенный, нужен рантайм/стандартная библиотека

NC>Ну это понятно. Я имел в виду простую возможность скачать с официального сайта (иногда для организаций это важно) официальную сборку для Windows, и чтобы была какая-то (тоже официальная и без шаманств) инфраструктура со стороны сред разработки (того же qt creator).

средой разработки будет MSVS.
сейчас уже можно скачать кланг который как добавляется в виде тулчейна С++, т.е. в настройках проекта надо просто выставить LLVM-vs20xx вместо v120 или CTP_Nov2013

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

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

Это, по меньшей мере, спорно.
1. Дело привычки.
2. Особенности проекта.
3. Иногда такие баги бывают что хоть каждое выражение логируй фиг поймёшь где причина, особенно когда имеешь дело со всякими COM'ами

Ну и вообще, нельзя быть таким категоричным, вот чужой код, это чей?
Когда работаешь с проектом в одиночку ок, всё что сам пишешь это твоё, а если команда пишет? А если текучка в команде?
А если процесс разработки не предполагает каждому свой уютненький кусок проекта
и в итоге все пишут в любой модуль в соответсвии с таском, и таким образом даже написанный тобой модуль с нуля
через пару месяцев ты вообще можешь не узнать.

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

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

S>Ну и вообще, нельзя быть таким категоричным, вот чужой код, это чей?

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

S>Когда работаешь с проектом в одиночку ок, всё что сам пишешь это твоё, а если команда пишет? А если текучка в команде?
S>А если процесс разработки не предполагает каждому свой уютненький кусок проекта
S>и в итоге все пишут в любой модуль в соответсвии с таском, и таким образом даже написанный тобой модуль с нуля
S>через пару месяцев ты вообще можешь не узнать.

выше объяснил.

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

EP>>http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html
X>там не говорится ни о каких расширениях микрософт.
X>да и о win-spefic хидерах — тоже.

http://clang.llvm.org/docs/UsersManual.html#clang-cl
http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
+ где-то недавно об этом слышал, не могу вспомнить где именно.

EP>>Из-за пинка от Clang?
X>думаю, да...
EP>>Почему раньше не работали? Сейчас бы было больше разных tools.
X>работали, только в другом направлении. в версии 4.4.х, добавили поддержку плагинов. на этой основе написано немало тулзов.

Ну так получается от Clang'а есть польза.

EP>>Смысл в том, что я могу взять код который компилируется Clang'ом, и перенести его в Web, через Emscripten (который работает с LLVM).
X>я не особо понимаю, какой в этом смысл, и как оно работает?

Транслирует LLVM IR (или что-то подобное) в JavaScript.

X>как будет перенесен код, использующий boost.filesystem?

https://github.com/kripken/emscripten/wiki/Filesystem-Guide
Если же там есть привязка к конкретной OS — то скорей всего не пойдёт.

X>да и вообще, как быть с сисколами?

Видимо что-то эмулируется напрямую, а что-то подменной библиотек.
Есть примеры использующие OpenGL: 1, 2; QT.

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

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

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

S>>Ну и вообще, нельзя быть таким категоричным, вот чужой код, это чей?

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

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

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

DE>ATL хедеры mingw, вроде, не переваривает.
это не Си/С++?

DE>Плюс некоторые виндовые хедеры из тех, что с твоим mingw идут не полные.
почему не репортуешь?

DE>Ну и как-то мелкий проект было желание на mingw перевести, получил "out of memory allocating x bytes".
при компиляции?

DE>Ну хз. Если один инструмент позволяет использовать привычное окружение, а другой нет, то первому одножначно плюс.
"привычное окружение" — понятие относительно. как мы выяснили, привычное окружения для меня и Абикса — несовместимы. тем не менее, я на венде вполне себе нормально кожу, если нужно. криейтор+мингв — все, что нужно. иногда даже в консоль спускаюсь.

DE>Смысл в том, что код уже написан. Переделывать его никто не будет.
понятно.
так и со стандартом — что-то кардинально менять никто не хочет, и волокут обратную совместимость, которая мешает всему новому. так кому от этого выгода? — новым проектам которые решают использовать компилируемый ЯП, но не хотят С++ из-за его "багажа", и, таким образом, выбирают Go/D?

DE>Ну и такое отношение весьма показательно, не находишь?
показательно.
но, GCC не имеет среди таргетных платформ венду. то, что GCC умеет компилить для венды, безо всякой эмуляции и прослоек — это заслуга mingw.org и mingw-w64. оба эти проекта проделали огромнейшую работу, но, видимо, недостаточную...

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

X>это тоже самое, как и ругать GCC за то, что он предоставляет свои расширения, которые не поддерживают другие компиляторы. нелогично же?
Ну скажем интеловский компилятор с майкросовтовским совместим... И GCC расширения (хз, может не полностью) он тоже поддерживает.
Если и clang будет, то будут (смогут) использовать и его. GCC не ругают (я по крайней мере), но и использовать в таких случаях не получится. Вполне себе конкурентное преимущество при прочих равных.

X>мне не нужно интересоваться, ибо я сам работаю в геймдеве(правда не по части гуя), и знаю, что использует соседний отдел: qt+mingw.
X>к примеру, клиентская часть написанная на C++ с использованием Qt, имеет(имела три недели назад) ~135000 loc. конторе, правда, три года от роду.
А что за контора и что пишут, если не секрет?

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

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

X>>это тоже самое, как и ругать GCC за то, что он предоставляет свои расширения, которые не поддерживают другие компиляторы. нелогично же?
DE>Ну скажем интеловский компилятор с майкросовтовским совместим...
правда? хм..

DE>А что за контора и что пишут, если не секрет?
контору не назову, но пишем разного рода игрушки(и не только), сетевые сервисы, и, иногда не для себя.

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

DE>>ATL хедеры mingw, вроде, не переваривает.
X>это не Си/С++?
Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть.

DE>>Плюс некоторые виндовые хедеры из тех, что с твоим mingw идут не полные.
X>почему не репортуешь?
В sal.h содержимого гораздо меньше, чем в виндовом, например.

DE>>Ну и как-то мелкий проект было желание на mingw перевести, получил "out of memory allocating x bytes".
X>при компиляции?
Да. К сожалению исхoдники показать не могу. Выделить проблемный кусок тоже не удалось.

DE>>Ну хз. Если один инструмент позволяет использовать привычное окружение, а другой нет, то первому одножначно плюс.
X>"привычное окружение" — понятие относительно. как мы выяснили, привычное окружения для меня и Абикса — несовместимы. тем не менее, я на венде вполне себе нормально кожу, если нужно. криейтор+мингв — все, что нужно. иногда даже в консоль спускаюсь.
Естественно, относительно. Тем не менее, при возможности пользоваться привычными инструментами люди предпочитают это и делать. И при переходе будут упираться. Особенно если нет никаких особых преимуществ. Возможности нового стандарта, к сожалению ("как ни странно"), не всех убеждают.

DE>>Смысл в том, что код уже написан. Переделывать его никто не будет.
X>понятно.
X>так и со стандартом — что-то кардинально менять никто не хочет, и волокут обратную совместимость, которая мешает всему новому. так кому от этого выгода? — новым проектам которые решают использовать компилируемый ЯП, но не хотят С++ из-за его "багажа", и, таким образом, выбирают Go/D?
Так если бы они начали выкидывать "старое барахло", то было бы ещё хуже — в куче проектов тупо зафиксировали бы старую версию и всё. А так хоть ограниченно новые фичи вносить можно.
К D, кстати, даже в текущих условиях часто претензии высказывают из-за ломающих изменений.

DE>>Ну и такое отношение весьма показательно, не находишь?
X>показательно.
X>но, GCC не имеет среди таргетных платформ венду. то, что GCC умеет компилить для венды, безо всякой эмуляции и прослоек — это заслуга mingw.org и mingw-w64. оба эти проекта проделали огромнейшую работу, но, видимо, недостаточную...
Я понимаю и уважаю труд этих людей (ага и твой в том числе). Просто хочу сказать, что силанговский подход (если они, конечно, завершат начатое) имеет свои плюсы.

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

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

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

X>>>это тоже самое, как и ругать GCC за то, что он предоставляет свои расширения, которые не поддерживают другие компиляторы. нелогично же?
DE>>Ну скажем интеловский компилятор с майкросовтовским совместим...
X>правда? хм..
Да, правда не могу сказать насколько полностью.
Про совместимость с GCC у них тоже есть.

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

DE>Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть.
если доберешся — дай знать. хотелось бы понять причину.

DE>В sal.h содержимого гораздо меньше, чем в виндовом, например.
скинь плиз sal.h от msvc, гляну.

DE>Да. К сожалению исхoдники показать не могу. Выделить проблемный кусок тоже не удалось.
исходники не нужны. просто если появится время/желание — дай знать, возможно таки сможем победить.

DE>Я понимаю и уважаю труд этих людей (ага и твой в том числе). Просто хочу сказать, что силанговский подход (если они, конечно, завершат начатое) имеет свои плюсы.
по поводу clang-cl — я это сделаю для мингва, типа gcc-cl

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

DE>>Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть.
X>если доберешся — дай знать. хотелось бы понять причину.
Проблемы, например, в "throw( ... )", например (atlalloc.h):

_Ret_opt_bytecap_x_(nElements * sizeof(T)) T* Allocate(_In_ size_t nElements) throw( ... )
{
...

.../Microsoft Visual Studio 10.0/VC/atlmfc/include/atlalloc.h: At global scope:
.../Microsoft Visual Studio 10.0/VC/atlmfc/include/atlalloc.h:493:44: error: expected type-specifier before '...' token
  CTempBuffer(_In_ size_t nElements) throw( ... ) :
                                            ^

Нестандартно (и бесполезно), но править хедеры не хочется.
Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда.

DE>>В sal.h содержимого гораздо меньше, чем в виндовом, например.
X>скинь плиз sal.h от msvc, гляну.
Вот (который с 2010 студией идёт).

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

DE>Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда.
разузнаю.

DE>Вот (который с 2010 студией идёт).
как написано в самом 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. таким образом, они по логике не должны перетекать в пользовательский код.
так что да, если mingw-w64 в описании API не использует часть этих макросов, то его содержание может отличаться.

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

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

EP>>Я видел случаи где Clang оптимизировал лучше GCC, например.
X>отрепортовал. исправят.
оно оказывается уже исправлено:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742

кто-нибудь, приведите пример нескольких популярных опций cl.exe. хочу из кланга взять карту соответствий, но не могу понять где она.
спасибо.

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

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

DE>>Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда.
X>разузнаю.
можно. там действует тот же принцип, что и для остальных хидеров — они не копируются из msvc, а пишутся руками. иначе, любые хидеры нельзя было бы включать в мингв.

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

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

их много.
вот например опции по умолчанию для Debug x86

compile

/GS /analyze- /W3 /Zc:wchar_t /Zi /Gm /Od /sdl /Fd"Debug\vc120.pdb" /fp:precise /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_LIB" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /Fa"Debug\" /EHa /nologo /Fo"Debug\" /Fp"Debug\nov13ctp_sandbox.pch" 

link

/OUT:"D:\_src\sandbox\nov13ctp_sandbox\Debug\nov13ctp_sandbox.exe" /MANIFEST /NXCOMPAT /PDB:"D:\_src\sandbox\nov13ctp_sandbox\Debug\nov13ctp_sandbox.pdb" /DYNAMICBASE:NO "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X86 /INCREMENTAL /PGD:"D:\_src\sandbox\nov13ctp_sandbox\Debug\nov13ctp_sandbox.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Debug\nov13ctp_sandbox.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

ага, спасибо, разбираюсь.

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

X>ага, спасибо, разбираюсь.

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

также надо не забыть про командные файлы, они вроде используются в msbuild — http://msdn.microsoft.com/en-us/library/x2khzsa1.aspx

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

A>минимально необходимые это наверное пути к файлам и дефайны.
A>остальное можно сделать заглушками
думаю, сделать поддержку основных опций оптимизации(-O0,-O1,-O2,-O3), дефайнов, и путей к хидерам.

A>также надо не забыть про командные файлы, они вроде используются в msbuild — http://msdn.microsoft.com/en-us/library/x2khzsa1.aspx
эм.. поможешь, если что, с пониманием? а то я читаю доку, и реально чего-то недопонимаю... это что-то вроде баша для вендус?

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

A>>также надо не забыть про командные файлы, они вроде используются в msbuild — http://msdn.microsoft.com/en-us/library/x2khzsa1.aspx
X>эм.. поможешь, если что, с пониманием? а то я читаю доку, и реально чего-то недопонимаю... это что-то вроде баша для вендус?

не, там те же опции командной строки, только в файле.

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

A>>- код компилируется медленно
X>ну да, слышал уже неоднократно)
X>намного медленнее?

не сильно медленнее, но ощущается. и виной тут не gcc сам по себе, а его прослойка mingw.
две библиотеки ICU и xerces-c. на VC собираются быстро.
беру msys2 (чтобы не наткнутся на проблему с компилированием в несколько потоков), gcc. запускаю сборку в число_ядер+1 потоков. времени уходит больше.

сейчас пытаюсь переползти на написание кода в linux (надеюсь получить больше плюсов, таких как valgrind и более адекватное поведение нужных библиотек). т.е. это рабочее место, а код потом уже в win собрать под mingw. виртуальная машина с fedora на том же компе, что и mingw/VC .версия gcc та же (4.8.2). запускаю сборку библиотек — если сказать, что сборка идет быстро — ничего не сказать. а уж момент конфигурации по сравнению с msys идет почти мгновенно.

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

C>и виной тут не gcc сам по себе, а его прослойка mingw.
C>...
C>беру msys2

противоречий не замечаете?

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

C>момент конфигурации по сравнению с msys идет почти мгновенно.
так очевидно же, msys трансформирует пути/аргументы/етц налету.

вот только к мингву это не имеет отношения.

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

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

C>>и виной тут не gcc сам по себе, а его прослойка mingw.
C>>...
C>>беру msys2

X>противоречий не замечаете?
при запуске из под msys2 mingw-gcc работает ведь напрямую, не беря ничего от msys ? согласен, что make может не так эффективно работать под виндой.
mingw-шный make умеет в потоках собирать ?

C>>надеюсь получить больше плюсов, таких как valgrind
X>бестолковый инструмент для плюсового кода.
ну бестолковый или нет, а под виндой бесплатного ничего нет для поиска утечек. использование всяких либ для этого как то не сложилось. то не видят проблем при работе с классами из библиотек (надо все библиотеки пересобирать вместе с ней), то не работают под mingw по причине "posix gcc детектим, и меняем хедеры — не собирается; win gcc — не имеет имплементацию потоков). это гугловская библиотека, название не помню

C>>момент конфигурации по сравнению с msys идет почти мгновенно.
X>так очевидно же, msys трансформирует пути/аргументы/етц налету.
согласен.
X>вот только к мингву это не имеет отношения.

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

C>надеюсь получить больше плюсов, таких как valgrind

оно, вам наверное нужно для поиска утечек памяти?

приведу пример из личного опыта, произошедший совсем недавно.

есть проект, довольно таки большой проект, ~200000 loc.
начали подготавливать проект к релизу, и обнаружились "стандартные" Си`шные чудеса в виде произвольных падений программы. при том валилась программа в совершенно разных участках, порою даже не связанных(разве что адресным пространством). я в течении нескольких дней понял, что мы имеем дело либо с порчей кучи/стека, либо с висячими указателями, либо и то, и другое.
и вот, три человека, в течении месяца, полный рабочий день занимаются только поисками этих багов. по истечении месяца стало понятно, что ничего найти не получается. стандартные средства типа отладчика и стек-трейсера никак не помогают, а только путают. так же опробован valgrind, который, к слову, тоже только "голову морочил". не для плюсового кода он, однако.

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

хз, сколько еще месяцев потребовалось бы на поиски этих багов, без AddressSanitizer %)

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

C>при запуске из под msys2 mingw-gcc работает ведь напрямую, не беря ничего от msys ?
напрямую.

C>mingw-шный make умеет в потоках собирать ?
уже более года, как.

в общем проблему с производительностью я понял — да, виноват 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

X>вы про msvcrt.dll?

Именно)

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

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

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

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

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

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

сойдемся на том, что каждому свое

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

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

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

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

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

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

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

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

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

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

кстати о логах, логирующие точки останова ничем не хуже, если конечно есть возможно подключить отладчик

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

A>и что мешает посмотреть значения переменных в многопоточном коде?

Потому что точки останова меняют поведение многопоточного кода. Т.е. отлаживается совсем не то, что работает в реальности.

A>а что такого особенного в риалтайм коде? риалтайм это вообще-то только пожелание, на практике многие процессы можно спокойно поставить на паузу.

Ну мне вот например было совсем не удобно смотреть на реалтайм обработку видео под отладчиком, в то время как бегующие в консольке цифры параллельно основному окну, очень даже удобны были...

A>кстати о логах, логирующие точки останова ничем не хуже, если конечно есть возможно подключить отладчик

Ну так это и получается просто логгер... И тут мы вспоминаем про бритву Оккама...

P.S. А я думал что ты отреагируешь скорее на пункт 5 в моём первом сообщение тут, т.к. он является по сути комментарием на твои сообщения в темке... А по поводу отладчиков не вижу особого смысла спорить. Очевидно что лучше когда он есть, чем когда его нет. ))) Вне зависимости от вкусов и стилей отладки конкретных разработчиков.

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

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

DE>>Почему не должны? Встречал, код где тоже параметры отмечались как _In_, _Out_ и т.д. Смысла может и нет, но и запрета ведь нет тоже.
X>если размышлять по-вашему, то и использование 'boost::asio::detail::increment()' в своем коде — является нормальным.
Всё-таки нет. Вот тут есть целая куча информации, где в общем-то предлагают самим использовать их аннотации. Так что это не деталь реализации. Другое дело, что оно не переносимо, но об этом речи и не шло ведь.

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

_>P.S. А я думал что ты отреагируешь скорее на пункт 5 в моём первом сообщение тут, т.к. он является по сути комментарием на твои сообщения в темке...
"Странно слышать про невозможность использовать какую-то IDE с каким-то компилятором."?

а что тут комментировать? IDE это не "редактор кода".
очевидно что сейчас MinGW невозможно использовать из MSVS.
надо добавить тулчейн в msbuild, переделать отладочную информацию, переделать подсветку синтаксиса.

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

A>а что тут комментировать? IDE это не "редактор кода".

Это да, хотя лично я предпочёл бы иметь именно совершенный редактор кода и всё (а всё остальное у меня и так есть в других инструментах), но к сожалению все редакторы C++, умеющие его полноценно парсить, находятся исключительно внутри нескольких монстроидальных IDE. Поэтому и использую их. Но надеюсь что clang это скоро поменяет..

A>очевидно что сейчас MinGW невозможно использовать из MSVS.

А мне очевидно что можно. )))

A>надо добавить тулчейн в msbuild,

Вообще то я имел в виду нормальные инструменты сборки, а не это недоразумение. Но даже если и так, то в чём проблема? )

A>переделать отладочную информацию,

Типа сложно добавить в postbuild debug версии одну строчку на запуск конвертера? )

A>переделать подсветку синтаксиса.

Ээээ что? А каким боком относится компилятор к подсветке?

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

AD>Если точки останова меняют поведение кода, то значит в коде "гонка" и её надо исправлять, иначе она выстрелит в таком месте, где совсем этого не ожидаешь.

Ничего подобного) Во многих случаях завязанность на время бывает не случайная, а специально заложенная.

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

_>Ничего подобного) Во многих случаях завязанность на время бывает не случайная, а специально заложенная.

Так это не отменяет того, что

она выстрелит в таком месте, где совсем этого не ожидаешь

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

AD>Так это не отменяет того, что
AD>

AD>она выстрелит в таком месте, где совсем этого не ожидаешь

Да? ))) И как это можно не ожидать того, что специально заложено? )))

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

A>>- моя любимая IDE (MSVS+VAX) не поддерживает mingw (а кланг теперь поддерживает ключи компиляции MSVC)
B>поддерживает

я бы предпочел вариант с тулсетом.

Здравствуйте, niXman,

как дела с интеграцией мингв в студию?

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

A>как дела с интеграцией мингв в студию?
в процессе, не забил.

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

A>>как дела с интеграцией мингв в студию?
X>в процессе, не забил.

мда. я было думал что написать такой враппер — это просто.
начал писать, и дошел до момента что cl.exe получает командную строку /Fo"Debug\\", я ее превращаю в -o "Debug\\", а g++ мне говорит что нифига, ибо -o принимает имя файла а не папки.

это же какой-то трындец. и ты говоришь что гцц не говно? да у него уже командная строка — говно =\

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

A>это же какой-то трындец. и ты говоришь что гцц не говно? да у него уже командная строка — говно =\
ну хз. как по мне — так говно — это командная строка cl.exe, ибо она совсем не такая как командная строка gcc.

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

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

A>>это же какой-то трындец. и ты говоришь что гцц не говно? да у него уже командная строка — говно =\
X>ну хз. как по мне — так говно — это командная строка cl.exe, ибо она совсем не такая как командная строка gcc.

ну знаешь ли, возможность задать каталог для всех выходных файлов нужного типа, она мощнее возможности задать имя 1 файла

т.е.
cl.exe /Fe"dir/for/exe/" /Fo"dir/for/all/obj/" /Fa"dir/for/all/asm/" src1.cpp src2.cpp src2.cpp

это круче чем
g++.exe -S -o "dir/for/all/asm/src1.asm"
g++.exe -S -o "dir/for/all/asm/src2.asm"
g++.exe -S -o "dir/for/all/asm/src3.asm"
g++.exe -c -o "dir/for/all/obj/src1.obj"
g++.exe -c -o "dir/for/all/obj/src2.obj"
g++.exe -c -o "dir/for/all/obj/src3.obj"
g++.exe -o "dir/for/exe/out.exe" "dir/for/all/obj/src1.obj" "dir/for/all/obj/src2.obj" "dir/for/all/obj/src3.obj"

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

A>ну знаешь ли, возможность задать каталог для всех выходных файлов нужного типа, она мощнее возможности задать имя 1 файла

A>т.е.
A>cl.exe /Fe"dir/for/exe/" /Fo"dir/for/all/obj/" /Fa"dir/for/all/asm/" src1.cpp src2.cpp src2.cpp

A>это круче чем
A>g++.exe -S -o "dir/for/all/asm/src1.asm"
A>g++.exe -S -o "dir/for/all/asm/src2.asm"
A>g++.exe -S -o "dir/for/all/asm/src3.asm"
A>g++.exe -c -o "dir/for/all/obj/src1.obj"
A>g++.exe -c -o "dir/for/all/obj/src2.obj"
A>g++.exe -c -o "dir/for/all/obj/src3.obj"
A>g++.exe -o "dir/for/exe/out.exe" "dir/for/all/obj/src1.obj" "dir/for/all/obj/src2.obj" "dir/for/all/obj/src3.obj"

Вот не могу понять, зачем пользоваться что одним ужасом, что другим, когда есть нормальные удобные системы построения, которые делают это всё за тебя. Причём независимо от ОС и компилятора...

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

_>Вот не могу понять, зачем пользоваться что одним ужасом, что другим, когда есть нормальные удобные системы построения, которые делают это всё за тебя. Причём независимо от ОС и компилятора...

а, действительно.
ну-ка расскажи какая система построения может взять список несколько файлов, скомпилить их g++ да так чтобы положить разные типы файлов в разные папки?

ну или может подскажи систему построения которая бы интегрировалась в студию и умела компилить g++?

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

A>ну или может подскажи систему построения которая бы интегрировалась в студию и умела компилить g++?

CMake позволяет делать custom targets, commands — то есть можно прикрутить любой компилятор, любого языка.
Он умеет генерировать проекты разных типов: Visual Studio (разных версий, начиная с VS2003), Makefiles, Eclipse CDT, KDevelop, Code::Blocks, etc. + QTCreator понимает CMakeLists.txt

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

A>ну знаешь ли, возможность задать каталог для всех выходных файлов нужного типа, она мощнее возможности задать имя 1 файла
так это вообще забота системы сборки, а не компилятора, имхо.

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

EP>CMake
я вообще использую qmake. просто и сердито.
правда, у него есть странная архитектурная особенность — он все объектники кидает в одну директорию без поддиректорий.
т.е. для ситуации когда имеем 'a/a.cpp' и 'b/a.cpp' он оба 'a.o' закинет в одну директорию, со всеми вытекающими.
и спустя *надцать лет, троли таки поняли что qmake убог, и написали qbs =)

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

A>а, действительно.
A>ну-ка расскажи какая система построения может взять список несколько файлов, скомпилить их g++ да так чтобы положить разные типы файлов в разные папки?

SCons, CMake, waf и им подобные. На мой личный вкус scons лучше всех для конечных приложений, а cmake для библиотек (распространяемых в исходниках).

A>ну или может подскажи систему построения которая бы интегрировалась в студию и умела компилить g++?

SCons умеет вообще все популярные компиляторы) И тривиально интегрируется в любую IDE.

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

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

A>>ну или может подскажи систему построения которая бы интегрировалась в студию и умела компилить g++?

EP>CMake позволяет делать custom targets, commands — то есть можно прикрутить любой компилятор, любого языка.
EP>Он умеет генерировать проекты разных типов: Visual Studio (разных версий, начиная с VS2003), Makefiles, Eclipse CDT, KDevelop, Code::Blocks, etc. + QTCreator понимает CMakeLists.txt

это всё круто, только мы говорим про интеграцию в студию, а она не понимает cmake.

интеграция в IDE — это когда добавление/переименование/удаление файлов, задание опций компиляции и т.п. делается через IDE.
правка текстовых файлов — это не интеграция в IDE.

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

_>SCons умеет вообще все популярные компиляторы) И тривиально интегрируется в любую IDE.

как интегрировать SCons в MSVS ?
чтоб например я мог переименовать .cpp файл в solution explorer'e, нажать F7 и у меня бы собрался проект?

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

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

A>>ну знаешь ли, возможность задать каталог для всех выходных файлов нужного типа, она мощнее возможности задать имя 1 файла
X>так это вообще забота системы сборки, а не компилятора, имхо.

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

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

A>это всё круто, только мы говорим про интеграцию в студию, а она не понимает cmake.

А ты его использовал?

A>интеграция в IDE — это когда добавление/переименование/удаление файлов, задание опций компиляции и т.п. делается через IDE.

Не обязательно делать добавление/переименование/удаление по одному файлу, можно например сделать:

file(GLOB src *.cpp)
ADD_EXECUTABLE(project ${src})

A>правка текстовых файлов — это не интеграция в IDE.

При изменении файлов cmake проект автоматически обновится при следующей сборке.
И мне, например, настройки большого проекта с десятками дочерних намного удобней хранить/править в простейших текстовых файлах, чем копаться по IDE. Все основные настройки собираются вместе, а весь boilerplate прячется в функциях и макросах.
Или, например, commit diff при изменении CMakeLists.txt — крайне лаконичный получается. Да и вообще хранить в репозитории CMakeLists.txt намного удобней чем проекты студии.

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

A>>как интегрировать SCons в MSVS ?
A>>чтоб например я мог переименовать .cpp файл в solution explorer'e, нажать F7 и у меня бы собрался проект?

_>Интеграция должна быть только в запуске сборки различных конфигураций из IDE. А редактирование настроек проекта очевидно удобнее делать в виде изменения текстового файла с кодом, а не щёлкая мышкой по десятку закладок в каких-то диалогах...

давай-ка ты мне не будешь говорить как оно должно быть и как оно удобнее.

ты сказал что "SCons" интегрируется в IDE, я спросил как, и теперь ты начал гнать какую-то пургу про текстовые файлы с кодом.

если в IDE есть окно "solution explorer" с определенным набором фич, интеграция в IDE означает что все эти фичи будут поддерживаться, точка.

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

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

A>>это всё круто, только мы говорим про интеграцию в студию, а она не понимает cmake.

EP>А ты его использовал?

A>>интеграция в IDE — это когда добавление/переименование/удаление файлов, задание опций компиляции и т.п. делается через IDE.

EP>Не обязательно делать добавление/переименование/удаление по одному файлу, можно например сделать:
EP>

EP>file(GLOB src *.cpp)
EP>ADD_EXECUTABLE(project ${src})
EP>

A>>правка текстовых файлов — это не интеграция в IDE.

EP>При изменении файлов cmake проект автоматически обновится при следующей сборке.
EP>И мне, например, настройки большого проекта с десятками дочерних намного удобней хранить/править в простейших текстовых файлах, чем копаться по IDE. Все основные настройки собираются вместе, а весь boilerplate прячется в функциях и макросах.
EP>Или, например, commit diff при изменении CMakeLists.txt — крайне лаконичный получается. Да и вообще хранить в репозитории CMakeLists.txt намного удобней чем проекты студии.

>_<
разве я спрашивал как тебе удобно?
я сказал что мне нужна фича студии — редактирование списка и свойств файлов в дереве solution explorer.

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

От:	niXman	https://github.com/niXman
Дата:	19.11.13 01:29
Оценка:	-6

	От:	night beast
	Дата:	19.11.13 17:41
	Оценка:	-2

	От:	Abyx
	Дата:	18.11.13 19:51
	Оценка:	39 (4)

	От:	night beast
	Дата:	20.11.13 03:47
	Оценка:

От:	niXman	https://github.com/niXman
Дата:	19.11.13 01:41
Оценка:	10 (2)

	От:	NeoCode
	Дата:	19.11.13 17:19
	Оценка:	1 (1) +1

	От:	Evgeny.Panasyuk
	Дата:	18.11.13 20:20
	Оценка:	+1

	От:	trophim
	Дата:	24.11.13 18:29
	Оценка:	+1

	От:	ArtDenis
	Дата:	25.11.13 15:17
	Оценка:	+1

	От:	bazis1
	Дата:	28.11.13 03:14
	Оценка:	+1

	От:	alex_public
	Дата:	09.12.13 17:40
	Оценка:	-1