Re[23]: Visual C# vs C++. Надо сравнить перспективы. - Компьютерные священные войны

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

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

S>> А что? Его использует CLR и джитит если нужно. Так что они не могут быть разными. Там вся проблема в рефлексии.
I>Еще раз повторюсь: выход принципиально нового компилятора С++ в майкрософт лет 13 назад был просто событием. Никакой не супер революцией, делающей прорыв в языке. Хотя он приципиально новый, с нуля написанный, стол нормально поддерживать стандарт, оптимизация кода вышла на новый уровень и все такое.
I>Тут тоже самое.

Еще раз. Проблема не в компиляторе, а в CLR и JIT.
NGEN это тот же JIT только предварительный. У него проблемы с рефлексией и скоростью компиляции. То есть компиляция должна быть быстрой в ущерб оптимизации кода, рефлексия не дает максимально использовать регистры SIIMD ,инлайнинг итд итп

У .Net Native нет ограничений и он может использовать любой компилятор. Необязательно от MS.
Тот же Unity использует IL2CPP. А вот сборки должны быть под NetStandad

https://msdn.microsoft.com/ru-ru/magazine/mt590967.aspx

Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)

Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности. Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.

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

lpd>Но мне кажется идея создания промежуточного кода избыточной. Возможно, что это вопрос вкуса, однако в IT простые инструменты нередко выигрывают у сложных(unix) и монструзоных(Windows и .NET).

Не избыточна. Вот смотри пример. Сейчас при разработке на C++ приложения под Андроид приходится пихать в дистрибутив (apk) от 2 (самые распространённые) до 6 (теоретический максимум в данный момент, охватывающий точно всё) версий приложения, под разные процессорные архитектуры. Если бы вместо этого мы компилировали приложение в llvm, а потом при инсталляции приложения на устройство перекомпилировали в машинные коды процессора данного устройства (кстати, в современном Андроиде именно так и происходит с Java кодом), то можно было бы класть только одну версию приложения в дистрибутив, что гораздо удобнее и экономнее. Причём это всё было бы без малейших потерь в производительности.

lpd>Все же C#/Java как языки програмирования немного получают за счет потерь производительности. Впрочем, я не хочу начинать этот спор сначала, а просто подытожил свое мнение, т.к. дискусия ушла от обсуждения следствий низкой скорости C#/Java к ее причинам.

В этом смысле у тебя довольно забавно вышла дискуссия в данной теме. Ты с ходу верно указал на разницу в производительности C++ и C#/Java и даже верно назвал приблизительный порядок цифр. Хотя при этом твоё понимания причин этой разницы было не верным. )))

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

_>>Ну и где там например WPF (это же стандартная библиотека .Net'а, не так ли?)?
Q>Нет, WPF в .NET Standard 1.6 не входит.

Это всё смешные отмазки новорождёнными "стандартами" (хотя никто их не использует) и т.п. Давай лучше по сути. Вот у меня есть приложение на .Net написанное для винды с помощью WPF (это же стандартная библиотек для этих целей, входящая в .Net, предустановленная на винде, и рекомендуемая прямо в этой теме адептами .Net). Получается что я не смогу запустить это приложение на таком же десктопе, но под Линухом, правильно? ) И к чему тогда разговоры о какой-то кроссплатформенности? )

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

_>Это всё смешные отмазки новорождёнными "стандартами" (хотя никто их не использует) и т.п.

Их очень много кто уже использует. Посмотри в NuGet, например. (Кстати, что там в C++ с дистрибуцией пакетов?)

_>Давай лучше по сути. Вот у меня есть приложение на .Net написанное для винды с помощью WPF (это же стандартная библиотек для этих целей, входящая в .Net, предустановленная на винде, и рекомендуемая прямо в этой теме адептами .Net).

Нет, это не стандартная библиотека. Она входит в .NET Framework и UWP, но не входит в Xamarin/Mono и .NET Core.

_>Получается что я не смогу запустить это приложение на таком же десктопе, но под Линухом, правильно? ) И к чему тогда разговоры о какой-то кроссплатформенности? )

