Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 28.08.21 15:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Собсно, изначально "пакет" противопоставлялся программе или установленной в систему библиотеке.

V>>Отмечалось ключевое, что программа или библиотека ничего не знают о "пакете", но "пакет" знает о них.
S>Это где это оно так отмечалось?

Это с рождения условие существования.
(тут маты, маты, маты...)

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


V>>Если же перейти на "пакеты времени сборки", то вся тыщща целевых установленных программ будет тыщщу раз дублировать свои зависимости, верно?

S>Нет конечно. Это же ортогональные вещи.

Ес-но, ортогональные.
(тут маты, маты, маты...)

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


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

V>>Ес-но, программисту всегда лучше, чтобы юзер его, Великого, не отвлекал своими мелкими потребностями.
V>>Потому что Он — Творит.
S>Вижу, до reproducible builds вы ещё не доросли. Ну, ок.

В смысле, до перевода выделенного на английский?
И добавления усилительного "не доросли"?
Синклер, ты хоть отдаешь себе отчёт, что после этих двух эээ... скажем, "махинаций" никакого нового смысла не появилось?
Или связь с реальностю истончилась окончательно? ))

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

Тебе ответ прямой речью подсказали еще в прошлый раз.
Как так вышло, что вместо попытки хотя бы просто запомнить, ты стал оспаривать, по-сути, таблицу умножения, т.е. аксиомы?
Пипец днище. ))
Отредактировано 28.08.2021 15:08 vdimas . Предыдущая версия .
Re[32]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.08.21 18:26
Оценка:
Здравствуйте, vdimas, Вы писали:
V>Ну а мне требуется System.Runtime.CompilerServices.Unsafe, и?
V>Мне это надо, чтобы не сливать хотя бы ноде.
А ты проверял? https://stackoverflow.com/questions/49731480/system-runtime-compilerservices-unsafe-produce-unexpected-behavior-in-xamarin-fo?rq=1
Здесь прекрасно используют. А вот и бэнчмарки, где нода сливает Net
https://www.techempower.com/benchmarks/
V>Я тебя умоляю... без поддержки новейших фич языка и платформы Хamarin превращается в подобие VB, а в ноде я могу прикрутить требуемую функциональность через плюсы.
V>Причём, вызов нейтивного кода из ноды в разы дешевле, чем из дотнета.

https://docs.microsoft.com/ru-ru/dotnet/standard/net-standard
Поддержка .NetStandard 2.1 и C# 9
https://stackoverflow.com/questions/64786495/is-it-possible-to-use-c-sharp-9-for-xamarin

Ну и по бэнчмаркам уступает в производительности
https://www.techempower.com/benchmarks/

S>>Другой вопрос, что для мобилок грохнули ось. Хотя по сути UWP там более востребован.


V>Дык, это ж ключевое.

V>Близко ходишь, но не замечаешь — у них нет проблем разработать дотнет-кор под Андроид или iOS.

V>Под iOS иногда обыгрываю мелкие различия с линуховым прочтением POSIX — там понты работы.

Ну под IOS то там как раз аналог .Net Native так, что под IOS они сделали то о чем ты говоришь.
Кстати как там Node на IOS?
V>Под Андроид работы тоже немного, т.е., имеющиеся исходники дотнета можно заставить собраться для arm64-андроида, допилить чуть сборку, портировать SSL-слой на boring SSL, перекинуть CRT-зависимости с GNU-либ на гугло-андроидные и т.д.
Там как раз использование Java и котлин библиотек коих куча.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 29.08.2021 5:29 Serginio1 . Предыдущая версия . Еще …
Отредактировано 28.08.2021 18:33 Serginio1 . Предыдущая версия .
Re[5]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 29.08.21 01:11
Оценка:
Здравствуйте, vfedosov, Вы писали:

Б>>>На питоне приятно писать — быстро и удобно.


M>>А вот тут я бы поспорил


V>Работал и на шарпе и на пайтоне. Пайтон впечатлил в плане скорости реализации логики. Если проект в одно рыло пишешь, то пайтон делает шарп в разы по скорости разработки. При командной разработке есть нюансы. Например, пайтон располагает к использованию tupple, которые по сути помойка с данными и разбираясь в чужем коде, сложно понять чего там конкретно лежит. Ну и прочие минусы отсутствия строгой типизации начинают вылазить. Думаю, что для коммандного проекта средней сложности, выгода от использования пайтона не так очевидна. А при высокой сложности, сопровождение может стать проблемой. Но это в комманде. А когда работаешь один — наслаждаешься эффективностью.


После тыщи-двух строк кода, даже своего, любой проект на питоне скатывается в лютое гавно, в котором хрен разберёшься. Годен только как замена башу или bat-файлам
Маньяк Робокряк колесит по городу
Re[33]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 29.08.21 10:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

V>>Ну а мне требуется System.Runtime.CompilerServices.Unsafe, и?

V>>Мне это надо, чтобы не сливать хотя бы ноде.
S> А ты проверял? https://stackoverflow.com/questions/49731480/system-runtime-compilerservices-unsafe-produce-unexpected-behavior-in-xamarin-fo?rq=1

Примерно год назад проверял, когда делал попытки портировать наш .Net Core продукт на Андрод.


S>Здесь прекрасно используют. А вот и бэнчмарки, где нода сливает Net

S>https://www.techempower.com/benchmarks/

