Здравствуйте, 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

Автор: Sinix
Дата: 09.01.17

https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

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

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

http://rsdn.org/forum/dotnet/6661629.1

Автор: Sinix
Дата: 10.01.17

Планируется

Заметных с точки зрения 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

Автор: Serginio1
Дата: 12.01.17

По этим мануалам https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Visual-Studio

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