MFC тоже не входит в стандартную библиотеку C++. Хотя входит в поставку макрософтовских библиотек под Windows. Её ты тоже не сможешь запустить под Линуксом.

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

I>Вот тут инетерсно. С однйо стороны пожалуй соглашусь, что скриптовый язык и c++ в теории могут быть интересными. Тот же Node.js демонстрирует это. С другой стороны, js — это боль, питон так и не взлетел, typescript вполне годный вариант, но он сыроват и молод.

Питон не взлетел? ) Смешно. ) Например в области HPC и научных вычислений он вообще занимает полностью доминирующую роль. А так же весьма популярен и при разработке игр (например те же танчики от варгейминга — это C++ и Python) и как язык серверных скриптов в вебе (одно время с популярностью фреймворка Django мог соперничать разве что RoR и только сравнительное недавно их популярность затмила собой мода на node.js). Ещё он очень часто встречается в качестве встроенного скриптового языка в различных тяжёлых профессиональных продуктах (различных CAD'aх, 3D редакторах и т.п.). И это мы говорили только о его роли в качестве компонента сложного приложения — помимо этого же ещё существует множество полезных инструментов на чистом Питоне.

Что касается JS, то он берёт именно своей простотой (Питон всё же лучше изучать, т.к. там есть много нетривиальных возможностей для написания более красивого кода, а на JS можно научить писать за пару минут). Плюс у него имеется общедоступных движок с наверное самой лучшей производительностью среди всех подобных языков. Кстати, для коротких скриптов (а сложные приложения на подобном языке вообще кажутся мне бредом) на мой взгляд лучше не использовать typescript, т.к. в таком случае он только увеличивает объём кода без всякой пользы.

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

S> Давай рассмотрим нынешние дефекты
S>1. Для сборщика мусора нужно подготавливать точки для остановки потока для сборки мусора
S>2. Выделение памяти для объектов на стеке и автоматический финализатор для них. В этом направлении сейчас ведутся работы
S>3. Работа напрямую с нативной памятью. Тоже ведутся работы.
S>4. Нет инлайнинга для делегатов,интерфейсов там где можно вывести код на стадии компиляции, но и здесь ведутся работы пример Roslin Linq
S>5. Net Native сейчас только на начальном пути развития, но уже сейчас может оптимизировать компиляцию Il кода используя компилятор С++

Это не верный список. В нём нет части важных пунктов. И есть какие-то сомнительные (что такой нативная память?).

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

_>>Если же ты утверждаешь, что C# в данное время развивается в сторону улучшения производительности, то с этим как бы никто и не спорил. Это ясно видно из многих материалов, в том числе и твоих ссылок.
S> Ну я просто считаю, что у С++ просто уменьшится доля, там где скорость будет достаточно близка.
S>Только это будет не скоро. А к тому времени, может и С++ будет совсем иным.

Дело в том, что написание производительного приложения на C# требует приложения специальных усилий, которые сразу убивают на корню его главное преимущество (возможность использования не самых продвинутых кодеров). Так то предположение маловероятное. )

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

ARK>>"Нет IL кода" совершенно не эквивалентно "использует бекенд C++" (и особенно к месту пафос "наверное открою секрет"

).
I>Именно, Ngen написан на С++, соответсвтенно сам является "бекендом С++". Не больше и не меньше.

Под "бекендом С++" естественно везде подразумевается использование оптимизатора машинных кодов из компилятора C++ (который даже производства MS (не самый лучший среди своих коллег) на голову выше того, что используется в обычном .Net).

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

ARK>>>Unity — 10, Xamarin — 5. Когда в Unity появился C#, не знаю, изначально этот движок вообще был только под мак.
A>C# там был с начала.

Совершенно верно. В качестве одного из скриптовых языков. А сам движок написан на C++. Не так ли? )

A>Честно говоря, я не очень понимаю, зачем среднестатистическому шутеру C++. В них нагрузка больше на графику, чем на игровую логику. Тут скорее С++ нужен не для шутеров, а просто для движков.

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

A>Рендер, физика, анимация на C++, а игровая логика в зависимости от требований проекта на C++, C#, Lua, Python, что там ещё есть...