По ссылке тесты веб-фреймворков, т.е. большого пласта писанной на технологии логики.
Ес-но, чистый JS сливает чистому C#, неужели ты пытаешься приписать мне иное? ))

В моем случае в ноде будет обёртка над уже приличной функциональностью в нейтиве, поэтому, играет рояль только эффективность интеропа.
CompilerServices.Unsafe позволяет при грамотном подходе этот интероп, считай, ополовинить.


V>>Я тебя умоляю... без поддержки новейших фич языка и платформы Хamarin превращается в подобие VB, а в ноде я могу прикрутить требуемую функциональность через плюсы.

V>>Причём, вызов нейтивного кода из ноды в разы дешевле, чем из дотнета.
S>https://docs.microsoft.com/ru-ru/dotnet/standard/net-standard
S>Поддержка .NetStandard 2.1 и C# 9

Ошибочка, в xamarin поддержка только .NetStandard 2.0


S>https://stackoverflow.com/questions/64786495/is-it-possible-to-use-c-sharp-9-for-xamarin


И здесь тоже подтверждается.


V>>Под iOS иногда обыгрываю мелкие различия с линуховым прочтением POSIX — там понты работы.

S> Ну под IOS то там как раз аналог .Net Native так, что под IOS они сделали то о чем ты говоришь.
S>Кстати как там Node на IOS?

https://www.npmjs.com/package/nodejs-mobile-cordova
Но я не специалист в cordova, т.е. подробностей не в курсе.


V>>Под Андроид работы тоже немного, т.е., имеющиеся исходники дотнета можно заставить собраться для arm64-андроида, допилить чуть сборку, портировать SSL-слой на boring SSL, перекинуть CRT-зависимости с GNU-либ на гугло-андроидные и т.д.

S> Там как раз использование Java и котлин библиотек коих куча.

Не нужны, под капотом там обычные линуха.
Re[34]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.08.21 14:03
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>>>Ну а мне требуется System.Runtime.CompilerServices.Unsafe, и?

V>>>Мне это надо, чтобы не сливать хотя бы ноде.
S>> А ты проверял? https://stackoverflow.com/questions/49731480/system-runtime-compilerservices-unsafe-produce-unexpected-behavior-in-xamarin-fo?rq=1

V>Примерно год назад проверял, когда делал попытки портировать наш .Net Core продукт на Андрод.


Ну а народ использует. Может галочку, про небезопасный код не поставил?
Попробуй.
S>>Здесь прекрасно используют. А вот и бэнчмарки, где нода сливает Net
S>>https://www.techempower.com/benchmarks/

V>По ссылке тесты веб-фреймворков, т.е. большого пласта писанной на технологии логики.

V>Ес-но, чистый JS сливает чистому C#, неужели ты пытаешься приписать мне иное? ))

V>В моем случае в ноде будет обёртка над уже приличной функциональностью в нейтиве, поэтому, играет рояль только эффективность интеропа.

V>CompilerServices.Unsafe позволяет при грамотном подходе этот интероп, считай, ополовинить.
Обертку можно и на том же C# использовать. Только сейчас RuyJit и так хорош.

V>>>Я тебя умоляю... без поддержки новейших фич языка и платформы Хamarin превращается в подобие VB, а в ноде я могу прикрутить требуемую функциональность через плюсы.

V>>>Причём, вызов нейтивного кода из ноды в разы дешевле, чем из дотнета.
S>>https://docs.microsoft.com/ru-ru/dotnet/standard/net-standard
S>>Поддержка .NetStandard 2.1 и C# 9

V>Ошибочка, в xamarin поддержка только .NetStandard 2.0

То есть ты не веришь, то что MS пишет? 2.1
Xamarin.iOS 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.14 12.16
Xamarin.Mac 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.8 5.16
Xamarin.Android 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 10.0
S>>https://stackoverflow.com/questions/64786495/is-it-possible-to-use-c-sharp-9-for-xamarin

V>И здесь тоже подтверждается.


Подтверждается, что поддерживается, что кто то прописал 2.0 вместо 2.1 ?
<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <LangVersion>9.0</LangVersion>
    </PropertyGroup>
    .....
    .....
</Project>


Сейчас проверил в студии выбирается standard 2.1

 <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
    <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
  </PropertyGroup>


Ты хоть проверяй то, о чем пишешь. Год назад может и не было. Сейчас есть.

V>>>Под iOS иногда обыгрываю мелкие различия с линуховым прочтением POSIX — там понты работы.

S>> Ну под IOS то там как раз аналог .Net Native так, что под IOS они сделали то о чем ты говоришь.
S>>Кстати как там Node на IOS?

V>https://www.npmjs.com/package/nodejs-mobile-cordova

V>Но я не специалист в cordova, т.е. подробностей не в курсе.
Ну да кордова, ионик. Короче костыли.

V>>>Под Андроид работы тоже немного, т.е., имеющиеся исходники дотнета можно заставить собраться для arm64-андроида, допилить чуть сборку, портировать SSL-слой на boring SSL, перекинуть CRT-зависимости с GNU-либ на гугло-андроидные и т.д.

S>> Там как раз использование Java и котлин библиотек коих куча.

V>Не нужны, под капотом там обычные линуха.

То есть библиотеки в линуксе есть на все случаи жизни? Нахрена народ пишет библиотеки?
Суть то как раз Xamarin.Android использовать по максимуму библиотеки Java и котлин.
и солнце б утром не вставало, когда бы не было меня
Re[30]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.08.21 03:23
Оценка:
V>А для моих задач — нет, не дорос еще дотнет.
V>Под линуха свой интероп, под винду свой, под макос свой.

