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

Вышел очередной CTP Visual C++

Линк — http://aka.ms/Icp591

Пост в блоге VC++ — http://blogs.msdn.com/b/vcblog/archive/2013/11/18/announcing-the-visual-c-compiler-november-2013-ctp.aspx
Видео от STL — http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-/Core-Cpp-10

It contains the following C++11, C++14, and C++/CX features:

Implicit move special member function generation (thus also completing =default)
Reference qualifiers on member functions (a.k.a. "& and && for *this")
Thread-safe function local static initialization (a.k.a. "magic statics")
Inheriting constructors
alignof/alignas
__func__
Extended sizeof
constexpr (except for constructors)
noexcept (unconditional)
C++14 decltype(auto)
C++14 auto function return type deduction
C++14 generic lambdas (with explicit lambda capture list)
(Proposed for C++17) Resumable functions and await

19.11.13 13:34: Перенесено модератором из 'C/C++. Прикладные вопросы' — Кодт

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.

Здравствуйте, 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>Вышел очередной CTP Visual C++

A>Линк — http://aka.ms/Icp591

A>Пост в блоге VC++ — http://blogs.msdn.com/b/vcblog/archive/2013/11/18/announcing-the-visual-c-compiler-november-2013-ctp.aspx
A>Видео от STL — http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-/Core-Cpp-10

A>

A>It contains the following C++11, C++14, and C++/CX features:

A> Implicit move special member function generation (thus also completing =default)
A> Reference qualifiers on member functions (a.k.a. "& and && for *this")
A> Thread-safe function local static initialization (a.k.a. "magic statics")
A> Inheriting constructors
A> alignof/alignas
A> __func__
A> Extended sizeof
A> constexpr (except for constructors)
A> noexcept (unconditional)
A> C++14 decltype(auto)
A> C++14 auto function return type deduction
A> C++14 generic lambdas (with explicit lambda capture list)
A> (Proposed for C++17) Resumable functions and await

оно еще шевелится?

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

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

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

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

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

Здравствуйте, 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 дистров, и ни одного хорошего?

Здравствуйте, 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), которых намного меньше чем дистрибутивов.

Здравствуйте, 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
опять же — это твои личные недостатки.

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

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

	От:	Abyx
	Дата:	18.11.13 21:34
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	18.11.13 22:05
	Оценка:

	От:	Abyx
	Дата:	18.11.13 22:21
	Оценка:

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