А вот тут совершенно справедливая мысль. Правда как-то странно коррелирующая с предыдущим же предложением. )))

A>Если у тебя специфический проект, типа Total War, Factorio, какой-нибудь открытый мир невообразимых размеров вроде Just Cause 3, то ты его пишешь с нуля на С++ именно под этот проект. Если проект менее амбициозный, берёшь существующий движок и, независимо от жанра, пишешь логику на том, на чём этот движок предлагает. Причём в скорость скорее упрутся игры с тяжёлой симуляцией, типа Cities Skylines, чем шутеры.

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

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

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

S>> Давай рассмотрим нынешние дефекты
S>>1. Для сборщика мусора нужно подготавливать точки для остановки потока для сборки мусора
S>>2. Выделение памяти для объектов на стеке и автоматический финализатор для них. В этом направлении сейчас ведутся работы
S>>3. Работа напрямую с нативной памятью. Тоже ведутся работы.
S>>4. Нет инлайнинга для делегатов,интерфейсов там где можно вывести код на стадии компиляции, но и здесь ведутся работы пример Roslin Linq
S>>5. Net Native сейчас только на начальном пути развития, но уже сейчас может оптимизировать компиляцию Il кода используя компилятор С++

_>Это не верный список. В нём нет части важных пунктов. И есть какие-то сомнительные (что такой нативная память?).

http://rsdn.org/forum/dotnet/6660816.1
https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

_>В любом случае, даже уже в этом твоём списке видны неустранимые причины (типа того же сборщика мусора), которые никогда не позволят догнать. А если добавить ещё скажем рефлексию и ещё несколько пунктов, то сразу всё станет ясно.

Опять же не читаешь.

http://rsdn.org/forum/dotnet/6661629.1
Планируется

Заметных с точки зрения GC проблем в принципе четыре:
* куча аллокаций в gc0 для IEnumerable<>, string.Format() etc. — это как раз stackalloc сотоварищи.
* долгоживущие объекты в огромных количествах — может быть решено через ArrayPool<T>, Memory<T>, explicit heaps etc.
* pinned objects в GC0 и большие короткоживущие массивы — пулинг ч/з ArrayPool<T> обычно.
* большие коллекции — chunked-коллекции поверх ArrayPool<T>

Что касается .Net Native, то там по сути рефлексия ограничена и сведена к минимуму.

_>>>Если же ты утверждаешь, что C# в данное время развивается в сторону улучшения производительности, то с этим как бы никто и не спорил. Это ясно видно из многих материалов, в том числе и твоих ссылок.
S>> Ну я просто считаю, что у С++ просто уменьшится доля, там где скорость будет достаточно близка.
S>>Только это будет не скоро. А к тому времени, может и С++ будет совсем иным.

_>Дело в том, что написание производительного приложения на C# требует приложения специальных усилий, которые сразу убивают на корню его главное преимущество (возможность использования не самых продвинутых кодеров). Так то предположение маловероятное. )

Посмотрим. Сам сейчас собираюсь плагин для хрома на С++ писать.

Использование в TypeScript классов .Net
По этим мануалам https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Visual-Studio

Так, что от С++ не уйти.

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

_>Я имел в виду как раз инлайнинг, точнее его потенциальную возможность (а осуществлять его или нет компилятор решает сам в зависимости от вида функции — для мелких можно считать гарантированно заинлайнит).

Ну т.е. я тебя правильно понял и речь была о замене косвенного вызова (виртуального) на прямой?

_>Но даже если говорить про прямой вызов, то как по твоему компилятор C# будет способен это сделать, если там всегда можно написать такой код (где B и C наследники A; а f — виртуальная функция, переопределённая в них):
_>

_>A a;
_>if(х) a=new B();
_>else a=new C();
_>a.f();
_>

_>Как по твоему компилятор сможет подставить здесь прямой вызов? )

Ессно никак, и будет виртуальный вызов, так же как и в C++ я думаю, ведь это чисто полиморфный код, нет?

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