V>Реализация банального poll по нескольким хендлам в дотнете безобразная — каждый раз создаётся массив в куче, невозможно ожидать в одном списке сокеты и какие-нить eventfd.

Ну так это же выносится в библиотечку размером в несколько килобайт, которая пилится под основные платформы; а всё остальное — platform independent.
Если не хотите выделять каждый раз массив в куче — велком в Span<T>, и можете его хоть в стеке, хоть в пуле, хоть в куче держать. Делов-то.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 30.08.21 03:40
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Ну а народ использует. Может галочку, про небезопасный код не поставил?


Заинтересовался подробней, вот рецепт:

Finally I get the solution. One of the comments in the issue provided by @Gerald Versluis solve the problem:

I follow these steps of hongliyu2002 https://forums.realm.io/t/could-not-load-assembly-system-runtime-compilerservices-unsafe-during-startup-registration/974/4

Go to C:\Users%user%.nuget\system.runtime.compilerservices.unsafe\4.4.0, and delete "ref" folder then make a copy of "lib" folder and rename the copy back to "ref".
Cleanup all the "bin" and "obj" folders in the projects.
Rebuild and run..


Рука-лицо.
То бишь, моно подхватывает ref-ссылки, если они есть в пакете.


V>>В моем случае в ноде будет обёртка над уже приличной функциональностью в нейтиве, поэтому, играет рояль только эффективность интеропа.

V>>CompilerServices.Unsafe позволяет при грамотном подходе этот интероп, считай, ополовинить.
S>Обертку можно и на том же C# использовать.

Еще раз, медленно — интероп в C# медленный.
Требуется сокращать его до минимума.


S>Только сейчас RuyJit и так хорош.


Я именно тебе приводил не так давно тесты вызова interop или ф-ий через unsafe-указатели — результаты катастрофические.
В обоих случаях.


V>>Ошибочка, в xamarin поддержка только .NetStandard 2.0

S> То есть ты не веришь, то что MS пишет? 2.1
S>Xamarin.iOS 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.14 12.16
S>Xamarin.Mac 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.8 5.16
S>Xamarin.Android 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 10.0
S>>>https://stackoverflow.com/questions/64786495/is-it-possible-to-use-c-sharp-9-for-xamarin

V>>И здесь тоже подтверждается.


S>Подтверждается, что поддерживается, что кто то прописал 2.0 вместо 2.1 ?

S>
S><Project Sdk="Microsoft.NET.Sdk">
S>    <PropertyGroup>
S>        <TargetFramework>netstandard2.0</TargetFramework>
S>        <LangVersion>9.0</LangVersion>
S>    </PropertyGroup>
S>    .....
S>    .....
S></Project>
S>


S>Сейчас проверил в студии выбирается standard 2.1

S>
S> <PropertyGroup>
S>    <TargetFramework>netstandard2.1</TargetFramework>
S>    <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
S>  </PropertyGroup>
S>

S> Ты хоть проверяй то, о чем пишешь. Год назад может и не было. Сейчас есть.

А что именно ты проверил?
Создай прямо сейчас в VS2019 приложение из шаблона Xamarin class library.


V>>Не нужны, под капотом там обычные линуха.

S>То есть библиотеки в линуксе есть на все случаи жизни?

Не в Линухе, а "вообще".
Просто под линуха сбилдили эти либы и упаковали в пакеты.


S>Нахрена народ пишет библиотеки?


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


S>Суть то как раз Xamarin.Android использовать по максимуму библиотеки Java и котлин.


Бред несёшь.
Xamarin имеет прямой бинд к Android SDK, ему не джавовские либы нужны, а разве что доступ к датчикам, микрофону, камере и т.д.
И какие же это в опу "либы", если в самой Андроидной Джаве это лишь тонкие обёртки над нейтивом?
Это "просто АПИ".
Re[42]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.08.21 05:39
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:
V>Это с рождения условие существования.
V>(тут маты, маты, маты...)
А должны быть ссылки, ссылки, ссылки. Увы.

V>Буквально одной извилинкой шевельни — иначе как бы одни и те же программы или либы запросто распространялись что-то под сотню одновременно существующих сегодня независимых пакетных менеджеров и даже несколькими десятками сдохших на сегодня?

Да я-то шевельнул. Не очень понятно, что имеется в виду под "программа не знает о пакете".
В бинаре, понятное дело, никаких следов пакетного менеджера нет. А вот с точки зрения сборки и поставки — сейчас собственно "программа" или "библиотека" и есть пакет.
То есть именно он является результатом труда разработчика. Сборка пакета является частью билд-системы, за которую отвечает собсно исходный автор.
Те случаи, когда опакечивание выполняется посторонними, являются частным случаем — просто исходники собственно кода разрабатывает кто-то другой.
Т.е. вот я являюсь автором пакета, который сам при сборке зависит от чего-то внешнего — например, исходников, вытащенных из гитхаба или битбакета. Или бинарей, которые уже были кем-то собраны для моей целевой архитектуры, но не оформлены для моего пакетного менеджера.

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


V>Поэтому на выходе произведение.

