>> Managed C++ — они переколбашивают синтаксис языка почти каждый релиз Visual Studio
Managed C++ — это старый набор расширений для написания managed кода на плюсах, который появился в VS 2002, и стал deprecated в VS 2005. Там все ключевые слова были с подчеркиваниями — __gc и так далее.
C++/CLI — это новый набор расширений для того же, но более грамотно задизайненый на основе печального опыта с MC++. Он появился в VS 2005, заменив собой МС++, и с тех пор не изменялся — т.е. синтаксис и семантика там стабильны уже 5 релизов VS как (2005, 2008, 2010, 2012, 2013). На нем вполне можно спокойно «поделать что-то серьезно» — другой вопрос, что для .NET шарп все равно удобнее, поэтому C++/CLI так и остается в основном языком для создания обвязок вокруг нативных библиотек.
C++/CX, который для Windows Store — это вообще другая вещь, не имеющая отношения ни к MC++, ни к C++/CLI, поскольку она заточена под нативный код. Синтаксис там процентов на 90 взят из C++/CLI, но это не замена последнему.
Это не Managed C++, а C++/CX. Managed в нем ничего нет, там все полностью компилируется в нативный код, и тоже кстати с подсчетом ссылок для объектов. Похожего в нем только то, что синтаксис по большей части взят от C++/CLI.
В оригинальной статье многое, увы, напутано. Причем это ровно те же грабли, на которые люди массово наступали, осваивая async/await в C#.
>> Внутри resumable функции вещи происходят тоже слегка иначе. Используя ключевое слово await теперь можно «завернуть» выражение или вызов функции в future, которая посчитает это выражение или вызов в другом потоке.
await ничего никуда не заворачивает — наоборот, она «разворачивает» значение типа std::future (возможно, но не обязательно, возвращенное из другой resumable функции), асинхронно ожидая завершения вычисления и вытаскивая полученное значение (или исключение).
Чтобы завернуть вызов обычной синхронной функции в future, нужно использовать std::async. Что, кстати, наглядно видно из приведенного там же примера кода.
>> И вот мы подоходим к интересному. Вы можете использовать ключевое слово await неоднократно — каждое его применение создаст std::future, которая начнёт выполняться в параллельном потоке.
Те же грабли, вид сбоку. Еще раз — await не создает экземпляры std::future, а получает значения из них.
Ну и о «параллельных потоках» — это тоже неправда. Далеко не каждый future выполняется на своем потоке. Например, вполне возможна реализация всяческой асинхронщины в reactor style, вообще на одном потоке (как в node.js) с циклом сообщений/коллбэков. Туда же всяческие completion ports и прочие средства асинхронного I/O.
Единственный случай, когда future гарантированно выполняется на своем потоке — это когда синхронный код обернут через std::async. Во всех остальных случаях, это деталь реализации данного конкретного future.
Для правильного кода риска нет — по стандарту все имена, начинающиеся с двух подчеркиваний, зарезервированы для реализации языка (в т.ч. для языковых расширений). Именно отсюда все эти __async и __attribute__.
Вопросы по коду, и вообще по проекту, можно задавать на форуме CodePlex. Или можете стукнуться мне на почту — pminaev@microsoft.com — а я переадресую команде.
Интересный вопрос. Теоретически, отладка идет через сокет по обычному V8 debugging protocol, поэтому если можно настроить хром так, чтобы он вывесил отладочный порт наружу, то к нему можно будет попробовать приаттачиться (Debug -> Attach to Process, и выбрать транспорт Node.js remote debugging). Но мы не пробовали.
Source maps пока нет, но обязательно будет, т.к. он нужен для полноценной поддержки TypeScript.
Это, действительно, реальная проблема для людей не привыкших к VS — которых особенно много среди нашей целевой аудитории — и мы над ней думаем.
Вообще, интерфейс в VS можно довольно гибко настраивать. Скрытие тулбаров по right-click на ним — это достаточно стандартная вещь, но можно также индивидуально скрывать команды, причем не только на тулбарах, но и на главном меню — это все живет в Tools -> Customize. Т.е. при желании можно очень сильно упростить интерфейс под себя. Причем это можно сохранить через Tools -> Import and Export Settings, и потом таскать с собой на новые машины.
Так вот, мысль состоит в том, чтобы сделать упрощенные профили под Python и Node разработчиков из коробки — убрать все, не относящиеся к делу менюшки и тулбары, и так далее. Нечто, что было бы как минимум «good enough» для большинства людей, привыкших к SlickEdit, Sublime и т.д.
> Чем тогда он будет отличаться от абстрактного класса? Множественным наследованием?
Отсутствием состояния.
> Так ведь изначально от этого осознанно ушли.
Множественное наследование является злом при наличии состояния. При его отсутствии, все становится намного проще, почему его и вернули.
> Еще ни разу не было необходимости в дефолтных реализациях методов интерфейса.
Необходимости на самом деле нет ни в классах, ни в циклах (все можно написать на if/goto и глобальных переменных). Речь об удобстве. Посмотрите еще раз, насколько богаче стали новые интерфейсы коллекций, и насколько удобнее их стало использовать. Теперь представьте себе, что было бы, если бы для каждой конкретной реализации коллекции её автору пришлось бы реализовывать все эти методы самому с нуля.
А, то бишь Visual Studio Gallery. Там есть некоторая проблема — чтобы работать с их автообновлением, расширение должно быть в формате VSIX, а у него есть ряд ограничений, в которые мы, увы, не влезаем.
Если мне не изменяет память, в превьюшках обычно хардкодится дата, когда оно просто перестает работать. Подгадывается так, чтобы это было через некоторое время после RTM.
Как будет с обновлениями в финальном релизе, мы пока еще детально не планировали. Но, скорее всего, как и с PTVS, мы добавим NTVS в WebPI, в дополнение к обычным установщикам. NuGet — это все же больше для библиотек и фреймворков.
cscript.exe, даже с новым движком, это далеко не нода — ведь все нативные модули, включая многие стандартные нодовские, написаны с использованием V8 API.
Гм. PTVS уже два года, и в нем стандартный Питон как был основным поддерживаемым интерпретатором, так и остается. При том, что есть и поддержка IronPython, и прочих сторонних реализаций.
Если команда, занимающаяся джаваскриптом в MS (а это другая команда!), завтра вдруг выпустит консольную версию с поддержкой ноды, то мы ее, разумеется, поддержим — в дополнение к основному интерпретатору, аналогично IronPython в PTVS. То же самое для любых других сторонних реализаций, если они в разумной мере совместимы с обычной нодой (т.е., в частности, используют её протокол отладки).
Я понимаю ваш скепсис, но задача нашего продукта — это не приватизировать ноду, а привлечь существующих разработчиков под неё на VS и Azure. Поэтому поддерживать мы будем в первую очередь всегда те реализации, библиотеки etc, которые широко использует community.
Нет, не на собственном — все работает со стандартной V8-нодой с nodejs.org. Собственно, нода не идет в коробке с расширением, её нужно ставить отдельно.
Если присмотреться, на скриншоте фигурирует node.exe.
Там в предыдущем предложении было про Visual Node. Если вкратце — это их собственный проект, но на ту же тему, и похожий внутри (тоже форк PTVS). Поэтому мы связались с ними и предложили работать совместно над одним продуктом под эгидой NTVS.
В частности, в альфе NTVS, вся работа с npm — это Red Gate.
Managed C++ — это старый набор расширений для написания managed кода на плюсах, который появился в VS 2002, и стал deprecated в VS 2005. Там все ключевые слова были с подчеркиваниями — __gc и так далее.
C++/CLI — это новый набор расширений для того же, но более грамотно задизайненый на основе печального опыта с MC++. Он появился в VS 2005, заменив собой МС++, и с тех пор не изменялся — т.е. синтаксис и семантика там стабильны уже 5 релизов VS как (2005, 2008, 2010, 2012, 2013). На нем вполне можно спокойно «поделать что-то серьезно» — другой вопрос, что для .NET шарп все равно удобнее, поэтому C++/CLI так и остается в основном языком для создания обвязок вокруг нативных библиотек.
C++/CX, который для Windows Store — это вообще другая вещь, не имеющая отношения ни к MC++, ни к C++/CLI, поскольку она заточена под нативный код. Синтаксис там процентов на 90 взят из C++/CLI, но это не замена последнему.
>> Внутри resumable функции вещи происходят тоже слегка иначе. Используя ключевое слово await теперь можно «завернуть» выражение или вызов функции в future, которая посчитает это выражение или вызов в другом потоке.
await ничего никуда не заворачивает — наоборот, она «разворачивает» значение типа std::future (возможно, но не обязательно, возвращенное из другой resumable функции), асинхронно ожидая завершения вычисления и вытаскивая полученное значение (или исключение).
Чтобы завернуть вызов обычной синхронной функции в future, нужно использовать std::async. Что, кстати, наглядно видно из приведенного там же примера кода.
>> И вот мы подоходим к интересному. Вы можете использовать ключевое слово await неоднократно — каждое его применение создаст std::future, которая начнёт выполняться в параллельном потоке.
Те же грабли, вид сбоку. Еще раз — await не создает экземпляры std::future, а получает значения из них.
Ну и о «параллельных потоках» — это тоже неправда. Далеко не каждый future выполняется на своем потоке. Например, вполне возможна реализация всяческой асинхронщины в reactor style, вообще на одном потоке (как в node.js) с циклом сообщений/коллбэков. Туда же всяческие completion ports и прочие средства асинхронного I/O.
Единственный случай, когда future гарантированно выполняется на своем потоке — это когда синхронный код обернут через std::async. Во всех остальных случаях, это деталь реализации данного конкретного future.
Для правильного кода риска нет — по стандарту все имена, начинающиеся с двух подчеркиваний, зарезервированы для реализации языка (в т.ч. для языковых расширений). Именно отсюда все эти __async и __attribute__.
Если интересно, можете попробовать поковырять отладчик:
nodejstools.codeplex.com/SourceControl/latest#Nodejs/Product/Nodejs/Debugger/
nodejstools.codeplex.com/SourceControl/latest#Nodejs/Product/Nodejs/Debugger/DebugEngine/Remote/
И в частности, то место, где оно отваливается в диалоге Attach to Process — скорее всего, там какая-то проблема в handshake, а дальше оно пойдет как надо:
nodejstools.codeplex.com/SourceControl/latest#Nodejs/Product/Nodejs/Debugger/DebugEngine/Remote/NodeRemoteEnumDebugProcesses.cs
Инструкция по скачке и сборке проекта:
nodejstools.codeplex.com/wikipage?title=Build%20Instructions%20for%20NTVS
(там все просто и тупо, обычный VS solution, минимум зависимостей)
Вопросы по коду, и вообще по проекту, можно задавать на форуме CodePlex. Или можете стукнуться мне на почту — pminaev@microsoft.com — а я переадресую команде.
Пулл реквестам мы всегда будем рады :)
Source maps пока нет, но обязательно будет, т.к. он нужен для полноценной поддержки TypeScript.
Вообще, интерфейс в VS можно довольно гибко настраивать. Скрытие тулбаров по right-click на ним — это достаточно стандартная вещь, но можно также индивидуально скрывать команды, причем не только на тулбарах, но и на главном меню — это все живет в Tools -> Customize. Т.е. при желании можно очень сильно упростить интерфейс под себя. Причем это можно сохранить через Tools -> Import and Export Settings, и потом таскать с собой на новые машины.
Так вот, мысль состоит в том, чтобы сделать упрощенные профили под Python и Node разработчиков из коробки — убрать все, не относящиеся к делу менюшки и тулбары, и так далее. Нечто, что было бы как минимум «good enough» для большинства людей, привыкших к SlickEdit, Sublime и т.д.
Отсутствием состояния.
> Так ведь изначально от этого осознанно ушли.
Множественное наследование является злом при наличии состояния. При его отсутствии, все становится намного проще, почему его и вернули.
> Еще ни разу не было необходимости в дефолтных реализациях методов интерфейса.
Необходимости на самом деле нет ни в классах, ни в циклах (все можно написать на if/goto и глобальных переменных). Речь об удобстве. Посмотрите еще раз, насколько богаче стали новые интерфейсы коллекций, и насколько удобнее их стало использовать. Теперь представьте себе, что было бы, если бы для каждой конкретной реализации коллекции её автору пришлось бы реализовывать все эти методы самому с нуля.
Как будет с обновлениями в финальном релизе, мы пока еще детально не планировали. Но, скорее всего, как и с PTVS, мы добавим NTVS в WebPI, в дополнение к обычным установщикам. NuGet — это все же больше для библиотек и фреймворков.
Если команда, занимающаяся джаваскриптом в MS (а это другая команда!), завтра вдруг выпустит консольную версию с поддержкой ноды, то мы ее, разумеется, поддержим — в дополнение к основному интерпретатору, аналогично IronPython в PTVS. То же самое для любых других сторонних реализаций, если они в разумной мере совместимы с обычной нодой (т.е., в частности, используют её протокол отладки).
Я понимаю ваш скепсис, но задача нашего продукта — это не приватизировать ноду, а привлечь существующих разработчиков под неё на VS и Azure. Поэтому поддерживать мы будем в первую очередь всегда те реализации, библиотеки etc, которые широко использует community.
Если присмотреться, на скриншоте фигурирует node.exe.
В частности, в альфе NTVS, вся работа с npm — это Red Gate.