_>>Давай лучше по сути. Вот у меня есть приложение на .Net написанное для винды с помощью WPF (это же стандартная библиотек для этих целей, входящая в .Net, предустановленная на винде, и рекомендуемая прямо в этой теме адептами .Net).
Q>Нет, это не стандартная библиотека. Она входит в .NET Framework и UWP, но не входит в Xamarin/Mono и .NET Core.

Угу, интересно как много программистов на .net думают аналогично (подозреваю что все эти .NET Core и т.п. до сих пор выглядят странной экзотикой для большинства).

Но не в этом суть. Ты лучше скажи, что мне взять, чтобы написать десктопное приложение на .net работающее и под виндой и под линухом. Или снова будем звать на помощь C/C++ библиотеки?

_>>Получается что я не смогу запустить это приложение на таком же десктопе, но под Линухом, правильно? ) И к чему тогда разговоры о какой-то кроссплатформенности? )
Q>MFC тоже не входит в стандартную библиотеку C++. Хотя входит в поставку макрософтовских библиотек под Windows. Её ты тоже не сможешь запустить под Линуксом.

Т.е. ты хочешь сказать, что в мире C# отношение к WPF приблизительно такое же, как в мире C++ к MFC? Я правильно понял твою мысль?

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

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

lpd>>Но мне кажется идея создания промежуточного кода избыточной. Возможно, что это вопрос вкуса, однако в IT простые инструменты нередко выигрывают у сложных(unix) и монструзоных(Windows и .NET).

_>Не избыточна. Вот смотри пример. Сейчас при разработке на C++ приложения под Андроид приходится пихать в дистрибутив (apk) от 2 (самые распространённые) до 6 (теоретический максимум в данный момент, охватывающий точно всё) версий приложения, под разные процессорные архитектуры. Если бы вместо этого мы компилировали приложение в llvm, а потом при инсталляции приложения на устройство перекомпилировали в машинные коды процессора данного устройства (кстати, в современном Андроиде именно так и происходит с Java кодом), то можно было бы класть только одну версию приложения в дистрибутив, что гораздо удобнее и экономнее. Причём это всё было бы без малейших потерь в производительности.

Конкретно для Android необходимость поддержки разных процессоров операционной системой, на мой взгляд, сомнительна.
Более значительным преимуществом является безопасность кода по сравнению с C, однако эту проблему можно решить и без байткода.
Сейчас же Java и C# популярны в основном из-за наличия более проработанных фреймворков и средств сборки по сравнению с C++, а не из-за принципиальных преимуществ, которые дает байткод.
Хотя идея перенести часть процесса компиляции в рантайм или на этап инсталляции интересна. Однако портабельность сужает круг задача, которые код может решить. А портабельность как раз больше нужна в embedded системах. Вообщем, субъективно я бы предпочел, чтобы программа была представлена ввиде привычных машинных инструкций, а не скармливалась JVM-монстру. Но допускаю, что у других людей мнение может быть отличное.

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

_>>Это не верный список. В нём нет части важных пунктов. И есть какие-то сомнительные (что такой нативная память?).
S>http://rsdn.org/forum/dotnet/6660816.1
S>https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

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

_>>В любом случае, даже уже в этом твоём списке видны неустранимые причины (типа того же сборщика мусора), которые никогда не позволят догнать. А если добавить ещё скажем рефлексию и ещё несколько пунктов, то сразу всё станет ясно.
S> Опять же не читаешь.
S>http://rsdn.org/forum/dotnet/6661629.1

Что не читаю? ) Раздел dotnet RSDN'а? Да, не читаю)))

S>Планируется
S>

S>Заметных с точки зрения GC проблем в принципе четыре:
S> * куча аллокаций в gc0 для IEnumerable<>, string.Format() etc. — это как раз stackalloc сотоварищи.
S> * долгоживущие объекты в огромных количествах — может быть решено через ArrayPool<T>, Memory<T>, explicit heaps etc.
S> * pinned objects в GC0 и большие короткоживущие массивы — пулинг ч/з ArrayPool<T> обычно.
S> * большие коллекции — chunked-коллекции поверх ArrayPool<T>