V>А задачей пакетных менеджеров отродясь было давать сумму.
Вы, похоже, не понимаете основную мысль. Дело в том, что для сборки программы или библиотеки, зависящей от проекта А, нужны одни артефакты, а для исполнения — другие.
Ну, на пальцах — в рантайме вам нужен xxx.so файл для вашей зависимости, а при сборке нужен xxx.h файл(ы) (а без .so можно, в принципе, и обойтись).
Или, наоборот — при сборке вы используете .a, который вам в целевой системе нафиг не упал (и в результирующем пакете нет зависимости от xxx.a; она существует только в момент сборки).

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

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

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

V>>>Ес-но, программисту всегда лучше, чтобы юзер его, Великого, не отвлекал своими мелкими потребностями.
V>>>Потому что Он — Творит.
S>>Вижу, до reproducible builds вы ещё не доросли. Ну, ок.
V>В смысле, до перевода выделенного на английский?
V>И добавления усилительного "не доросли"?
V>Синклер, ты хоть отдаешь себе отчёт, что после этих двух эээ... скажем, "махинаций" никакого нового смысла не появилось?
А зачем вам новый смысл, когда вы старый ещё не усвоили?
Давайте я разжую помедленнее, чтобы вы успевали:
1. потребности пользователя вообще ортогональны деталям процесса сборки. Уверяю вас, юзеру абсолютно наплевать, используете ли вы при сборке инкрементальную компиляцию, модули, пакетный менеджер, процедурную генерацию исходников или ещё что-то. Поэтому оправдывать подход "мы там рисуем в зависимостях при билде любой питон новее 2.7" какими-то мифическими потребностями пользователя — очень странно.
2. Я понимаю, вам кажется, что из требования указывать конкретную версию зависимости в билде непосредственно следует прибитие гвоздями конечного продукта ровно к той же версии пакета — но нет, ключевое слово здесь "кажется".
Дело в том, что когда вы, как разработчик, пишете в зависимостях диапазон версий, то инженерная дотошность требует от вас тестирования хотя бы границ этого диапазона. То есть не просто "я думаю, что оно будет работать на версиях не младше 0.9.5, и не работать на версиях не младше 1.0.2", а у вас в процессе сборки проверяется совместимость с версиями 0.9.5. 0.9.6, 1.0.1.
А не просто "дай-ка мне, менеджер пакетов, что-то в этом диапазоне, и собери мой проект с ним".
3. Причины для этого вполне просты и понятны: допустим, вы делаете не так. Вот вы впервые собрали ваш проект с версией 0.9.5 вашей зависимости, и оптимистично написали: Requires xxx >= 0.9.5.
Однажды вы коммитите изменения в репозиторий. Ваш коллега забирает их к себе — упс, у него не работает! Падают тесты. Он расстроен вашей подставой, развлекается откатом изменений и прочими приседаниями. Вы тратите литр кофе, и выясняете: дело в том, что вышла новая версия xxx, 1.0.2, нечаянно стащилась при билде, а ваш коммит тут совершенно ни при чём. Вы добавляете Conflicts xxx >= 1.0.2 и на этом успокаиваетесь. Всё, вроде бы, работает.
Но потом, по мере изменения требований к вашему софту, вы вносите в ваш код изменения, которые отлично работают с версией xxx 1.0.1, но в версиях 0.9.5 и 0.9.6 — нет.
Если вы используете при сборке вот эту любимую вами способность пакетного менеджера оперировать диапазонами, то он вам стащит 1.0.1, и всё успешно соберётся и протестируется.
А вот у того самого юзера до сих пор стоит xxx 0.9.5. И при инсталляции менеджер пакетов не станет её обновлять, т.к. она совместима с вашими requires.
В итоге ваш софт у юзера либо упадёт, либо будет работать неверно.

Судя по вашей реакции на банальные словосочетания "воспроизводимость билда" и "контроль зависимостей", вас такая ситуация в целом устраивает.

Ничего плохого в этом нет — вон, начинающих студентов вполне устраивает, если программа компилируется. А работает она или нет — это уже не так важно.
Подрастут — начнут делать так, чтобы программа работала корректно хотя бы иногда. Но запросто могут игнорировать коды возврата или возможность вылета исключений.
Потом постепенно приходит понимание, что надо продумывать не только happy path, но и предусматривать различные альтернативные сценарии.

Именно об этом я и говорю, когда пишу, что вы не доросли до воспроизводимых билдов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ui
Re[36]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.08.21 06:01
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Еще раз, медленно — интероп в C# медленный.

V>Требуется сокращать его до минимума.
Эмм, а чего там медленного? Мне чисто так — в абстрактном смысле интересно. Я всегда полагал, что интероп в дотнете один из самых лучших на рынке. Особенно с версии 5.
И как вы ухитряетесь его сократить при помощи СompilerServices.Unsafe?
V>Я именно тебе приводил не так давно тесты вызова interop или ф-ий через unsafe-указатели — результаты катастрофические.
V>В обоих случаях.
Что-то сходу не могу найти тех тестов.
И, главное, как нода-то ухитряется сделать интероп быстрее? Там же должны все те же самые проблемы быть — маршалинг, переключение GC, всё такое?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ночной Смотрящий Россия  
Дата: 30.08.21 08:30
Оценка:
Здравствуйте, vfedosov, Вы писали:

V>Если проект в одно рыло пишешь, то пайтон делает шарп в разы по скорости разработки.


Можно пример именно логики, которую в разы быстрее на пайтоне?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[38]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ночной Смотрящий Россия  
Дата: 30.08.21 08:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

N>>Киев. У нас достаточно таких "правильных" кофеен. Но с чего бы это что-то изменило?

I>Если тренировать вкус, то рано или поздно начнешь чувствовать оттенки.

Самовнушение — великая сила
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.08.21 09:58
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

N>>>Киев. У нас достаточно таких "правильных" кофеен. Но с чего бы это что-то изменило?

I>>Если тренировать вкус, то рано или поздно начнешь чувствовать оттенки.

НС>Самовнушение — великая сила


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

Можешь сюда глянуть:
https://shop.tastycoffee.ru/blog/koleso-vkusov
Re[44]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ночной Смотрящий Россия  
Дата: 30.08.21 10:46
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Одна поправочка — TS активно вытесняет JS где угодно, кроме фронтенда.

V>Во фронтенде весьма неактивно.
V>Я бы сказал даже — никак не вытесняет.

Ангуляр и Vue это не фронтенд? Или 2 из 3 основных фронтовых фреймворков это никак не вытесняет? Вот так новость.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[45]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 30.08.21 11:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ангуляр и Vue это не фронтенд? Или 2 из 3 основных фронтовых фреймворков это никак не вытесняет?


И какая разница, на чём написаны сами эти фреймворки?
Хоть на ассемблере.

Фреймворки заточены под клиентский JS.
Angular.min.js (наиболее популярный включаемый файл) — прямым образом именно под JS.


НС>Вот так новость.


Угу, многовато новостей для тебя одного. ))
Re[36]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 30.08.21 12:15
Оценка:
Здравствуйте, vdimas, Вы писали:


V>Еще раз, медленно — интероп в C# медленный.

V>Требуется сокращать его до минимума.
Ну вот новые ссылки на функции вполне себе быстрые. https://dev.to/jeikabu/native-code-in-net-5-0-and-c-9-0-39h7

S>>Только сейчас RuyJit и так хорош.


V>Я именно тебе приводил не так давно тесты вызова interop или ф-ий через unsafe-указатели — результаты катастрофические.

V>В обоих случаях.


V>>>Ошибочка, в xamarin поддержка только .NetStandard 2.0

S>> То есть ты не веришь, то что MS пишет? 2.1
S>>Xamarin.iOS 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.14 12.16
S>>Xamarin.Mac 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.8 5.16
S>>Xamarin.Android 7.0 7.0 7.0 7.0 7.0 7.0 7.0 8.0 10.0
S>>>>https://stackoverflow.com/questions/64786495/is-it-possible-to-use-c-sharp-9-for-xamarin

V>>>И здесь тоже подтверждается.

То, что Xamarin.Android выше 10.0 поддерживает 2.1
S>>Подтверждается, что поддерживается, что кто то прописал 2.0 вместо 2.1 ?
S>>
S>><Project Sdk="Microsoft.NET.Sdk">
S>>    <PropertyGroup>
S>>        <TargetFramework>netstandard2.0</TargetFramework>
S>>        <LangVersion>9.0</LangVersion>
S>>    </PropertyGroup>
S>>    .....
S>>    .....
S>></Project>
S>>


S>>Сейчас проверил в студии выбирается standard 2.1

S>>
S>> <PropertyGroup>
S>>    <TargetFramework>netstandard2.1</TargetFramework>
S>>    <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
S>>  </PropertyGroup>
S>>

S>> Ты хоть проверяй то, о чем пишешь. Год назад может и не было. Сейчас есть.

V>А что именно ты проверил?

V>Создай прямо сейчас в VS2019 приложение из шаблона Xamarin class library.

Я создавал Xamarin.Forms там есть поддержка 2.1. Библиотеки независимы от ксамарин или чего еще. Это же .Net Standard!
Но создал приложение и установил пакет Microsoft.EntityFrameworkCore который под 2.1

S>>Нахрена народ пишет библиотеки?


V>Пока что на сегодня только в нейтиве на все случаи жизни и есть.

V>Любой не-нейтив в большинстве своём биндится к нейтивным библиотекам.
V>А которая оригинальная в не-нейтивных платформах библиотечная функциональность — так её кот наплакал.
V>Обычно оригинальное обитает в нише поддержки разработки, по понятной причине.

Угу. На Java и C# пишут наверное поболее библиоетек и главное используют их!

S>>Суть то как раз Xamarin.Android использовать по максимуму библиотеки Java и котлин.


V>Бред несёшь.

V>Xamarin имеет прямой бинд к Android SDK, ему не джавовские либы нужны, а разве что доступ к датчикам, микрофону, камере и т.д.
V>И какие же это в опу "либы", если в самой Андроидной Джаве это лишь тонкие обёртки над нейтивом?
V>Это "просто АПИ".
Сканеру, и прочему оборудованию. Куча готовых классов на Java на всякие случаи жизни. По твоему .Net это тонкая обертка на нативом?
Да вначале они так и делали, затем отказались. То же самое и с Java.

Ты давай .Net Standard 2.1 Я что зря время тратил?
и солнце б утром не вставало, когда бы не было меня
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.08.21 12:45
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Че-то от тебя не ожидал, обычно ты стараешься не подставляться.

НС>Вот только подставился то ты
НС>Какое убожество. Почувствуйте разницу:

Если вы оба про эмуляцию repl, то разницы особо нет.
Скажем, в дебаге не получится добавишь штукенцию вида
    const x = App.hooks.reqister(class extends App.Hook { onRequestArrived(req,res) {  ... }})
    ...
    x.unsubscribe();