Ну ты же сам понимаешь, что это реально не решит проблему.

S> Что касается .Net Native, то там по сути рефлексия ограничена и сведена к минимуму.

Кстати, а вот тут было бы интересно посмотреть поподробнее. А то я про это слышал, но конкретные технические подробности не изучал. Что значит сведена к минимуму?

S> Посмотрим. Сам сейчас собираюсь плагин для хрома на С++ писать.
S>Использование в TypeScript классов .Net
S> По этим мануалам https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Visual-Studio
S> Так, что от С++ не уйти.

Не очень понял что конкретно ты хочешь там сделать. Но ты уверен, что это ещё не сделано скажем в том же CEF?

P.S. Сборка вебкита под виндой — это весьма увлекательный квест. ))) Я помнится его когда-то проходил (причём ещё хотел всё сделать именно в своём окружение) и впечатления до сих пор яркие. )))

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

_>Угу, интересно как много программистов на .net думают аналогично (подозреваю что все эти .NET Core и т.п. до сих пор выглядят странной экзотикой для большинства).

Не так уж много программистов на C++ подозревают, что есть какие-то там циферки после плюсов: C++11, C++14, C++17. Все эти && и move-семантика выглядят странной экзотикой для большинства.

_>Но не в этом суть. Ты лучше скажи, что мне взять, чтобы написать десктопное приложение на .net работающее и под виндой и под линухом. Или снова будем звать на помощь C/C++ библиотеки?

Гуйнёй я не занимаюсь, подробно не скажу. Последний раз, когда делал интерфейс утилитки для выкладки в Google Play Store, использовал Unity. Работало одинаково на Windows и Android.

_>>>Получается что я не смогу запустить это приложение на таком же десктопе, но под Линухом, правильно? ) И к чему тогда разговоры о какой-то кроссплатформенности? )
_>Т.е. ты хочешь сказать, что в мире C# отношение к WPF приблизительно такое же, как в мире C++ к MFC? Я правильно понял твою мысль? :)))

А почему ты задаёшь столько вопросов? Тебе нравится вести в такой манере дискуссии? У тебя все экзаменуемые или что? Проще говоря: ты вообще что за **й, чтоб кого-то так снисходительно экзаменовать? скобка-скобка-скобка

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

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

Ну да. Просто в C++ вслед за этой заменой в большинстве случаев последует и инлайнинг.

_>>Но даже если говорить про прямой вызов, то как по твоему компилятор C# будет способен это сделать, если там всегда можно написать такой код (где B и C наследники A; а f — виртуальная функция, переопределённая в них):
_>>

_>>A a;
_>>if(х) a=new B();
_>>else a=new C();
_>>a.f();
_>>

_>>Как по твоему компилятор сможет подставить здесь прямой вызов? )
_>Ессно никак, и будет виртуальный вызов, так же как и в C++ я думаю, ведь это чисто полиморфный код, нет?

Конечно. Но нюанс в том, что подобный код не скомпилируется в C++. Там у тебя или явно полиморфный объект (ссылка или указатель) или явно нет (обычная переменная и именно их большинство в нормальном коде). Так что в последнем случае компилятор может абсолютно гарантированно подставлять нужный вызов. В отличие от C#, где любой объект может быть инициализирован экземпляром другого класса где-то выше по коду. И как по твоему решает это проблему компилятор C#? )

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

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

_>>>Это не верный список. В нём нет части важных пунктов. И есть какие-то сомнительные (что такой нативная память?).
S>>http://rsdn.org/forum/dotnet/6660816.1
S>>https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

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

_>>>В любом случае, даже уже в этом твоём списке видны неустранимые причины (типа того же сборщика мусора), которые никогда не позволят догнать. А если добавить ещё скажем рефлексию и ещё несколько пунктов, то сразу всё станет ясно.
S>> Опять же не читаешь.
S>>http://rsdn.org/forum/dotnet/6661629.1

_>Что не читаю? ) Раздел dotnet RSDN'а? Да, не читаю)))

А зря. Просто я уже по нескольку раз ссыоки апутался ет.
S>>Планируется
S>>