Re[37]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 30.08.21 13:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Еще раз, медленно — интероп в C# медленный.

V>>Требуется сокращать его до минимума.
S>Эмм, а чего там медленного?

Много предварительных телодвижений перед вызовом.
В дотнете вызов не несет с собой никакого контекста текущей VM, в отличии от интеропа в Node.js, где контекст подаётся прямым образом в аргументах.

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

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


S>Мне чисто так — в абстрактном смысле интересно. Я всегда полагал, что интероп в дотнете один из самых лучших на рынке. Особенно с версии 5.


В новых версиях языка добавилось много unsafe-фич, но unsafe и interop друг другу немного перпендикулярны.

Или имелось ввиду появление указателей на ф-ии?
Первым делом измерил, там в точности то же быстродействие получилось, что и через [DllImport("Lib")].

Т.е., вызов ф-ии по managed указателю мгновенный, а по unamanged — медленный, разница примерно в 17 раз.
            managedPtr(bar, ref tmp);
00007FFB821B7D5A  mov         rcx,qword ptr [rbp+10h]  
00007FFB821B7D5E  mov         qword ptr [rbp-10h],rcx  
00007FFB821B7D62  mov         rcx,2215AF02C80h  
00007FFB821B7D6C  mov         rcx,qword ptr [rcx]  
00007FFB821B7D6F  lea         rdx,[rbp-8]  
00007FFB821B7D73  mov         rax,qword ptr [rbp-10h]  
00007FFB821B7D77  call        rax  
            unmanagedPtr(bar, ref tmp);
00007FFB821B7D79  mov         rcx,qword ptr [rbp+18h]  
00007FFB821B7D7D  mov         qword ptr [rbp-18h],rcx  
00007FFB821B7D81  mov         rcx,2215AF02C80h  
00007FFB821B7D8B  mov         rcx,qword ptr [rcx]  
00007FFB821B7D8E  lea         rdx,[rbp-8]  
00007FFB821B7D92  mov         r10,qword ptr [rbp-18h]  
00007FFB821B7D96  mov         r11,22163442FA0h  
00007FFB821B7DA0  call        GenericPInvokeCalliHelper (07FFBE1D0A8D0h)


Тут можно пробежаться глазами, что происходит при вызове нейтивной ф-ии через указатель:
https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/coreclr/vm/amd64/PInvokeStubs.asm#L29

Здесь немного результатов бенчмарков из списка:
http://www.rsdn.org/forum/flame.comp/8063452.1

Ключевое — BaseLine надо вычитать из других результатов, а не смотреть отношение к нему.
Подкорректированная сводка стоимости вызовов в попугаях при использовании:
Managed func ptr — 35;
делегат — 128;
интерфейс — 172;
DllImport/GetProcAddr — 586;
Обратный вызов через GetFunctionPointerForDelegate — 1180;
Указатель на управляемую ф-ию, преобразованный к неуправляемому и вызванный затем как вызов неуправляемой ф-ии — 7000-8000.

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

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

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

В дотнете для борьбы с таким сценарием обычно создают статический прокси-метод.
(К сожалению, сей простой паттерн не задействовали для машинки async-метода, на каждый вызов создаётся унутре делегат — тяжелое наследение .Net Framework, проклятая индустрией индюшатина... )) )

  Сырцы бенчмарка, каждый файл образует свой проект
using System;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

namespace ClassLibrary1 {

public interface IBar {
    void Foo(ref ulong value);
}

public class Bar : IBar {

    [MethodImpl(MethodImplOptions.NoInlining)]
    public void Foo(ref ulong value) {
        value++;
    }
}

public static class Helper {
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static IBar GetIBar() => new Bar();

    public static MethodInfo GetFooMethod(IBar bar) => bar.GetType().GetMethod("Foo")!;

    public static IntPtr GetFooAddress(IBar bar) => GetFooMethod(bar).MethodHandle.GetFunctionPointer();
}

public abstract class MethodWrapper {
    public abstract void Foo(ref ulong value);
}

public sealed class Baseline : MethodWrapper {
    [MethodImpl(MethodImplOptions.NoInlining)]
    public override void Foo(ref ulong value) {
        value++;
    }
}

public sealed class WrapperOverInterface : MethodWrapper {
    private readonly IBar _bar;

    public WrapperOverInterface(IBar bar) => _bar = bar;

    [MethodImpl(MethodImplOptions.NoInlining)]
    public override void Foo(ref ulong value) {
        _bar.Foo(ref value);
    }
}

public sealed class WrapperOverDelegate : MethodWrapper {

    private readonly FooDelegate _fn;

    public WrapperOverDelegate(IBar bar) => _fn = ((Bar)bar).Foo;

    [MethodImpl(MethodImplOptions.NoInlining)]
    public override void Foo(ref ulong value) {
        _fn(ref value);
    }

    private delegate void FooDelegate(ref ulong value);
}

public sealed unsafe class WrapperOverPtrFromDelegate : MethodWrapper {

    private readonly FooDelegate _delegate; // prevent GC cleaning
    private readonly delegate* unmanaged[Cdecl]<ref ulong, void> _fn;

    public WrapperOverPtrFromDelegate(IBar bar) {
        _delegate = ((Bar)bar).Foo;
        _fn = (delegate* unmanaged[Cdecl]<ref ulong, void>)Marshal.GetFunctionPointerForDelegate(_delegate);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    public override void Foo(ref ulong value) {
        _fn(ref value);
    }

    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    private delegate void FooDelegate(ref ulong value);
}

public sealed class WrapperOverDelegateFromMethodInfo : MethodWrapper {

    private readonly FooDelegate _fn;

    public WrapperOverDelegateFromMethodInfo(IBar bar)
        => _fn = (FooDelegate)Delegate.CreateDelegate(typeof(FooDelegate), bar, Helper.GetFooMethod(bar));

    [MethodImpl(MethodImplOptions.NoInlining)]
    public override void Foo(ref ulong value) {
        _fn(ref value);
    }

    private delegate void FooDelegate(ref ulong value);
}

public sealed class WrapperOverDelegateFromPtr : MethodWrapper {
    private readonly IBar _bar;
    private readonly FooDelegateFromPtr _fn;

    public WrapperOverDelegateFromPtr(IBar bar) {
        _bar = bar;
        _fn = Marshal.GetDelegateForFunctionPointer<FooDelegateFromPtr>(Helper.GetFooAddress(bar));
    }

    public override void Foo(ref ulong value) {
        _fn(_bar, ref value);
    }

    private delegate void FooDelegateFromPtr(IBar @this, ref ulong value);
}

public sealed unsafe class WrapperOverManagedFunPtr : MethodWrapper {
    private readonly IBar _bar;
    private readonly delegate* managed<IBar, ref ulong, void> _fn;

    public WrapperOverManagedFunPtr(IBar bar) {
        _bar = bar;
        _fn = (delegate* managed<IBar, ref ulong, void>)Helper.GetFooAddress(bar);
    }

    public override void Foo(ref ulong value) {
        _fn(_bar, ref value);
    }
}

public sealed unsafe class WrapperOverUnmanagedFunPtr : MethodWrapper {
    private readonly IBar _bar;
    private readonly delegate* unmanaged<IBar, ref ulong, void> _fn;

    public WrapperOverUnmanagedFunPtr(IBar bar) {
        _bar = bar;
        _fn = (delegate* unmanaged<IBar, ref ulong, void>)Helper.GetFooAddress(bar);
    }

    public override void Foo(ref ulong value) {
        _fn(_bar, ref value);
    }
}

public sealed class WrapperOverDllImport : MethodWrapper {
    [DllImport("SomeDll.dll")]
    private static extern void FooNative(ref ulong value);

    public override void Foo(ref ulong value) {
        FooNative(ref value);
    }
}

public sealed unsafe class WrapperOverDllGetProcAddr : MethodWrapper {
    private readonly delegate* unmanaged[Cdecl]<ref ulong, void> _fn;

    public WrapperOverDllGetProcAddr() {
        var hModule = NativeLibrary.Load("SomeDll.dll");
        _fn = (delegate* unmanaged[Cdecl]<ref ulong, void>)NativeLibrary.GetExport(hModule, "FooNative");
    }
        