S>>Заметных с точки зрения GC проблем в принципе четыре:
S>> * куча аллокаций в gc0 для IEnumerable<>, string.Format() etc. — это как раз stackalloc сотоварищи.
S>> * долгоживущие объекты в огромных количествах — может быть решено через ArrayPool<T>, Memory<T>, explicit heaps etc.
S>> * pinned objects в GC0 и большие короткоживущие массивы — пулинг ч/з ArrayPool<T> обычно.
S>> * большие коллекции — chunked-коллекции поверх ArrayPool<T>

_>Ну ты же сам понимаешь, что это реально не решит проблему.

Это уменьшает нагрузку на GC. В том числе может сразу применять финализаторы исинга.

S>> Что касается .Net Native, то там по сути рефлексия ограничена и сведена к минимуму.

_>Кстати, а вот тут было бы интересно посмотреть поподробнее. А то я про это слышал, но конкретные технические подробности не изучал. Что значит сведена к минимуму?

https://msdn.microsoft.com/ru-ru/library/dn600640(v=vs.110).aspx

Среда выполнения .NET Native не включает JIT-компилятор. В результате все необходимые машинные коды должны быть созданы заранее. Используется набор эвристических правил, чтобы определить, какой код должен создаваться, но они не могут охватывать все возможные сценарии метапрограммирования. Таким образом, необходимо предоставить подсказки для этих сценариев метапрограммирования с помощью директив среды выполнения. Если необходимые метаданные или код реализации недоступны во время выполнения, приложение вызывает исключение MissingMetadataException, MissingRuntimeArtifactException или MissingInteropDataException. Существуют два средства устранения неполадок, создающие соответствующую запись для файла директив среды выполнения, который устраняет исключение.

S>> Посмотрим. Сам сейчас собираюсь плагин для хрома на С++ писать.
S>>Использование в TypeScript классов .Net
S>> По этим мануалам https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Visual-Studio
S>> Так, что от С++ не уйти.

_>Не очень понял что конкретно ты хочешь там сделать. Но ты уверен, что это ещё не сделано скажем в том же CEF?
Да под .Net Core вообще мало сделано. А использование манагед его 2 статьи кроме моих.

_>P.S. Сборка вебкита под виндой — это весьма увлекательный квест. ))) Я помнится его когда-то проходил (причём ещё хотел всё сделать именно в своём окружение) и впечатления до сих пор яркие. )))

Вот и мне плохо. При этом, что я С++ знаю постольку поскольку.

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

_>>>Но даже если говорить про прямой вызов, то как по твоему компилятор C# будет способен это сделать, если там всегда можно написать такой код (где B и C наследники A; а f — виртуальная функция, переопределённая в них):
_>>>

_>>>A a;
_>>>if(х) a=new B();
_>>>else a=new C();
_>>>a.f();
_>>>

_>>>Как по твоему компилятор сможет подставить здесь прямой вызов? )
_>>Ессно никак, и будет виртуальный вызов, так же как и в C++ я думаю, ведь это чисто полиморфный код, нет?

_>Конечно. Но нюанс в том, что подобный код не скомпилируется в C++.

Ну типа я в курсе

, добавим для C++ к A звездочку, я так понял что ты предостаивл типа псевдокод похожтй на C#/java

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

Тут тоже интересная тема, чем отличается для компилятора A a; a.f.();, от A* a; a->f(); , что сlang ,что gcc генерят в последнем случае косвенный вызов.

_>В отличие от C#, где любой объект может быть инициализирован экземпляром другого класса где-то выше по коду. И как по твоему решает это проблему компилятор C#? )

Никак, т.е влоб — полиморфно, так же ка и в C++

От:	Qbit86	https://twitter.com/qbit86
Дата:	13.01.17 13:48
Оценка:

От:	Qbit86	https://twitter.com/qbit86
Дата:	13.01.17 14:03
Оценка:	+1

	От:	itslave
	Дата:	13.01.17 16:19
	Оценка:	-1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	13.01.17 17:11
Оценка:	+1

	От:	alex_public
	Дата:	14.01.17 12:44
	Оценка:	+1