    public override void Foo(ref ulong value) {
        _fn(ref value);
    }
}

}


#define WIN32_LEAN_AND_MEAN
#include <windows.h>

BOOL APIENTRY DllMain(HMODULE hModule,
                      DWORD ul_reason_for_call,
                      LPVOID lpReserved
) {
    switch(ul_reason_for_call) {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

extern "C"
__declspec(dllexport) void __stdcall FooNative(UINT64 & value) {
    value++;
}


using System.Collections.Generic;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using ClassLibrary1;

#nullable enable

namespace ConsoleApp27 {

[DisassemblyDiagnoser]
public class MethodCallTest {

    public static IEnumerable<CallMethod> Arguments() {
        IBar bar = Helper.GetIBar();

        return new CallMethod[] {
            new("Baseline", new Baseline()),
            new("Interface", new WrapperOverInterface(bar)),
            new("Delegate", new WrapperOverDelegate(bar)),
            new("Delegate from MI", new WrapperOverDelegateFromMethodInfo(bar)),
            new("Delegate from ptr", new WrapperOverDelegateFromPtr(bar)),
            new("Ptr from delegate", new WrapperOverPtrFromDelegate(bar)),
            new("Managed func ptr", new WrapperOverManagedFunPtr(bar)),
            new("Unmanaged func ptr", new WrapperOverUnmanagedFunPtr(bar)),
            new("DllImport", new WrapperOverDllImport()),
            new("DllGetProcAddr", new WrapperOverDllGetProcAddr())
        };
    }

    [ArgumentsSource(nameof(Arguments))]
    [Benchmark]
    [MethodImpl(MethodImplOptions.NoOptimization | MethodImplOptions.NoInlining)]
    public ulong CallTest(CallMethod m) {
        var fn = m.Func;
        ulong sum = 0;

        for(var i = 0; i < 100000; i++)
            fn.Foo(ref sum);

        return sum;
    }

    public record CallMethod(string Name, MethodWrapper Func) {
        public override string ToString() => Name;
    }
}

internal static class Program {
    private static void Main() {
        BenchmarkRunner.Run<MethodCallTest>();
    }
}

}


S>И как вы ухитряетесь его сократить при помощи СompilerServices.Unsafe?


Часть нейтивной функциональности переношу в дотнет, избавляясь от интеропа.
СompilerServices.Unsafe позволяет получать управляемые ссылки из, грубо, void*, чего до него не было.
Или же приводить одну управляемую ссылку в другую, например, ссылку на byte на ссылку на SomeStruct.
Кароч, позволяет реинтерпретировать память по моему усмотрению.


V>>Я именно тебе приводил не так давно тесты вызова interop или ф-ий через unsafe-указатели — результаты катастрофические.

V>>В обоих случаях.
S>Что-то сходу не могу найти тех тестов.

Так я и не тебе приводил.
Ссылку дал выше.


S>И, главное, как нода-то ухитряется сделать интероп быстрее?


Ноде не надо заботиться о фреймах стека для GC, поэтому, вызывает нейтивные ф-ии напрямую.

"Ополовинить интероп" в C# имелось ввиду отрезать/снизить почти вдвое надобность в интеропе.
Отредактировано 31.08.2021 19:13 vdimas . Предыдущая версия . Еще …
Отредактировано 30.08.2021 13:31 vdimas . Предыдущая версия .
Отредактировано 30.08.2021 13:29 vdimas . Предыдущая версия .
Re[38]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.08.21 13:20
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Никак.

V>"Ополовинить" имелось ввиду отрезать снизить почти вдвое надобность в интеропе.

А разве .NET Core не убирает вагоны лишних нативных вызовов?
Re[37]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 30.08.21 13:28
Оценка:
Здравствуйте, Serginio1, Вы писали:

V>>Еще раз, медленно — интероп в C# медленный.

V>>Требуется сокращать его до минимума.
S> Ну вот новые ссылки на функции вполне себе быстрые. https://dev.to/jeikabu/native-code-in-net-5-0-and-c-9-0-39h7

Медленные, согласно твоей ссылки — в 6 раз медленее.
Но это потому что руки у ребят по ссылке кривые, они не в состоянии вычесть общие для всех расходы из тестов.
Там разница примерно в 17 раз.
http://www.rsdn.org/forum/flame.comp/8081536.1


V>>А что именно ты проверил?

V>>Создай прямо сейчас в VS2019 приложение из шаблона Xamarin class library.
S> Я создавал Xamarin.Forms там есть поддержка 2.1. Библиотеки независимы от ксамарин или чего еще. Это же .Net Standard!

Просто открой студию 2019 прямо сейчас, просто создай проект "Xamarin class library", просто посмотри зависимости.
Библиотеки зависимы еще как.

Еще ни разу у меня не получалось гладко привести некий код из .Net Core стандарта в .Net Standart.
Твои представления о совместимости стандартов не отвечают объективной реальности.

Ну и, MS прямо сказала, что лавочку .Net Standart-ов будут прикрывать, бо это бардак.
Уже попросила ориентироваться только на .Net 5.0, а с выходом LTS .Net 6.1 (скорее всего именно такая версия будет LTS) — и вовсе .Net Standart уйдёт в неподдерживаемое состояние.
И тогда степень совместимости с .Net Core разработчики Хamarin будут обеспечивать только по своей доброй воле, как грится.


V>>Пока что на сегодня только в нейтиве на все случаи жизни и есть.

V>>Любой не-нейтив в большинстве своём биндится к нейтивным библиотекам.
V>>А которая оригинальная в не-нейтивных платформах библиотечная функциональность — так её кот наплакал.
V>>Обычно оригинальное обитает в нише поддержки разработки, по понятной причине.
S> Угу. На Java и C# пишут наверное поболее библиоетек и главное используют их!

Это ты сейчас серьёзно?


V>>Xamarin имеет прямой бинд к Android SDK, ему не джавовские либы нужны, а разве что доступ к датчикам, микрофону, камере и т.д.

V>>И какие же это в опу "либы", если в самой Андроидной Джаве это лишь тонкие обёртки над нейтивом?
V>>Это "просто АПИ".
S> Сканеру, и прочему оборудованию. Куча готовых классов на Java на всякие случаи жизни. По твоему .Net это тонкая обертка на нативом?

В любой более-менее заметной востребованной современной функциональности — разумеется.
Шифрование, подпись, медиа (изображения, видео, графика, звук), сетка, протоколы, датчики, ИИ и т.д. до бесконечности — всё по большей части нейтив.
В скриптовых и управляемых языках в основном "удобные классы" над всем этим.


S>Да вначале они так и делали, затем отказались. То же самое и с Java.


Никто не думал отказываться.
Наоборот, в Андроиде к 7-8-м версиям появилось больше нейтива в том же GUI, он стал заметно более отзывчивый, им с тех пор можно пользоваться.


S> Ты давай .Net Standard 2.1 Я что зря время тратил?


По-моему, ты ничего не тратил, помимо времени на общение здесь. ))
Отредактировано 30.08.2021 13:43 vdimas . Предыдущая версия .
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: vdimas Россия  
Дата: 30.08.21 13:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Никак.

V>>"Ополовинить" имелось ввиду отрезать снизить почти вдвое надобность в интеропе.
I>А разве .NET Core не убирает вагоны лишних нативных вызовов?

Не понял вопроса.
.Net Core тащит за собой нейтивные либы-обертки, которые компиляются уникально для каждой платформы, предоставляя вызывающему .Net коду унифицированный АПИ платформы.

Осуждаемая Usafe-либа с одноимённым названием это, по-сути, reinterpret-cast для управляемого кода.
Либа эта писана непосредственно на IL, т.к. C# не предоставляет таких ср-в.
Отредактировано 30.08.2021 13:40 vdimas . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.