Re[15]: Новости C#13. params - .NET

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

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

_FR>>>>>System.Collections.IEnumerable, например, тоже поддержали, что могли бы сделать и с самого начала.
S>>>>На самом деле это еще тот геморрой при рефлексии обрабатывать все варианты. Да еще разные варианты с количество перегрузок методов.
_FR>>>Какие варианты и рефлексию вы имеете в виду? Можете пример показать? Как это связано с первой, второй или 13-той версией языка?

S>> Вот у тебя есть имя метода и параметры. По этим данным надо найти реальный метод.
S>>.Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед

_FR>Спасибо за очень понятное объяснение. Конечно, это всё объясняет.
Да в целом-то всё понятно. Вот у нас есть некий object, а ещё — string methodName, плюс object[] arguments.
И хочется воспроизвести все нюансы перегрузки, реализованные в C#.
Внезапно выясняется, что когда мы видим в коде foo.bar(baz1, baz2), то там происходит много всяких подкапотных интересностей.
Начиная от того, что результат зависит не от фактических типов baz1 и baz2, а от формальных. А вот для foo важен как формальный тип, так и фактический.
Даже если выбросить из рассмотрения extension методы, ограничившись только экземплярными, то всё равно там чёрт ногу сломит. Далеко не всякий сходу скажет, что выведет такой код:

using System;
                    
public class Program
{
    public class Foo
    {
       public string bar(object a, string b) => "1";
       public string bar(int a, object b) => "2";
       public string bar(object a, object b) => "3";
       public string bar<A>(A a, string b) => "4";
       public string bar<B>(int a, B b) => "5";
       public string bar(params object[] xs) => "6";
       public string bar(int a, params string[] b) => "7";
    }

    public static void Main()
    {
        var foo = new Foo();
        Console.WriteLine(foo.bar(42, "42"));
    }
}

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

S>>> Вот у тебя есть имя метода и параметры. По этим данным надо найти реальный метод.
S>>>.Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
_FR>>Спасибо за очень понятное объяснение. Конечно, это всё объясняет.
S>Да в целом-то всё понятно. Вот у нас есть некий object, а ещё — string methodName, плюс object[] arguments.
S>И хочется воспроизвести все нюансы перегрузки, реализованные в C#.
S>Внезапно выясняется, что когда мы видим в коде foo.bar(baz1, baz2), то там происходит много всяких подкапотных интересностей.

Да, там много сложностей и действительно задача "в самом общем виде" не самая простая. Но 1) заметно проще, чем у компилятора и 2) думаю, если не хочется самому это всё выписывать, можно воспользоваться тем, что компилятор создаёт для вызова метода с dynamic-параметрами, типа такого:

S>using System;
                    
S>public class Program
S>{
S>    public class Foo
S>    {
S>       public string bar(object a, string b) => "1";
S>       public string bar(int a, object b) => "2";
S>       public string bar(object a, object b) => "3";
S>       public string bar<A>(A a, string b) => "4";
S>       public string bar<B>(int a, B b) => "5";
S>       public string bar(params object[] xs) => "6";
S>       public string bar(int a, params string[] b) => "7";
S>    }

      public class Foo2
      {
         public static string bar(Foo foo, dynamic a, dynamic b) => foo.bar(a, b);
      }

S>    public static void Main()
S>    {
S>        var foo = new Foo();
S>        Console.WriteLine(Foo2.bar(foo, 42, "42")); // Вызываем "наш" метод заместо искомого
S>    }
S>}

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

_
_FR> public class Foo2
_FR> {
_FR> public static string bar(Foo foo, dynamic a, dynamic b) => foo.bar(a, b);
_FR> }

Но пишем то мы универсальный код. Конечно можно динамически скомпилировать.
В той же статье для эвентов генерируется и компилируется код.
Но геморроя добавляется.

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

_FR>>      public class Foo2
_FR>>      {
_FR>>         public static string bar(Foo foo, dynamic a, dynamic b) => foo.bar(a, b);
_FR>>      }

S> Но пишем то мы универсальный код. Конечно можно динамически скомпилировать.
S>В той же статье для эвентов генерируется и компилируется код.
S> Но геморроя добавляется.

Так посмотрите во что компилятор это превращает:

    public class Foo2
    {
        [CompilerGenerated]
        private static class <>o__0
        {
            public static CallSite<Func<CallSite, Foo, object, object, object>> <>p__0;

            public static CallSite<Func<CallSite, object, string>> <>p__1;
        }

        [NullableContext(1)]
        public static string bar(Foo foo, [Dynamic] object a, [Dynamic] object b)
        {
            if (<>o__0.<>p__1 == null)
            {
                <>o__0.<>p__1 = CallSite<Func<CallSite, object, string>>.Create(Microsoft.CSharp.RuntimeBinder.Binder.Convert(CSharpBinderFlags.None, typeof(string), typeof(Foo2)));
            }
            Func<CallSite, object, string> target = <>o__0.<>p__1.Target;
            CallSite<Func<CallSite, object, string>> <>p__ = <>o__0.<>p__1;
            if (<>o__0.<>p__0 == null)
            {
                Type typeFromHandle = typeof(Foo2);
                CSharpArgumentInfo[] array = new CSharpArgumentInfo[3];
                array[0] = CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.UseCompileTimeType, null);
                array[1] = CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null);
                array[2] = CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null);
                <>o__0.<>p__0 = CallSite<Func<CallSite, Foo, object, object, object>>.Create(Microsoft.CSharp.RuntimeBinder.Binder.InvokeMember(CSharpBinderFlags.None, "bar", null, typeFromHandle, array));
            }
            return target(<>p__, <>o__0.<>p__0.Target(<>o__0.<>p__0, foo, a, b));
        }
    }

и делайте так же.

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

S>Далеко не всякий сходу скажет, что выведет такой код:

S> public string bar(object a, string b) => "1";
S> public string bar(int a, object b) => "2";
S> public string bar(object a, object b) => "3";
S> public string bar<A>(A a, string b) => "4";
S> public string bar<B>(int a, B b) => "5";
S> public string bar(params object[] xs) => "6";
S> public string bar(int a, params string[] b) => "7";

"Ваш код — $#$$%!" (ц) Ванко

Если человек(!!) не может сказать, что выведет компилятор (я угадал — 7), то и КОМПИЛЯТОР НЕ ДОЛЖЕН!
Машина не должна делать то, что человек не в состоянии осмыслить (например, тупые "нейронные сети").
Если ты наоверлоадил и некоторые методы схожи вплоть до неявной конверсии типов, это ПЛОХОЙ оверлоадинг и надо решать задачу по-другому или убирать неоднозначный оверлоадинг.

Это классика тупого поведения микрософта: думать за юзера больше, чем хочет сам юзер. Это программирование, точная наука! Здесь "я программист, я знаю как юзеру лучше!" не работает.
Лучше прогер напишет лишний символ/приведение типов/etc, чем компилятор распухнет от "хардкоженных догадок" и потом люди будут долго медитировать над тем, почему очевидный код ведёт себя криво.
Простота — залог надёжности.

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

R>В превью версию C#13 добавили для так называемой `params` collections поддержку IEnumerable<T> и ReadOnlySpan<T>. Значит скоро можно будет писать вот так
R>

R>void M(params IEnumerable<int> numbers);
R>void M(params ReadOnlySpan<int> numbers);
R>

R>https://x.com/jcouv/status/1767967748259545522

Ну добавили финтифлюшку и что от этого изменилось? Теперь быстрее программы писать будете?

Я к 40 годам начал смотреть на суть. Когда будет возможно сделать библиотеку на C#, которую можно будет использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?

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

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

R>>В превью версию C#13 добавили для так называемой `params` collections поддержку IEnumerable<T> и ReadOnlySpan<T>. Значит скоро можно будет писать вот так
R>>

R>>void M(params IEnumerable<int> numbers);
R>>void M(params ReadOnlySpan<int> numbers);
R>>

R>>https://x.com/jcouv/status/1767967748259545522

S>Ну добавили финтифлюшку и что от этого изменилось? Теперь быстрее программы писать будете?

S>Я к 40 годам начал смотреть на суть. Когда будет возможно сделать библиотеку на C#, которую можно будет использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?

.Native AOT. Только зачем? В том же .Net в большинстве случаев отказываются от P/Invoke
Так или иначе в .Native AOT Il сначала транслируется в С++, затем с помощью С++ компиляторов генерится машинный код со сборщиком мусора.

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

S> .Native AOT.

iOS и Android: Официально не поддерживаются для Native AOT на данный момент. Для мобильных платформ используются другие технологии, такие как Xamarin/MAUI.

WebAssembly: Не поддерживается напрямую Native AOT. Для работы с WebAssembly используется Blazor и связанный с ним стек.

Т.е. не возможно для всех ОС — и ты хоть обвешай себя разными финтифлюшками — когда нет фундамента дома — бесполезно делать рюшечки на ставнях.

S> Только зачем?

Чтобы переиспользовать код — вынести код в библиотеку и использовать один и тот же код на всех платформах, коих у человечества ровно шесть штук:

1. Windows.
2. Linux.
3. MacOS.
4. Android.
5. iOS.
6. WASM.

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

S>> .Native AOT.

S>

S>iOS и Android: Официально не поддерживаются для Native AOT на данный момент. Для мобильных платформ используются другие технологии, такие как Xamarin/MAUI.

S>WebAssembly: Не поддерживается напрямую Native AOT. Для работы с WebAssembly используется Blazor и связанный с ним стек.

S>Т.е. не возможно для всех ОС — и ты хоть обвешай себя разными финтифлюшками — когда нет фундамента дома — бесполезно делать рюшечки на ставнях.

S>> Только зачем?

S>Чтобы переиспользовать код — вынести код в библиотеку и использовать один и тот же код на всех платформах, коих у человечества ровно шесть штук:

S>1. Windows.
S>2. Linux.
S>3. MacOS.
S>4. Android.
S>5. iOS.
S>6. WASM.

Ииии? Нужно компилировать под каждую платформу отдельно.
Еще кстати есть Tizen OS https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8

Platform Supported architecture Notes
Windows x64, Arm64
Linux x64, Arm64
macOS x64, Arm64
iOS Arm64 Experimental support
iOSSimulator x64, Arm64 Experimental support
tvOS Arm64 Experimental support
tvOSSimulator x64, Arm64 Experimental support
MacCatalyst x64, Arm64 Experimental support
Android x64, Arm64 Experimental, no built-in Java interop

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

S> Ииии? Нужно компилировать под каждую платформу отдельно.

Вы можете сделать приложение на .Net, чтобы именно из .Net использовать повторно C#-код.

Однако из того же Python или JS — уже не сможете библиотеку использовать, хотя это самый популярный ЯП.

Т.е. это вещь в себе — песочница для детей и экспериментов, отдаленная от реальной жизни.

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

S>> Ииии? Нужно компилировать под каждую платформу отдельно.

S>Вы можете сделать приложение на .Net, чтобы именно из .Net использовать повторно C#-код.
В большинстве случаев да.
S>Однако из того же Python или JS — уже не сможете библиотеку использовать, хотя это самый популярный ЯП.
Почему? Например .Net через тот же COM прекрасно используется. В том же 1С

Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux

Использование классов .Net в 1С для новичков
S>Т.е. это вещь в себе — песочница для детей и экспериментов, отдаленная от реальной жизни.

Ну это для тебя. Многие используют. Например тот же WebAssembly в Blazor

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

S>>Однако из того же Python или JS — уже не сможете библиотеку использовать, хотя это самый популярный ЯП.
S> Почему? Например .Net через тот же COM прекрасно используется. В том же 1С

Потому что НЕТ и такова реальность.

Покажите мне хотя бы одну .Net библиотеку, которую авторы предлагают для использования на других языках на всех 6 платформах. ОДНУ!!!

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

Готов поспорить что вы такой библиотеки не найдете.

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

S>>>Однако из того же Python или JS — уже не сможете библиотеку использовать, хотя это самый популярный ЯП.
S>> Почему? Например .Net через тот же COM прекрасно используется. В том же 1С

S>Потому что НЕТ и такова реальность.

S>Покажите мне хотя бы одну .Net библиотеку, которую авторы предлагают для использования на других языках на всех 6 платформах. ОДНУ!!!

S>Это просто вы можете верить что так можно, блажен кто верует. Но когда столкнетесь с реальностью — поймёте что это не возможно в принципе, даже за миллионы долларов нет.

S>Готов поспорить что вы такой библиотеки не найдете.

Вопрос, а зачем? На самом деле .Net хорош во многом, но прежде всего в рефлексии и динамической компиляции.
.Native AOT прежде всего для обфускации и оптимизации критических по скорости приложений.
Но если ооочень хочется то можно https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

Суть в том, что сейчас не все классы поддерживают AOT. Много динамической компиляции или рефлексии без ограничений на типы.
Но сейчас такие вещи обходятся интерпретацией Il кода.
Ну и .Native AOT всего то года 2-3!

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

S> Вопрос, а зачем?

Чтобы твою библиотеку могли использовать разные разработчики из разных ЯП на 6 платформах. Иначе придется под каждую платформу под каждый язык писать что-то в нуля, а это увеличивает работу сотни и тысячи раз — кроме разработки еще и поддержку.

S>На самом деле .Net хорош во многом, но прежде всего в рефлексии и динамической компиляции.

Это все рюшечки — основа это переиспользование кода и возможность игнтеграции.

S>.Native AOT прежде всего для обфускации и оптимизации критических по скорости приложений.
S>Но если ооочень хочется то можно https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

Уже обсуждали — это не работает в моб. осях и WASM. Вообще.

Еще раз вам вопрос. Вот пример либы — https://github.com/jedisct1/libsodium

Она работает:

1. На Windows.
2. На Linux.
3. MacOS.
4. iOS.
5. Android.
6. WASM.

Есть примеры вызова из Python, .Net, Java.

И таких библиотек много. Представляете что было бы, если бы для каждой ОС и для каждой платформы пришлось писать код с нуля???

И во взрослом мире программирования все библиотеки такие. Работают на всех платформах и использовать можно из всех ЯП.

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

S> Ну и .Native AOT всего то года 2-3!

Ну вот когда достигнет зрелости — тогда и можно будет рассматривать.

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

S>>.Native AOT прежде всего для обфускации и оптимизации критических по скорости приложений.
S>>Но если ооочень хочется то можно https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

S>Уже обсуждали — это не работает в моб. осях и WASM. Вообще.

Угу а как же Blazor WASM то работает?

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

S>>>.Native AOT прежде всего для обфускации и оптимизации критических по скорости приложений.
S>>>Но если ооочень хочется то можно https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

S>>Уже обсуждали — это не работает в моб. осях и WASM. Вообще.

S> Угу а как же Blazor WASM то работает?

Blazor WASM разве использует native aot?

См. мой вопрос выше — попытайтесь ответить и все поймете — хотя бы один аналог такой библиотеки https://rsdn.org/forum/dotnet/8829536.1

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

S>>>>.Native AOT прежде всего для обфускации и оптимизации критических по скорости приложений.
S>>>>Но если ооочень хочется то можно https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

S>>>Уже обсуждали — это не работает в моб. осях и WASM. Вообще.

S>> Угу а как же Blazor WASM то работает?

S>Blazor WASM разве использует native aot?
ASP.NET Core Blazor WebAssembly build tools and ahead-of-time (AOT) compilation

Тоже предполагаю, что переводится в C++, а затем компилятором C++ уже в WASM. То есть все то же самое что и в библиотеки или приложение

То есть все, что может С++ то же умеет и .Native AOT

Компиляция кода C/C++ в WebAssembly

C# in Browser via WebAssembly (without Blazor)

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

S>>Blazor WASM разве использует native aot?
S>ASP.NET Core Blazor WebAssembly build tools and ahead-of-time (AOT) compilation

S>Тоже предполагаю, что переводится в C++, а затем компилятором C++ уже в WASM. То есть все то же самое что и в библиотеки или приложение

А как можно перевести в C++ ? Разве такая возможность есть?

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

S>>>Blazor WASM разве использует native aot?
S>>ASP.NET Core Blazor WebAssembly build tools and ahead-of-time (AOT) compilation

S>>Тоже предполагаю, что переводится в C++, а затем компилятором C++ уже в WASM. То есть все то же самое что и в библиотеки или приложение

S>А как можно перевести в C++ ? Разве такая возможность есть?
Вот нахрена я тебе ссылки даю?
https://learn.microsoft.com/ru-ru/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8#prerequisites
Для ubuntu например нужен clang.

Кстати я как понял после покупки MONO они взяли и IL2CPP Overview
Введение в IL2CPP

.NET Native это предшественник Native AOT
.Net Native использует ту же серверную часть, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.

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

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

S>>А как можно перевести в C++ ? Разве такая возможность есть?
S> Вот нахрена я тебе ссылки даю?
S>https://learn.microsoft.com/ru-ru/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8#prerequisites
S>Для ubuntu например нужен clang.

Напрямую C++ код можно получить?

Далее — есть ли пример хотя бы одной .Net библиотеки, которую можно использовать из любого языка на всех 6 платформах? Хотя бы одна?

Скорее всего сделать такое не возможно в принципе — это фундамент, а в фундаменте как всегда заложена мина. Т.е. это чисто вещь в себе — будете использовать из приложений .Net, и с ограничениями, все будет медленно, приложения будут большими + не всегда стабильно работать.

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

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

S>>>А как можно перевести в C++ ? Разве такая возможность есть?
S>> Вот нахрена я тебе ссылки даю?
S>>https://learn.microsoft.com/ru-ru/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8#prerequisites
S>>Для ubuntu например нужен clang.

S>Напрямую C++ код можно получить?

S>Далее — есть ли пример хотя бы одной .Net библиотеки, которую можно использовать из любого языка на всех 6 платформах? Хотя бы одна?

S>Скорее всего сделать такое не возможно в принципе — это фундамент, а в фундаменте как всегда заложена мина. Т.е. это чисто вещь в себе — будете использовать из приложений .Net, и с ограничениями, все будет медленно, приложения будут большими + не всегда стабильно работать.
Почему нельзя объясни? Это всё твои предположения. Еще раз все компилится в С++ а из него в нужный машинный код!

https://joeysenna.com/posts/nativeaot-in-c-plus-plus
https://stackoverflow.com/questions/74944873/call-nativeaot-c-sharp-dll-from-delphi
https://learn.microsoft.com/ru-ru/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute?view=net-8.0

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

S> Почему нельзя объясни? Это всё твои предположения. Еще раз все компилится в С++ а из него в нужный машинный код!

S>https://joeysenna.com/posts/nativeaot-in-c-plus-plus
S>https://stackoverflow.com/questions/74944873/call-nativeaot-c-sharp-dll-from-delphi
S>https://learn.microsoft.com/ru-ru/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute?view=net-8.0

Вместо теоретических размышлений и вопросов — дай хотя бы ОДНУ практически реализованную библиотеку, которая такой фукнционал предоставляет — т.е. чтобы был запуск на 6 платформах и возможность использовать из любого языка.

Уверен что нет таких библиотек. Ни одной.

И при попытке реализовать — будет масса проблем, после которых неудобства синтаксиса С++ или Rust вам покажутся цветочками.

Жду от вас практическую бибилиотеку. Ну или вы попробуйте сделать. Уверен что нет таких библиотек и когда РЕАЛЬНО попробуете сделать (а не языком) — столкнетесь с непреодолимыми сложностями. Может сделать и даже статью на Хабре запилить если что-то получится из этого (и даже если не получится).

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

S>> Почему нельзя объясни? Это всё твои предположения. Еще раз все компилится в С++ а из него в нужный машинный код!

S>>https://joeysenna.com/posts/nativeaot-in-c-plus-plus
S>>https://stackoverflow.com/questions/74944873/call-nativeaot-c-sharp-dll-from-delphi
S>>https://learn.microsoft.com/ru-ru/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute?view=net-8.0

S>Вместо теоретических размышлений и вопросов — дай хотя бы ОДНУ практически реализованную библиотеку, которая такой фукнционал предоставляет — т.е. чтобы был запуск на 6 платформах и возможность использовать из любого языка.

S>Уверен что нет таких библиотек. Ни одной.

S>И при попытке реализовать — будет масса проблем, после которых неудобства синтаксиса С++ или Rust вам покажутся цветочками.

Еще раз есть проблемы с компиляцией в рантайме, которая обходится через интерпретатор и рефлексия без ограничений.

S>Жду от вас практическую бибилиотеку. Ну или вы попробуйте сделать. Уверен что нет таких библиотек и когда РЕАЛЬНО попробуете сделать (а не языком) — столкнетесь с непреодолимыми сложностями. Может сделать и даже статью на Хабре запилить если что-то получится из этого (и даже если не получится).
Мне они не нужны. И времени на данный момент тоже, что бы статьи писал. Возможность есть. Многие используют, так как в много библиотек. Но не все они на данный компилируются.
Но вот блазор в вэбассембли содержит еще и IL код который интерпретируется.
Но ты же утверждаешь, что нет возможности. Я тебе привел что IL код переводится в C++ а из него уже в код на нужной платформе со сборщиком мусора.

Обычно пишут такого рода библиотеки как плагины для доступа к существующему софту на .Net.
Просто раньше можно было подключаться через Написание пользовательского хост-приложения .NET для управления средой выполнения .NET из машинного кода

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

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

S> Мне они не нужны. И времени на данный момент тоже, что бы статьи писал. Возможность есть. Многие используют, так как в много библиотек. Но не все они на данный компилируются.
S>Но вот блазор в вэбассембли содержит еще и IL код который интерпретируется.
S> Но ты же утверждаешь, что нет возможности. Я тебе привел что IL код переводится в C++ а из него уже в код на нужной платформе со сборщиком мусора.

Меня интересуют не философские измышления и как в теории это возможно (может быть) — а практика.

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

Т.е. реально думаете что на C# можно написать код, который компилить скриптами для всех 6 платформ и потом использовать из любого ЯП, как на нормальных ЯП? Реально думаете что возможно это, но никто еще не сделал такой библиотеки в мире?

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

S> Скорее всего сделать такое не возможно в принципе — это фундамент, а в фундаменте как всегда заложена мина. Т.е. это чисто вещь в себе — будете использовать из приложений .Net, и с ограничениями, все будет медленно, приложения будут большими + не всегда стабильно работать.

Во, смари: https://www.remobjects.com/elements/ Шесть языков, шарп в том числе, с возможностью фигачить под семь программных платформ (прикинь, на шарпе можешь фигачить под жэвээм и ведроид). Пользуйся. Средства для кросс наличествуют.

avalon/3.0.2

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

R>Во, смари: https://www.remobjects.com/elements/ Шесть языков, шарп в том числе, с возможностью фигачить под семь программных платформ (прикинь, на шарпе можешь фигачить под жэвээм и ведроид). Пользуйся. Средства для кросс наличествуют.

Но это платное — чтобы не учить C++ и писать ущербные библиотеки на любимом шарпике — вам придется платить налог $999 за вход и 749/year за обновление. При этом платформа не известная, не популярная и вы не сможете найти команду под эту платформу.

Так же не думаю что там все гладко — скорее всего банальные либы будут получаться дутые — типа мин. функционал — 5 МБ, а добавил чуть либ — уже 50 МБ, притом что такая же читая на C++ будет 500 Кб.

Смотрите на суть — смотрите не на финтифлюшки а на фундамент.

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

S> Но это платное — чтобы не учить C++ и писать ущербные библиотеки на любимом шарпике — вам придется платить налог $999 за вход и 749/year за обновление.

$999 не за вход, а за все языки. За один язык — $749. Впрочем, есть и за 200 баксов вариант. Зато любая платформа на любимом язычке, а не пердолинг с сисиплюсами и растаманией. Не хочешь платить — пердолься и дальше.

S> При этом платформа не известная, не популярная и вы не сможете найти команду под эту платформу.

Завязывай, теоретик.

avalon/3.0.2

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

S> Так же не думаю что там все гладко — скорее всего банальные либы будут получаться дутые — типа мин. функционал — 5 МБ, а добавил чуть либ — уже 50 МБ, притом что такая же читая на C++ будет 500 Кб.

Завязывай, теоретик.

avalon/3.0.2

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

S>> Мне они не нужны. И времени на данный момент тоже, что бы статьи писал. Возможность есть. Многие используют, так как в много библиотек. Но не все они на данный компилируются.
S>>Но вот блазор в вэбассембли содержит еще и IL код который интерпретируется.
S>> Но ты же утверждаешь, что нет возможности. Я тебе привел что IL код переводится в C++ а из него уже в код на нужной платформе со сборщиком мусора.

S>Меня интересуют не философские измышления и как в теории это возможно (может быть) — а практика.

S>Вы хотите сказать что это возможно, но еще никто в мире не сделал ни одной библиотеки кроссплатформенной, не смотря на то что такая возможность присутствует?

S>Т.е. реально думаете что на C# можно написать код, который компилить скриптами для всех 6 платформ и потом использовать из любого ЯП, как на нормальных ЯП? Реально думаете что возможно это, но никто еще не сделал такой библиотеки в мире?

То есть ты утверждаешь, что на С++ невозможно компилить код для 6 платформ?
IL код прекрасно транслируется в С++. А кто там, что пишет мне неизвестно. Я даже нативными библиотеками не пользуюсь. Вернее если и пользуюсь, то они где то далеко скрыты в PInvoke
и их минимум.

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

R>$999 не за вход, а за все языки. За один язык — $749. Впрочем, есть и за 200 баксов вариант. Зато любая платформа на любимом язычке, а не пердолинг с сисиплюсами и растаманией. Не хочешь платить — пердолься и дальше.

Все-равно — ты платишь за якобы неспособность выучить нормальный язык, который умеет все это из коробки.

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

S>> При этом платформа не известная, не популярная и вы не сможете найти команду под эту платформу.
R>Завязывай, теоретик.

Дело вот в чем. Ты можешь создать либу на C# — но чтобы другие ее могли использовать на всех 6 платформах им нужно заплатить $749. Бывает что у либы 1 млн. пользователей — и каждый из 1 млн. — должен заплатить $749 — а это уже почти миллиард долларов.

Все дело в деньгах — на нормальных платформах все это БЕСПЛАТНО для всех.

Более того — это вендорлок. Что ты будешь делать, если эта конторка загнется или решит перестать поддерживать твой язык?

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

S>> Так же не думаю что там все гладко — скорее всего банальные либы будут получаться дутые — типа мин. функционал — 5 МБ, а добавил чуть либ — уже 50 МБ, притом что такая же читая на C++ будет 500 Кб.

R>Завязывай, теоретик.

А ты то использовал эту платформу? Я не слышал даже ранее, не смотря на то что хабр читаю постоянно. Но дело в другом, повторюсь:

Дело вот в чем. Ты можешь создать либу на C# — но чтобы другие ее могли использовать на всех 6 платформах им нужно заплатить $749. Бывает что у либы 1 млн. пользователей — и каждый из 1 млн. — должен заплатить $749 — а это уже почти миллиард долларов.

Все дело в деньгах — на нормальных платформах все это БЕСПЛАТНО для всех.

Более того — это вендорлок. Что ты будешь делать, если эта конторка загнется или решит перестать поддерживать твой язык?

А теперь подумай почему конкретно ты так не хочешь учить C++ и готов отмазывать C#, даже платить деньги за это — крыть нечем?

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

S> То есть ты утверждаешь, что на С++ невозможно компилить код для 6 платформ?
S>IL код прекрасно транслируется в С++. А кто там, что пишет мне неизвестно. Я даже нативными библиотеками не пользуюсь. Вернее если и пользуюсь, то они где то далеко скрыты в PInvoke
S>и их минимум.

Как IL транслировать в C++ ? Дай пример — посмотрим что там получается. Что со сборкой мусора?

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

S> Все-равно — ты платишь за якобы неспособность выучить нормальный язык, который умеет все это из коробки.

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

S> А что на выходе то получается? Каков размер мин. библиотеки WASM получается?

Скачай и проверь

S> Дело вот в чем. Ты можешь создать либу на C# — но чтобы другие ее могли использовать на всех 6 платформах им нужно заплатить $749.

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

S> Более того — это вендорлок. Что ты будешь делать, если эта конторка загнется или решит перестать поддерживать твой язык?

Какой еще вендорлок??? У них только один собственный язык (паскалеподобный), остальные языки мейнстримовые (например, там есть радость Лаптева — GOшечка, на которой так же можно фигатчить под все платформы и даже с гуем). RTL и некоторые тулзы вообще с открытыми кодами

Загнись контора, языковые скилы никуда не пропадут (будет печально, конечно, вернуться в песочницу МС/гугла/жабы, но люди и там живут. не смертельно)

А что ты будешь делать, когда завтра АНБ запретит использовать сисиплюсы во всех странах сателитах? Вернешься в неньку, возрождать местое ойти? Глупости, примерно, одного порядка.

avalon/3.0.2

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

S> А ты то использовал эту платформу?

Да. И знаю людей, у которых на этом продукт.

S> Я не слышал даже ранее, не смотря на то что хабр читаю постоянно.

Читай лучше.

https://habr.com/ru/sandbox/111016/
https://habr.com/ru/articles/489708/

S> А теперь подумай почему конкретно ты так не хочешь учить C++ и готов отмазывать C#, даже платить деньги за это — крыть нечем?

От ненадобности. От ненадобности и отвратного синтаксиса. И шарп туда же.

avalon/3.0.2

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

R>Нет. Ты платишь за клевые возможности предоставляемые инструментом (в доку загляни, почитай о концепциях), а так же за качественную поддержку.

Нам лишь нужна одна возможность — чтобы код либы работал на всех 6-ти платформах — об этом же речь.

C# из коробки стандартными инструментами так не умеет — в мире нет ни одной НИ ОДНОЙ библиотеки на C#, которая бы собиралась под все платформы. Ну нет их.

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

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

А как люди будут собирать вашу библиотеку? Допустим, вы хотите продать библиотеку с исходниками за $500. Люди ее сами хотят собирать. Пробуют собрать под все платформы (проверив код, добавив то что им нужно) — и фига. Спрашивают у вас как — а вы такой — ну, понимаете, еще нужно штуку баксов добавить чтобы купить прогу, которая умеет это собирать

Сказать куда вас пошлют?

Нет, это не решение.

S>> Более того — это вендорлок. Что ты будешь делать, если эта конторка загнется или решит перестать поддерживать твой язык?

R>Какой еще вендорлок??? У них только один собственный язык (паскалеподобный), остальные языки мейнстримовые (например, там есть радость Лаптева — GOшечка, на которой так же можно фигатчить под все платформы и даже с гуем). RTL и некоторые тулзы вообще с открытыми кодами

Загнись контора, языковые скилы никуда не пропадут (будет печально, конечно, вернуться в песочницу МС/гугла/жабы, но люди и там живут. не смертельно)

Да причем тут их языки. Без их приблуды вы уже не сможете собирать либы на C# под все платформы. Т.е. вы привязываетесь к ним. Поднимут цену или или вообще выкинут C# — и все.

R>А что ты будешь делать, когда завтра АНБ запретит использовать сисиплюсы во всех странах сателитах? Вернешься в неньку, возрождать местое ойти? Глупости, примерно, одного порядка.

Это не в их власти. А вот коммерческий продукт вполне могут прекратить развивать — скажут что убыточно. Было уже много раз.

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

S>> А теперь подумай почему конкретно ты так не хочешь учить C++ и готов отмазывать C#, даже платить деньги за это — крыть нечем?
R>От ненадобности. От ненадобности и отвратного синтаксиса. И шарп туда же.

Так а что же не туда же?

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

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

S>> То есть ты утверждаешь, что на С++ невозможно компилить код для 6 платформ?
S>>IL код прекрасно транслируется в С++. А кто там, что пишет мне неизвестно. Я даже нативными библиотеками не пользуюсь. Вернее если и пользуюсь, то они где то далеко скрыты в PInvoke
S>>и их минимум.

S>Как IL транслировать в C++ ? Дай пример — посмотрим что там получается. Что со сборкой мусора?
Я уже давал тебе ссылки на Il2CPP. Смотри Unity на том же яблоке.
Но IL2CPP старый проект надо смотреть Native AOT
Кстати про заголовочные файлы https://github.com/dotnet/runtime/issues/100747

По .Net Native больше информации
https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation

.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

Примечание

.NET Native использует тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию. Дополнительные сведения о сборке мусора см. в разделе Основы сборки мусора.

Здесь про производительность про эволюцию Native AOT .Net 8 vs .Net 9.
Вообще MS вкладываются в развитие Native AOT
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/

Усовершенствования встраивание для собственного AOT

Тут нашел
https://www.linux.org.ru/forum/development/17559964/page1?ysclid=m2608onp93145387422

По словам Claude.ai:

Here are some key points about garbage collection in .NET Native AOT-compiled binaries:

GC Design: The .NET Native GC is designed to be simpler and more predictable than the traditional .NET GC. It uses a non-compacting, mark-and-sweep algorithm, which avoids the need for compaction and simplifies the GC implementation.
AOT Compilation: During the AOT compilation process, the compiler analyzes the code and generates GC information and metadata that is embedded in the final binary. This metadata is used by the AOT GC at runtime.
GC Triggering: The AOT GC is triggered based on a simple threshold mechanism. When the amount of allocated memory crosses a predefined threshold, the GC is triggered to reclaim unused memory.
Thread Suspension: Unlike the traditional .NET GC, which suspends all threads during a collection, the .NET Native GC uses a concurrent marking phase that allows threads to continue running during most of the collection cycle.
Memory Layout: The .NET Native GC uses a different memory layout compared to the traditional .NET runtime. It separates the managed heap into different regions, including the new object space, the large object space, and the pinned object space.
Performance Characteristics: The .NET Native GC is designed to be more deterministic and predictable in terms of performance, at the cost of some throughput compared to the traditional .NET GC. This predictability is important for scenarios like ahead-of-time compiled apps, where consistent performance is crucial.
Btw., следующий релиз .NET v9 нацелен на cloud-native приложения, наверно, Goкрыс на мороз будут выпинывать?

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

S> И вы тут приводите какой-то сторонний инструмент, который за немалые деньги якобы может это обеспечить.

Не якобы, а обеспечивает. Продажа всего двух лицензий твоей либы ($500) покроет все расходы. Ойфончик дороже стоит.

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

S> А как люди будут собирать вашу библиотеку?

Сам собирай.

S> Допустим, вы хотите продать библиотеку с исходниками за $500. Люди ее сами хотят собирать.

Идут и качают триал (за 30 дней осилят, поди), коли им чешется самим собирать

S> Да причем тут их языки. Без их приблуды вы уже не сможете собирать либы на C# под все платформы. Т.е. вы привязываетесь к ним. Поднимут цену или или вообще выкинут C# — и все.

Цену они, как раз, снизили и прилично. Раньше было дороже. И, разумеется, никто не станет выкидывать никакие компиляторы, не выдумывай.

S> Это не в их власти. А вот коммерческий продукт вполне могут прекратить развивать — скажут что убыточно. Было уже много раз.

Обычно, то что убыточно, выкидывают в опенсорс. В общем, спорить с твоими фантазиями скучно и не интересно. Но ты уже знаешь, что сисиплюс не единственное решение, уже хорошо.

avalon/3.0.2

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

S> S>> А теперь подумай почему конкретно ты так не хочешь учить C++ и готов отмазывать C#, даже платить деньги за это — крыть нечем?

S> R>От ненадобности. От ненадобности и отвратного синтаксиса. И шарп туда же.

S> Так а что же не туда же?

Pascal, Ada.

avalon/3.0.2

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

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

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

S>>> То есть ты утверждаешь, что на С++ невозможно компилить код для 6 платформ?
S>>>IL код прекрасно транслируется в С++. А кто там, что пишет мне неизвестно. Я даже нативными библиотеками не пользуюсь. Вернее если и пользуюсь, то они где то далеко скрыты в PInvoke
S>>>и их минимум.

S>>Как IL транслировать в C++ ? Дай пример — посмотрим что там получается. Что со сборкой мусора?
S>Я уже давал тебе ссылки на Il2CPP. Смотри Unity на том же яблоке.
S> Но IL2CPP старый проект надо смотреть Native AOT
S>Кстати про заголовочные файлы https://github.com/dotnet/runtime/issues/100747

S>По .Net Native больше информации
S>https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation

Если бы это реально работало — была бы хотя бы одна библиотека в мире, написанная на C#, и которую можно собрать под все 6 платформ.

Мне не охота время тратить — уверен на 99.99999% что там подводные камни, которые сводят все на нет.

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

R>Не якобы, а обеспечивает. Продажа всего двух лицензий твоей либы ($500) покроет все расходы. Ойфончик дороже стоит.

Деньги на дороге не валяются, тем более либа может быть и более дешевая.

R>Идут и качают триал (за 30 дней осилят, поди), коли им чешется самим собирать

Нет, так серьезные люди не работают.

R>Обычно, то что убыточно, выкидывают в опенсорс. В общем, спорить с твоими фантазиями скучно и не интересно. Но ты уже знаешь, что сисиплюс не единственное решение, уже хорошо.

Но потом оно будет работать ограниченно, если вообще будет.

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

S> R>Не якобы, а обеспечивает. Продажа всего двух лицензий твоей либы ($500) покроет все расходы. Ойфончик дороже стоит.

S> Деньги на дороге не валяются, тем более либа может быть и более дешевая.

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

S> R>Идут и качают триал (за 30 дней осилят, поди), коли им чешется самим собирать

S> Нет, так серьезные люди не работают.

Чой-та? А сисиплюсы качать не потребуется для сборки твоей либы? К тому же, там триал полнофункциональный.

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

S> Но потом оно будет работать ограниченно, если вообще будет.

Чой-та? Если все будет выложено, то и проблем не будет.

avalon/3.0.2

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

R>Короче, это не высокая цена за инструмент профессиональной деятельности. И за нее ты получаешь то, чего нет у бесплатных инструментов — поддержку (а у этой конторы поддержка очень хорошая).

Дело в другом. Библиотеки часто продают с исходниками, не в скомпленном виде. Особенно когда речь не про $30 версию а про $200-500.

Так вот — ты обязываешь каждого пользователя покупать эту приблуду, которая им нафиг не нужна.

S>> R>Идут и качают триал (за 30 дней осилят, поди), коли им чешется самим собирать

S>> Нет, так серьезные люди не работают.
R>Чой-та? А сисиплюсы качать не потребуется для сборки твоей либы? К тому же, там триал полнофункциональный.

С++ компиляторов куча — бесплатне легально и навсегда. Все собирается одной командой. В т.ч. можно и на сервере сборку настроить автоматом.

А эта приблуда на билд-сервере будет работать на Линуксе?

S>> Но потом оно будет работать ограниченно, если вообще будет.
R>Чой-та? Если все будет выложено, то и проблем не будет.

Если нет поддержки — новые версии языка перестанут работать.

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

Опенсорс с двойной политикой лицензирования уже не получится сделать — чтобы либа, скачал и под любую платформу скриптом сбилдил БЕСПЛАТНО.

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

S> Дело в другом. Библиотеки часто продают с исходниками, не в скомпленном виде. Особенно когда речь не про $30 версию а про $200-500.

И?

S> Так вот — ты обязываешь каждого пользователя покупать эту приблуду, которая им нафиг не нужна.

Ничего покупать не нужно. Качаешь тулзу БЕСПЛАТНО. Устанавливаешь. Собираешь свою библиотеку. Целых 30 дней можешь собирать и пересобирать. Ничего платить не нужно. К слову, я уже не помню точно, но, кажется, там компилятор командной строки вообще бесплатный (т.е. будет работать без ограничений).

S> R>Чой-та? А сисиплюсы качать не потребуется для сборки твоей либы? К тому же, там триал полнофункциональный.

S> С++ компиляторов куча — бесплатне легально и навсегда. Все собирается одной командой. В т.ч. можно и на сервере сборку настроить автоматом.

И че, их качать и ставить не нужно?

S> А эта приблуда на билд-сервере будет работать на Линуксе?

Я сам не пробовал, но версия компилятора и инструментов сборки для линукса там есть.

S> Если нет поддержки — новые версии языка перестанут работать.

Так прибежит толпа фанатиков опенсорса и запилит. Так было с борландовским интребейзом, когда его выкинули на мороз. Благодаря этому сейчас есть клевый файрберд (а интербейз даже воскрес).

S> В любом случае — нафиг нужно это, привязываться к какой-то мелкой конторке с неясными перспективами да еще и за платно. Это не то. Это ограничивает и совсем другой тип продукта получается — никому это не нужно.

Я с эмоциями спорить не умею и не стану.

S> Опенсорс с двойной политикой лицензирования уже не получится сделать — чтобы либа, скачал и под любую платформу скриптом сбилдил БЕСПЛАТНО.

...и с нелепыми фантазиями тоже.

avalon/3.0.2

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

R>Ничего покупать не нужно. Качаешь тулзу БЕСПЛАТНО. Устанавливаешь. Собираешь свою библиотеку. Целых 30 дней можешь собирать и пересобирать. Ничего платить не нужно. К слову, я уже не помню точно, но, кажется, там компилятор командной строки вообще бесплатный (т.е. будет работать без ограничений).

Вы как школьник рассуждаете. Типа скачал — и раз работает — то можно делать что хочешь.

Так и Windows Server покупать не нужно — зачем, если там полноценный триал 90 дней а потом можно и грохнуть инстанс и создать заново. Зачем 6 штук баксов платить за Windows Server 2022 Datacenter?

Нет, так это не работает.

В первую очередь при выборе ПО юрист компании смотрит НА ЛИЦЕНЗИЮ. Позволяет ли лицензия использовать или нет. Код может быть доступен даже вообще открыт, но копания будет платить деньги за лицензию (не смотря на то что теоретически могли бы надуть и скачать по GPL, ведь автор то не узнает сразу об этом).

Триальная версия не дает вам права коммерческого использования и это всплывет.

R>И че, их качать и ставить не нужно?

Дело не в скачать — бесплатно скачать вы и Windows можете. Дело в политике лицензирования.

Разбирайтесь в политиках лицензирования — что такое GPL, BSD, MIT — почему даже при двойном лицензировании компании платят деньги, а не юзают тайком бесплатно.

Школьник Вася может и плевал бы на все эти вопросы — но так у него и денег нет, он по другим принципам живет. Он и покупать ничего не будет.

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

S> Триальная версия не дает вам права коммерческого использования и это всплывет.

Компилятор командной строки там был бесплатным. Посмотрел сейчас, они вообще всю систему сборки собираются сделать открытой (кстати да, на линуксе, в рамках билд-сервера, оно работает).

avalon/3.0.2

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

S>> Триальная версия не дает вам права коммерческого использования и это всплывет.
R>Компилятор командной строки там был бесплатным.

Где бесплатный? Что скачать?

R>Посмотрел сейчас, они вообще всю систему сборки собираются сделать открытой (кстати да, на линуксе, в рамках билд-сервера, оно работает).

Но вот когда сделают — тогда и посмотрим. В любом случае остается риск что продукт перестанут поддерживать — уже было много подобных примеров.

C++ может и не имеет рюшечек, однако в нем есть фундамент — работает на 6 платформах бесплатно навсегда с множеством компиляторов, каждый из которых развивается независимо без риска прекращения поддержки всего — без единой точки отказа.

Вы предлагаете фундаментом сделать некую корпорацию https://en.wikipedia.org/wiki/RemObjects_Software — т.е. свою жизнь завязать на некую конторку, в которой даже не ясно сколько людей работает. Нужно ли объяснять что это плохой фундамент?

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

S> S>> Триальная версия не дает вам права коммерческого использования и это всплывет.

S> R>Компилятор командной строки там был бесплатным. Посмотрел сейчас, они вообще всю систему сборки собираются сделать открытой (кстати да, на линуксе, в рамках билд-сервера, оно работает).

S> Где бесплатный? Что скачать?

Компилятор командной строки был бесплатным с далеких времен: http://remobjects.github.io/train/Compiling/index.html (правда, они этот факт не особо афишируют)

Страница скачивания елементов: https://www.remobjects.com/elements/channels.aspx

Там есть полный пакет, иде для мака и отдельно компиляторы и система сборки для линукса и мака.

Про установку компилятора говорится здесь: https://docs.elementscompiler.com/Compiler/Installing/

the command line compiler is installed and made available automatically as part of the regular setup. To just install the command line compiler, you can simply disable the "Water" and "Visual Studio" option when running setup.

А это https://www.remobjects.com/elements/ebuild.aspx их система сборки, которую они собираются сделать открытой.

А вот сборка C# проекта этим ebuild'ом:

C:\Utils\test\ConsoleApplication>ebuild ConsoleApplication.sln
RemObjects EBuild. An open source build engine for Elements and beyond.
Copyright RemObjects Software 2016-2024. All Rights Reserved. Created by marc hoffman.
Version 12.0.0.2933 (develop) built on bajor, 20240614-153333. Commit a71c401.

Solution 'ConsoleApplication' built successfully.

avalon/3.0.2

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

R>Компилятор командной строки был бесплатным с далеких времен: http://remobjects.github.io/train/Compiling/index.html (правда, они этот факт не особо афишируют)

А где скачать отдельно компилятор командной строки для MacOS?

Вообще много неудобств, даже размер бинарника. Вот у меня было требование — чтобы WASM-модуль был не более 1 Мб. И я делал прогу месяц — весь код компилился в модуль около 700 Кб. Размер кода — папка с исходниками — была 359 Кб. А remobjects после компиляции пустого проекта в WASM — уже дает 8 Мб

Это важно.

R>Страница скачивания елементов: https://www.remobjects.com/elements/channels.aspx

R>Там есть полный пакет, иде для мака и отдельно компиляторы и система сборки для линукса и мака.

Не нашел бесплатный для MacOS. Для Windows тоже есть?

R>Про установку компилятора говорится здесь: https://docs.elementscompiler.com/Compiler/Installing/
R>

the command line compiler is installed and made available automatically as part of the regular setup. To just install the command line compiler, you can simply disable the "Water" and "Visual Studio" option when running setup.

R>А это https://www.remobjects.com/elements/ebuild.aspx их система сборки, которую они собираются сделать открытой.

Вопрос — могу ли я ее использовать бесплатно легально — по какой лицензии?

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

S> Вообще много неудобств, даже размер бинарника. Вот у меня было требование — чтобы WASM-модуль был не более 1 Мб. И я делал прогу месяц — весь код компилился в модуль около 700 Кб. Размер кода — папка с исходниками — была 359 Кб. А remobjects после компиляции пустого проекта в WASM — уже дает 8 Мб

Это важно.

Не знаю, как у тебя получилось 8 Мб, когда даже с отладочной информацией у меня получается около 3 Мб, релизная сборка — 1.8 Мб (за плюшки управляемой среды нужно платить). При передаче на клиента gzip ее пожмет до 460 Кб.

S> Не нашел бесплатный для MacOS.

Ссылка так и назывется: "Elements — Mac & Linux Zip Distro "

S> Для Windows тоже есть?

On Windows, the command line compiler is installed and made available automatically as part of the regular setup. To just install the command line compiler, you can simply disable the "Water" and "Visual Studio" option when running setup.

S> R>А это https://www.remobjects.com/elements/ebuild.aspx их система сборки, которую они собираются сделать открытой.

S> Вопрос — могу ли я ее использовать бесплатно легально — по какой лицензии?

Об этом можешь на их форуме спросить.

avalon/3.0.2

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

R>Не знаю, как у тебя получилось 8 Мб, когда даже с отладочной информацией у меня получается около 3 Мб, релизная сборка — 1.8 Мб (за плюшки управляемой среды нужно платить). При передаче на клиента gzip ее пожмет до 460 Кб.

Почему вы так заступаетесь?

Вот в режиме релиза: https://download.ru/files/bUD5OW6M

То что пожмет — мой WASM ужимает до 200 Кб. Это притом что мой не пустой — там месяц работы.

S>> Не нашел бесплатный для MacOS.

R>Ссылка так и назывется: "Elements — Mac & Linux Zip Distro "

Не нашел, гугл тоже не выдает.

R>Об этом можешь на их форуме спросить.

Для начала нужно его найти — я не нашел. А уже потом узнавать о лицензии. Без этого и речи быть не может, чтобы ввязываться.

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

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

S> R>Не знаю, как у тебя получилось 8 Мб, когда даже с отладочной информацией у меня получается около 3 Мб, релизная сборка — 1.8 Мб (за плюшки управляемой среды нужно платить). При передаче на клиента gzip ее пожмет до 460 Кб.

S> Почему вы так заступаетесь?

Потому что верю своим глазам:

S> То что пожмет — мой WASM ужимает до 200 Кб.

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

S> Это притом что мой не пустой — там месяц работы.

Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

S> R>Ссылка так и назывется: "Elements — Mac & Linux Zip Distro "

S> Не нашел, гугл тоже не выдает.

Я тебе ссылку дал два сообщения назад: https://www.remobjects.com/elements/channels.aspx

S> R>Об этом можешь на их форуме спросить.

S> Для начала нужно его найти — я не нашел.

На главной странице сайта смотрел? Точно?

S> Вот есть QT, по удобству использования как .Net примерно. Там лицензия более-мене прозрачная. Не супер, но для некоторых маловажных проектов сойдет.

Сколько весит wasm модуль использующий Qt? Просто интересно.

avalon/3.0.2

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

R>Цифры одного порядка. На фоне приезжающих на клиента мегабайтов джиэса, эти цифры просто ни о чем.

На MacOS — вы сами видели — 4 Мб в Release.

S>> Это притом что мой не пустой — там месяц работы.
R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

А если мне это не нужно?

R>Я тебе ссылку дал два сообщения назад: https://www.remobjects.com/elements/channels.aspx

А пробовал то перейти по ней? Меня перебрасывает на https://www.remobjects.com/elements/download.aspx — а там предлагает ввести email и присылает ссылку на триальную Elements Trial Downloads.

Возможно раньше это было а потом решили лавочку прикрыть

Что не редко для таких продуктов — гарантии нет.

R>На главной странице сайта смотрел? Точно?

Попробуйте скачать. Выше написал.

В том то и фишка — это за штуку баксов. Причем для компании — нужно раскошеливаться еще больше, цена не указана а значит будут доить.

Смысла нет привязываться к платным инструментам, которыми заправляет некая мелкая контора.

S>> Вот есть QT, по удобству использования как .Net примерно. Там лицензия более-мене прозрачная. Не супер, но для некоторых маловажных проектов сойдет.
R>Сколько весит wasm модуль использующий Qt? Просто интересно.

К сожалению прямо сейчас не могу проверить, у меня установлено без WASM а доустанавливает оно долго. Я собирал wasm без QT, не нужно было.

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

S> На MacOS — вы сами видели — 4 Мб в Release.

От ОС это не зависит. Это зависит от типа проекта, который ты выбрал. Выбери просто WebModule, размер будет меньше.

S> R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

S> А если мне это не нужно?

GC неотъемлемая часть платформы (даже когда софт собирается для Win32 или Linux), придется смириться.

S> А пробовал то перейти по ней? Меня перебрасывает на https://www.remobjects.com/elements/download.aspx — а там предлагает ввести email и присылает ссылку на триальную Elements Trial Downloads.

Тебя смущает, что у них нет отдельных страниц для скачивания? У них непосредственно система сборки пишет, что она open source, несмотря на то, что скачивается через страницу trial downloads. Оставь им мыло, получишь прямую ссылку (https://downloads.elementscompiler.com/RemObjects%20Elements%20-%20Mac%20and%20Linux%20Zip%20Distro%20-%2012.0.0.2949.zip).

S> Возможно раньше это было а потом решили лавочку прикрыть

Что не редко для таких продуктов — гарантии нет.

Чего гадать — спроси на форуме.

avalon/3.0.2

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

R>От ОС это не зависит. Это зависит от типа проекта, который ты выбрал. Выбери просто WebModule, размер будет меньше.

Его и выбрал: https://download.ru/files/hQKs9igW

S>> R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

S>> А если мне это не нужно?

R>Тебя смущает, что у них нет отдельных страниц для скачивания? У них непосредственно система сборки пишет, что она open source, несмотря на то, что скачивается через страницу trial downloads. Оставь им мыло, получишь прямую ссылку (https://downloads.elementscompiler.com/RemObjects%20Elements%20-%20Mac%20and%20Linux%20Zip%20Distro%20-%2012.0.0.2949.zip).

Вводил, прислали Elements Trial Downloads. Ну ладно, благодарю за ссылку — если она есть — то уже хорошо.

S>> Возможно раньше это было а потом решили лавочку прикрыть

Что не редко для таких продуктов — гарантии нет.
R>Чего гадать — спроси на форуме.

Пока это не заслуживает внимания. Слишком не надежный фундамент. Конторка мелкая, неизвестная. Узнаваемость — плохая.

То что есть бесплатная версия — уже что-то, можно сказать что это конкурент QT худо-бедный. Хотя у QT все инструменты доступны бесплатно, просто ограничение по лицензии.

То что есть для MacOS бесплатное — уже что-то, но маловато для захвата рынка.

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

S> R>От ОС это не зависит. Это зависит от типа проекта, который ты выбрал. Выбери просто WebModule, размер будет меньше.

S> Его и выбрал: https://download.ru/files/hQKs9igW

Я же вижу по коду, что ты выбрал не его, а WebModule w/ CodeBehind

S> S>> R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

S> Вводил, прислали Elements Trial Downloads. Ну ладно, благодарю за ссылку — если она есть — то уже хорошо.

Значит ты и пытался скачать полный комплект элементов (как раз первая ссылка на странице).

S> R>Чего гадать — спроси на форуме.

S> Пока это не заслуживает внимания. Слишком не надежный фундамент. Конторка мелкая, неизвестная. Узнаваемость — плохая.

Вот спрашивается, нафига было тут воду в ступе толочь, если ты для себя все давно решил?

avalon/3.0.2

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

S>> Пока это не заслуживает внимания. Слишком не надежный фундамент. Конторка мелкая, неизвестная. Узнаваемость — плохая.
R>Вот спрашивается, нафига было тут воду в ступе толочь, если ты для себя все давно решил?

Так а что вы предлагаете? Платить штуку баксов? Без этого нормально не поработаешь. И привязка к такой мелкой конторке — слишком рискованно. Это слишком серьезный вопрос.

Тем более это не решение индивидуального разработчика — это может решить тот, кто тебя нанимает. Никак иначе. При масштабировании придется докупать и докупать лицензии. Так что вряд-ли кто-то согласится на это.

Еще момент — оно слишком мало распространено. Если возникнут проблемы — не факт что быстро сможете решить, оно не обкатано. А проблемы возникать будут уже в процессе работы.

Вывод: плохой это фундамент. Если вы берете за фундамент MS — это еще пол беды, все-таки компания многомиллиардная. И то риск. НО MS не дает вам кроссплатформенного преимущества.

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

S>Меня интересуют не философские измышления и как в теории это возможно (может быть)

О-о-o, и давно?

Здравствуйте, Shmj, Вы писали:
S>Я к 40 годам начал смотреть на суть. Когда будет возможно сделать библиотеку на C#, которую можно будет использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?
1. Зачем?
2. Никогда. На что это влияет?
3. Знаете ли вы язык, на котором можно сделать библиотеку, которую можно использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?
4. Почему вы пишете приложения не на этом языке?

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

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

S> R>Вот спрашивается, нафига было тут воду в ступе толочь, если ты для себя все давно решил?

S> Так а что вы предлагаете? Платить штуку баксов? Без этого нормально не поработаешь. И привязка к такой мелкой конторке — слишком рискованно. Это слишком серьезный вопрос.

За инструмент разработки заплатить. Тебя это удивляет?

S> Тем более это не решение индивидуального разработчика — это может решить тот, кто тебя нанимает. Никак иначе. При масштабировании придется докупать и докупать лицензии. Так что вряд-ли кто-то согласится на это.

Я не пойму, то ты о своей библиотеке говоришь, то о разработке в найме. Эта контора свои продукты продает ет двадцать уже. Кто-то, таки, соглашается на такое.

S> Еще момент — оно слишком мало распространено. Если возникнут проблемы — не факт что быстро сможете решить, оно не обкатано. А проблемы возникать будут уже в процессе работы.

Снова твои фантазии. Проблемы они решаюют без бюрократической волокиты буквально за часы. Если осилишь найти форум сможешь сам в этом убедиться.

S> Если вы берете за фундамент MS — это еще пол беды, все-таки компания многомиллиардная.

Эта многомиллиардная сколько раз уже сливала своих последователей? VB, Silverlight, ActiveX, .NET FW... Другой многомиллиардной посвящен целый сайт с кладбищем ее продуктов. Тоже мне, гарантии.

avalon/3.0.2

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

R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

Кстати в WebAssembly завезли GC
https://developer.chrome.com/blog/wasmgc?hl=ru

WasmGC — предложение группы сообщества WebAssembly . Текущая реализация Wasm MVP способна работать только с числами, то есть целыми числами и числами с плавающей запятой, в линейной памяти, а с учетом предложения ссылочных типов Wasm может дополнительно удерживать внешние ссылки. WasmGC теперь добавляет типы кучи структур и массивов, что означает поддержку нелинейного распределения памяти. Каждый объект WasmGC имеет фиксированный тип и структуру, что позволяет виртуальным машинам легко генерировать эффективный код для доступа к своим полям без риска деоптимизации , которая свойственна динамическим языкам, таким как JavaScript. Таким образом, это предложение добавляет в WebAssembly эффективную поддержку управляемых языков высокого уровня через типы кучи структур и массивов, которые позволяют компиляторам языков, ориентированным на Wasm, интегрироваться со сборщиком мусора в виртуальной машине хоста. Проще говоря, это означает, что с помощью WasmGC портирование языка программирования на Wasm означает, что сборщик мусора языка программирования больше не должен быть частью порта, а вместо этого можно использовать существующий сборщик мусора.

Чтобы проверить реальное влияние этого улучшения, команда Chrome Wasm скомпилировала версии теста Fannkuch (который выделяет структуры данных по мере их работы) из C , Rust и Java . Бинарные файлы C и Rust могут иметь размер от 6,1 до 9,6 КБ в зависимости от различных флагов компилятора, тогда как версия Java намного меньше — всего 2,3 КБ ! C и Rust не включают сборщик мусора, но они по-прежнему связывают malloc/free для управления памятью, и причина, по которой Java здесь меньше, заключается в том, что ей вообще не нужно связывать какой-либо код управления памятью. Это всего лишь один конкретный пример, но он показывает, что двоичные файлы WasmGC потенциально могут быть очень маленькими, и это еще до какой-либо значительной работы по оптимизации размера.

Проблемы в .Net [wasm][post-MVP] garbage collection proposal in .NET

A new way to bring garbage collected programming languages efficiently to WebAssembly

GC Post-v1 Extensions

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

R>За инструмент разработки заплатить. Тебя это удивляет?

Зачем покупать, если есть лучше с лучшей поддержкой, работающее на всех платформах и бесплатно?

Можно купить, когда инструмент проверен, используется многими, баги отлажены и вы 100% знаете что он уменьшит количество работы, а не добавит новых проблем.

R>Я не пойму, то ты о своей библиотеке говоришь, то о разработке в найме. Эта контора свои продукты продает ет двадцать уже. Кто-то, таки, соглашается на такое.

Но не достигла популярности и узнаваемости.

R>Снова твои фантазии. Проблемы они решаюют без бюрократической волокиты буквально за часы. Если осилишь найти форум сможешь сам в этом убедиться.

Вы попробуйте узнать по какой лицензии RemObjects Elements — Mac and Linux Zip Distro можно использовать.

S>> Если вы берете за фундамент MS — это еще пол беды, все-таки компания многомиллиардная.
R>Эта многомиллиардная сколько раз уже сливала своих последователей? VB, Silverlight, ActiveX, .NET FW... Другой многомиллиардной посвящен целый сайт с кладбищем ее продуктов. Тоже мне, гарантии.

Вот по этому лучше сразу делать ставку на открытые стандартизированные решения.

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

S>>Я к 40 годам начал смотреть на суть. Когда будет возможно сделать библиотеку на C#, которую можно будет использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?
S>1. Зачем?

Кроссплатформа зачем? Потому что чем шире твои возможности — тем лучше. Зачем себя ограничивать?

S>2. Никогда. На что это влияет?

На то что не стоит к нему привязываться.

S>3. Знаете ли вы язык, на котором можно сделать библиотеку, которую можно использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?

Да. К примеру C, C++, Rust.

S>4. Почему вы пишете приложения не на этом языке?

Именно на нем и пишем.

S>Здесь отвечать не обязательно — вопросы риторические. Направлены на то, чтобы вы начали смотреть в нужную сторону хотя бы к 50 годам

Почему риторические?

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

S> Кстати в WebAssembly завезли GC
S>https://developer.chrome.com/blog/wasmgc?hl=ru

Ну еще не завезли — а только в планах, еще не везде работает даже к экспериментальном режиме.

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

S>>1. Зачем?
S>Кроссплатформа зачем? Потому что чем шире твои возможности — тем лучше. Зачем себя ограничивать?
Кроссплатформа — не то же самое, что и "библиотека для любого ЯП на всех шести платформах ". Сам по себе дотнет — вполне себе кроссплатформенный, и приложения на нём работают примерно везде, включая экзотику вроде Эльбруса.
S>>2. Никогда. На что это влияет?
S>На то что не стоит к нему привязываться.
Этот вывод нужно обосновывать.
S>>3. Знаете ли вы язык, на котором можно сделать библиотеку, которую можно использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?
S>Да. К примеру C, C++, Rust.
Ну, попробуйте задействовать "библиотеку на Rust" из Delphi.
Попробуйте использовать C-шную библиотеку из Java. Ну, например, отсортируйте мне джавовский String[] через qsort из C RTL.
Уверяю — вас ждут незабываемые приключения. Так что вы, судя по всему, совершенно спокойно пишете на языках, на которых невозможно написать библиотеку, доступную из любых других языков. Библиотеку на Расте вы будете использовать из Раста, библиотеку на С++ — из С++. А вовсе не из "любого ЯП". Ну, так и библиотеку, написанную на C#, можно использовать из любого языка .Net на любой из шести платформ. То есть в этом плане кроссплатформенность у шарпа выходит получше, чем у языков вашего выбора. Причём с двумя из трёх у вас могут возникнуть неожиданные приключения при переносе с платформы на платформу и без интеропа с другими языками. А с одним из этих двух вас поджидает неожиданный секас даже при смене компилятора в пределах одной платформы.

S>>4. Почему вы пишете приложения не на этом языке?
S>Именно на нем и пишем.
Ну вот нет. Единственный язык, библиотеку на котором можно вызвать более-менее из любого языка (и то, с оговорками) — это C. Вы на нём не пишете примерно ничего.
S>>Здесь отвечать не обязательно — вопросы риторические. Направлены на то, чтобы вы начали смотреть в нужную сторону хотя бы к 50 годам

S>Почему риторические?
Потому что отвечать не обязательно. Если бы вы дали себе труд подумать перед тем, как отвечать, то сами бы увидели ошибки в своих рассуждениях.

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

S>> Кстати в WebAssembly завезли GC
S>>https://developer.chrome.com/blog/wasmgc?hl=ru

S>Ну еще не завезли — а только в планах, еще не везде работает даже к экспериментальном режиме.

Ну главное, что уже не на бумаге, а бетта версия. Кстати и в .Net WASM как эксперимент используется как песочница.
DotNetIsolator [EXPERIMENTAL]

Экспериментируют Experimental WASI SDK for .NET Core

Я к тому, что WASM в недалеком будущем будет основным форматом мультиплатформенных приложений

S>Когда будет возможно сделать библиотеку на C#, которую можно будет использовать из любого ЯП на всех шести операционных системах/платформах, доступных человечеству?

Если кратко — это сейчас никому не нужно.

Вызывать напрямую библиотеку от другой среды/языка это всегда геморрой. Даже внутри C++ одно лишь конвертирование строк между разными библиотеками чего стоит.

На родном для библиотеки языке пишем executable обертку которая: читает данные из stdin, предает эти данные нужным методам библиотеки и выплевывает результат работы в stdout.

Уже на своем любимом языке/фреймворке пишем оркестрацию поднятия процессов и общения с ними.

Когда появится лишнее время или упремся в объемы данных уходим от stdin/out в сторону всяких пайпов, сокетов, http и проч.

Естественно, такое для всяких npm:is_odd библиотек не катит, но это извраты JS ...

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

S>Если кратко — это сейчас никому не нужно.
S>Вызывать напрямую библиотеку от другой среды/языка это всегда геморрой. Даже внутри C++ одно лишь конвертирование строк между разными библиотеками чего стоит.

Нужно и востребованно. Я уже приводил пример библиотеки, которая собирается под все 6 платформ и используется из всех ЯП простым способом — есть обертки даже для C#.

На C# вы такой в принципе не сможете написать. Попробуйте найти хотя бы одно решение — посмотрим. Уверен что в мире нет ни одной такой библиотеки.

Вы просто как бы влюбились в язык. Как блондинка — хочу эту сумочку. И потом сама себя начинает убеждать что именно эта сумочка самая лучшая.

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

S>Вы просто как бы влюбились в язык. Как блондинка — хочу эту сумочку. И потом сама себя начинает убеждать что именно эта сумочка самая лучшая.
Это ты как раз про себя написал. Это ты всех убеждаешь, что С++ эта та самая сумочка!
А тебе говорят, что есть и другие сумочки!

S>На родном для библиотеки языке пишем executable обертку которая: читает данные из stdin, предает эти данные нужным методам библиотеки и выплевывает результат работы в stdout.

Как будто написать "оркестрацию поднятия процессов и общения с ними" просто.
Уж лучше строки конвертировать.

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

S>Нужно и востребованно. Я уже приводил пример библиотеки, которая собирается под все 6 платформ и используется из всех ЯП простым способом — есть обертки даже для C#.
В некоторых частных случаях действительно, можно написать такую библиотеку, которую можно использовать примерно откуда угодно. Я вам по соседству привёл примеры других случаев, в которых вам не помогут ни Rust, ни C++, ни C. Отсутствие комментариев туда с вашей стороны вполне красноречиво.

S>На C# вы такой в принципе не сможете написать. Попробуйте найти хотя бы одно решение — посмотрим. Уверен что в мире нет ни одной такой библиотеки.
Если ограничить своё понимание "библиотеки" некоторыми частными случаями, то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.

По итогу: выдуманные вами критерии оценки языков не применяются никем, в том числе и вами. Поэтому вопрос о языковых предпочтениях должен решаться на основе каких-то других критериев.

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

S>то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.

Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.

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

S>>то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.

S>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.
Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно.
Но возможность есть!

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

S>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
S> Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.

Я даже не представляю как это сделать. Как быть с GC?

S> Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно.
S>Но возможность есть!

Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.

Более того — на мин. примере оно может и сработает — но для продакшена точно не годится.

Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?

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

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

S>>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
S>> Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.

S>Я даже не представляю как это сделать. Как быть с GC?
А чем тебе GC мешает? Разные менеджер памяти так он ив C++ есть.
Выкручиваются через копирование или обработку памяти.

S>> Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно.
S>>Но возможность есть!

S>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.
Я тебе приводил ссылку на создание заголовков для C++. Значит используют.
https://github.com/dotnet/runtime/issues/100747

S>Более того — на мин. примере оно может и сработает — но для продакшена точно не годится.

S>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?
Поверь уже делают. Только не на этом форуме.

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

S>>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.
S> Я тебе приводил ссылку на создание заголовков для C++. Значит используют.
S>https://github.com/dotnet/runtime/issues/100747

Это для AOT — не поддержки всех платформ.

S>>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?
S> Поверь уже делают. Только не на этом форуме.

Ну приведешь пример хотя бы одной такой библиотеки во Вселенной — поверю.

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

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

S>>>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.
S>> Я тебе приводил ссылку на создание заголовков для C++. Значит используют.
S>>https://github.com/dotnet/runtime/issues/100747

S>Это для AOT — не поддержки всех платформ.
AOT компилируется для всех платформ. Еще раз формируется С++ код со сборщиком мусора.
S>>>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?
S>> Поверь уже делают. Только не на этом форуме.

S>Ну приведешь пример хотя бы одной такой библиотеки во Вселенной — поверю.

Я уже давал. https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

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

S>>Это для AOT — не поддержки всех платформ.
S>AOT компилируется для всех платформ. Еще раз формируется С++ код со сборщиком мусора.

Нет — под моб. платформы не собирается.

Здравствуйте, Shmj, Вы писали:
S>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
Всё прекрасно получится. Например, MS SQL Server, написанный на C++, прекрасно исполнял дотнетовый код вплоть до недавних версий, где это было выпилено за ненадобностью. Делал он это, разумеется, на всех платформах.

Встречное предложение — попробовать столкнуться с практикой и привинтить какую-нибудь типовую header-only library на С++ к проекту на более-менее любом языке. Хоть даже и к С.
Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности:
1. Различия в языковых концепциях. Языки программирования настолько различны, что очень немногие конструкции есть сразу во всех. В большинстве случаев вы не сможете воспользоваться ничем, кроме "голых функций". Плюсовые шаблоны и операторы невозможно употребить ни в одном языке, кроме С++ — и то, при условии, что вы собираете весь код одним и тем же компилятором.
2. Различия в реализации похожих и даже одинаковых концепций. Наследование в Java, Javascript, и C++ реализовано настолько по-разному, что вы не сможете использовать классы, написанные на любом из этих языков, в других языках. Исключения — то же самое: не сможете вы поймать исключение, выброшенное из C++-кода, ни в каком другом языке. Даже если в этом языке тоже есть исключения. Управление памятью — та же беда. Код, написанный для JVM, будет использовать один и тот же менеджер памяти. Код, написанный на С++, использовать из С нужно с великой осторожностью — иначе вы получите трудноуловимые утечки, и вообще undefined behavior на каждом первом шагу.

Как с учётом этого можно утверждать, что на С++ "можно написать библиотеку, которую потом использовать из любого языка на любой платформе", будучи в здравом уме — я хз.
Если же вдруг вы всё это осознавали, и имели в виду, что "примерно из любого языка и платформы есть байндинги к plain С коду", то я поясню: возможность позвать "просто функцию" из библиотеки требует, чтобы на стороне С++ вся функциональность этой библиотеки была выставлена наружу в виде "просто функций". То есть вы не можете выставить наружу допустим, класс Matrix<N, M>, который оборудован операторами сложения и перемножения матриц.
Вам придётся для начала переделать свою библиотеку так, чтобы размерность матрицы была частью её рантайм-заголовка, а не параметрами шаблона. Вы не сможете выставить наружу операторы сложения и умножения этих матриц — вы будете писать функции matrix_add и matrix_multiply. Вы не сможете проверять соответствие размеров операндов статически при компиляции — вам придётся вкрячить код этой проверки в каждую функцию. Вы не сможете бросить исключение в случае несовпадения размеров — вы будете вынуждены пойти на унизительные конвенции вроде "если не получилось, то вернём null-указатель вместо результата". Вы не сможете реализовать никакое автоматическое управление памятью — клиенты вашей библиотеки будут вынуждены вызывать ваши функции create_matrix и release_matrix, а если не позвали — утечка.
В общем и целом, вам проще писать эту библиотеку сразу на C.
При этом полезность этой библиотеки будет в разы ниже её плюсового оригинала. Клиенты исходной библиотеки, которые пишут на С++, могут делать всякие прикольные трюки — например, могут предоставить свой тип элемента матрицы, для которого подходящим образом определены операции сложения и умножения. Ваша С-шная поделка потребует от вас просто выставить наружу десяток перегрузок вида сreate_matrix_int32, сreate_matrix_float, сreate_matrix_double, и так далее. И возможности передать вам пользовательский тип так и не появится. Клиенты библиотеки на С++ могут предоставлять частичные специализации операторов — например, для того, чтобы эффективно перемножать матрицы конкретных размеров, используя специфические для конкретной платформы векторные инструкции. Ничего этого сделать с библиотекой, выставленной наружу через С-шный интерфейс, невозможно.

В итоге, интерфейс вашей библиотеки становится бутылочным горлышком. И даже те клиенты, которые в итоге пишут на С++, не могут воспользоваться этим преимуществом — ведь вы уже искалечили библиотеку ради эфемерной цели "использовать её из любого языка".
Ну, и в таких ограничениях, внезапно, весь код этой библиотеки можно прекрасно написать на C#. Точно так же, как и для С++, никакие специфические возможности платформы использовать не получится. А для plain old C struct есть value-типы. И всё будет прекрасно работать. GC никак не помешает — всё управление памятью будет снаружи. Клиент будет передавать в библиотеку пару указателей на функции malloc и free, и всё размещение динамики будет сделано через них.

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

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

S>>>Это для AOT — не поддержки всех платформ.
S>>AOT компилируется для всех платформ. Еще раз формируется С++ код со сборщиком мусора.

S>Нет — под моб. платформы не собирается.
Это как. Тот же Xamarin собирается под IOS/
Ну и здесь под .Net 9+ https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus

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

Вы имеете в ввиду что-то типа https://github.com/dotnet/samples/blob/main/core/nativeaot/NativeLibrary/Class1.cs ?

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

S>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
S>Всё прекрасно получится. Например, MS SQL Server, написанный на C++, прекрасно исполнял дотнетовый код вплоть до недавних версий, где это было выпилено за ненадобностью. Делал он это, разумеется, на всех платформах.

А на моб. платформах он работал? Отож.

S>Встречное предложение — попробовать столкнуться с практикой и привинтить какую-нибудь типовую header-only library на С++ к проекту на более-менее любом языке. Хоть даже и к С.

Делал и не раз, причем не только h-only.

S>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности:
S>1. Различия в языковых концепциях. Языки программирования настолько различны, что очень немногие конструкции есть сразу во всех. В большинстве случаев вы не сможете воспользоваться ничем, кроме "голых функций". Плюсовые шаблоны и операторы невозможно употребить ни в одном языке, кроме С++ — и то, при условии, что вы собираете весь код одним и тем же компилятором.
S>2. Различия в реализации похожих и даже одинаковых концепций. Наследование в Java, Javascript, и C++ реализовано настолько по-разному, что вы не сможете использовать классы, написанные на любом из этих языков, в других языках. Исключения — то же самое: не сможете вы поймать исключение, выброшенное из C++-кода, ни в каком другом языке. Даже если в этом языке тоже есть исключения. Управление памятью — та же беда. Код, написанный для JVM, будет использовать один и тот же менеджер памяти. Код, написанный на С++, использовать из С нужно с великой осторожностью — иначе вы получите трудноуловимые утечки, и вообще undefined behavior на каждом первом шагу.

Нужно только делать extern "C". Но это будет 100% собираться под все 6 платформ и работать ВЕЗДЕ. На C# так невозможно в принципе.

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

S>Это как. Тот же Xamarin собирается под IOS/

А позволяет ли он использовать собранные библиотеки из других языков?

S>Ну и здесь под .Net 9+ https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus

А ограничения то смотрели? Limitations of Native AOT deployment — No C++/CLI.

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

На самом деле крутые перцы из reddit смотрят сразу на суть — на базу, на фундамент. И языки выбирают по этому признаку. Вы можете 10 лет писать по найму и даже не задумываться об этом — не будет широты охвата — а у них это первый вопрос. Они все сидят с макбуками и iPhone и первый вопрос будет — насколько ЯП позволяет интегрироваться в эту экосистему + во все другие экосистемы.

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

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

M>Вы имеете в ввиду что-то типа https://github.com/dotnet/samples/blob/main/core/nativeaot/NativeLibrary/Class1.cs ?
Да есть варианты работы с памятью
https://github.com/dotnet/runtime/pull/100623/files#diff-6efaa03fe5e58e6efcff52c135ed0d07594bd03a6827cec592900bce0fabe029

Здравствуйте, m2user, Вы писали:
M>Вы имеете в ввиду что-то типа https://github.com/dotnet/samples/blob/main/core/nativeaot/NativeLibrary/Class1.cs ?
Да, совершенно верно.

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

S>А на моб. платформах он работал?
Если и не работал, то нерабочесть его была связана вовсе не с дотнетом. А как раз с кодом на C++

S>Делал и не раз, причем не только h-only.
"не только", my ass.

S>>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности:
S>Нужно только делать extern "C".
Я одного не могу понять — вы стебётесь или реально настолько некомпетентны?

Как по вашему, подойдёт вот такой библиотечный код для работы из любого языка?

extern "C" Matrix<int> * create_matrix_int(int n, int m)
{
   return new Matrix<int>(n, m);
}

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

S>>А на моб. платформах он работал?
S>Если и не работал, то нерабочесть его была связана вовсе не с дотнетом. А как раз с кодом на C++

Смотря какой C++-код генерит — в этом вопрос.

Если на работало — значит C++ -код был завязан на POSIX или еще что, чего в моб. не было.

S>>Делал и не раз, причем не только h-only.
S>"не только", my ass.

Для доступа из других языков обязательно делать C-обертку. Но на .Net вы и этим не сможете проблему решить.

S>>>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности:
S>>Нужно только делать extern "C".
S>Я одного не могу понять — вы стебётесь или реально настолько некомпетентны?

S>Как по вашему, подойдёт вот такой библиотечный код для работы из любого языка?
S>

S>extern "C" Matrix<int> * create_matrix_int(int n, int m)
S>{
S>   return new Matrix<int>(n, m);
S>}
S>

В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер.

Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать.

На C# вы этого под все 6 платформ сделать не сможете. Возможно что через платное решение за штуку баксов от www.remobjects.com — но это совсем другая история, я бы не рекомендовал.

Здравствуйте, Shmj, Вы писали:
S>Смотря какой C++-код генерит — в этом вопрос.
Вот именно.
S>Если на работало — значит C++ -код был завязан на POSIX или еще что, чего в моб. не было.
Вот именно.
S>Для доступа из других языков обязательно делать C-обертку.\
Перед обёрткой нужно провести кастрацию библиотеки.
S>Но на .Net вы и этим не сможете проблему решить.
И с чего бы это вдруг?

S>В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер.
Отож. "Привести к формату" можно только то, что приводится к формату. Ну не сможете вы STL привести к формату простого C.
S>Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать.

Нет, не можете. В обратную сторону всё работает точно так же — если у вас есть коллбэк, то он тоже ограничен. Я же вам пишу, а вы не читаете — попробуйте передать в С-шный qsort джавовскую коллекцию и кастомный компаратор, написанный на джаве. Более того — вы не можете передавать в qsort коллбэк, написанный на полном С++. Не получится выбросить исключение из коллбэка и поймать его в своём коде, вызывающем qsort. Упс, то есть в коде библиотеки вы не можете использовать "все фишки С++" — придётся ограничиться C-совместимыми. Про управление памятью я вам уже писал — либо выставлять наружу свои аналоги malloc/free, либо, наоборот, получать их снаружи.
Не получится вернуть "смарт поинтер", который гарантированно уничтожит объект после выхода из области видимости. Всё. Ничего от вашего С++ не осталось. Борьба с С++ за совместимость с C настолько малоприятна, что проще с самого начала писать библиотеку на С.

S>На C# вы этого под все 6 платформ сделать не сможете.
Да почему не смогу-то? Упорствуете в заблуждениях.
Точно так же смогу, написав C-шную обёртку. С теми же жертвами. Да, в конце концов, неважно, что будет за обёртка — если уж мы взялись оборачивать обёртками, кто мне запретит выставить мою "библиотеку" в виде REST-сервиса? Запустил себе приложение — и вызывай его через HTTP. А уж возможность вызывать REST есть даже на большем количестве платформ и языков, чем умеющих импортировать C-шные динамические и статические либы.

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

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

S>>Это как. Тот же Xamarin собирается под IOS/

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

S>>Ну и здесь под .Net 9+ https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus

S>А ограничения то смотрели? Limitations of Native AOT deployment — No C++/CLI.
C++/CLI это фишка древняя и малоподдерживаемая https://learn.microsoft.com/ru-ru/dotnet/core/porting/cpp-cli

Ограничения для C++/CLI .NET Core
Существуют некоторые важные ограничения для проектов C++/CLI и .NET по сравнению с платформа .NET Framework:

Компиляция проекта C++/CLI в исполняемый файл не поддерживается. Необходимо скомпилировать библиотеку DLL.
Поддержка C++/CLI для .NET доступна только для Windows.
Проекты C++/CLI не могут использовать .NET Standard.
Проекты C++/CLI не поддерживают более новый формат файла проекта в стиле ПАКЕТА SDK. Вместо этого проекты C++/CLI используют тот же формат файла .vcxproj , что и другие проекты Visual Studio C++.
Проекты C++/CLI не могут нацелиться на несколько платформ .NET. Если необходимо создать проект C++/CLI для .NET и платформа .NET Framework, используйте отдельные файлы проекта.
.NET не поддерживает -clr:pure или -clr:safe компиляцию, только более -clr:netcore новый параметр (который эквивалентен -clr платформа .NET Framework).

И сколько таких проектов C++/CLI?

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

S>На самом деле крутые перцы из reddit смотрят сразу на суть — на базу, на фундамент. И языки выбирают по этому признаку. Вы можете 10 лет писать по найму и даже не задумываться об этом — не будет широты охвата — а у них это первый вопрос. Они все сидят с макбуками и iPhone и первый вопрос будет — насколько ЯП позволяет интегрироваться в эту экосистему + во все другие экосистемы.

Библиотеки нужны прежде всего для доступа к коду .Net из разных языков.
Есть решения Написание пользовательского хост-приложения .NET для управления средой выполнения .NET из машинного кода

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

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

S>>Но на .Net вы и этим не сможете проблему решить.
S>И с чего бы это вдруг?

Потому что нужна реализация сборщика мусора и прочих фишек .net под все 6 платформ — а этого просто нет.

S>>В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер.
S>Отож. "Привести к формату" можно только то, что приводится к формату. Ну не сможете вы STL привести к формату простого C.

Внутри библиотеки пользуете все фишки C++ -а. А наружу делаете простые упрощенные обертки в C-стиле. Никаких проблем с этим нет. Библиотеку изменять не нужно.

S>>Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать.
S>

Нет, не можете. В обратную сторону всё работает точно так же — если у вас есть коллбэк, то он тоже ограничен.

Ссылка на функцию стандартизирована.

S>>На C# вы этого под все 6 платформ сделать не сможете.
S>Да почему не смогу-то? Упорствуете в заблуждениях.
S>Точно так же смогу, написав C-шную обёртку. С теми же жертвами. Да, в конце концов, неважно, что будет за обёртка — если уж мы взялись оборачивать обёртками, кто мне запретит выставить мою "библиотеку" в виде REST-сервиса? Запустил себе приложение — и вызывай его через HTTP. А уж возможность вызывать REST есть даже на большем количестве платформ и языков, чем умеющих импортировать C-шные динамические и статические либы.

Выше написал — нет сборщика мусора под все платформы и возможности собрать стандартную .net-библиотеку под все платформы. А C++ — все можно. Даже важные сторонние библиотеки все собираются под все платформы — тот же boost.

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

S> Библиотеки нужны прежде всего для доступа к коду .Net из разных языков.
S>Есть решения Написание пользовательского хост-приложения .NET для управления средой выполнения .NET из машинного кода

S> Их используют, но ты библиотек этих не найдешь. Это как "Видишь суслика — нет. А он есть!"
S>Это же касается и использование нативных библиотек. Сам натив нужен для приложений ускорения и обфускации прежде всего.
S> А создавать нативные кроссплатформенные библиотеки это уже некий приятный бонус.

Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких.

Зная человечество уверен что если бы это возможно было написать — уже написали бы. Людей миллионы и кому-то в голову эта идея пришла бы.

Раз не написано — то значит есть принципиальная невозомжность.

Попробуй написать сам и узнаешь в чем проблема. Можешь так же дать денег мне — я попробую написать и скажу почему не получилось.

Здравствуйте, Shmj, Вы писали:
S>Потому что нужна реализация сборщика мусора и прочих фишек .net под все 6 платформ — а этого просто нет.
Ну конечно же есть.

S>Внутри библиотеки пользуете все фишки C++ -а. А наружу делаете простые упрощенные обертки в C-стиле. Никаких проблем с этим нет. Библиотеку изменять не нужно.
Дыштакое то. Ну сделайте мне простые "упрощённые обёртки" над STL в C-стиле. Над boost::bind мне сделайте обёртку!

S>Ссылка на функцию стандартизирована.

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

S>Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких.
Вот вам такая библиотека: https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary
S>Зная человечество уверен что если бы это возможно было написать — уже написали бы. Людей миллионы и кому-то в голову эта идея пришла бы.
Нет конечно. Примерно никому такое не нужно. Вообще библиотек, которые "можно вызывать из любого языка на всех шести платформах", в мире единицы, независимо от языка их реализации.
И во всех из них на кроссплатформенность положено столько усилий, что простым гражданским это нафиг не упало.
То, что вам это кажется лёгким и приятным, связано не с тем, что это легко, а с тем, что сами вы ничего подобного никогда в жизни не пробовали писать и маинтейнить.
S>Раз не написано — то значит есть принципиальная невозомжность.
Редко удаётся встретить столь неудачную мысль.

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

S>>Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких.
S>Вот вам такая библиотека: https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary

Как мне ее собрать под iOS и вызвать из Flutter?

Как собрать из других 5 платформ и вызвать из Flutter?

Где скрипты сборки? Где описание процесса сборки?

Покажи что это реально работает. Желательно чтобы была авто-сборка в GitHub на всех платформах (хотя бы скрипты сборки под все 6 платформ человечества) — и h-файл для подключения.

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

S>>Ссылка на функцию стандартизирована.
S>

. А ссылка на объект класса — нет, не стандартизована. VMT не стандартизована. Обработка исключений не стандартизована. Менеджер памяти не стандартизован. Примерно ничего из того, что может захотеться использовать в С++-библиотеке, не стандартизовано.

Чтобы работать с объектом класса — используете хандлер.

Потом в метод передаете хандлер первым параметром и данные как в инстациональный метод. Все просто.

Вместо исключений — коды ответов + описание (если нужно).

Очистку памяти делаете специальными функциями.

Внутри же библиотеки можете использовать все возможности — ограничение только на верхнем уровне. И это правильно — чтобы была возможность универсального доступа из 6 платформ — так нужно сделать.

S>>Выше написал — нет сборщика мусора под все платформы
S>от повторения ваше заблуждение не станет ближе к истине. Под какую из платформ вы не нашли CLR?

Под iOS и Android.

S>>и возможности собрать стандартную .net-библиотеку под все платформы.
S>Есть такая возможность. Аж два раза: можно запаковать в "библиотеку" зависимость от .net runtime, и поставлять байткод. А можно собрать из библиотеки .dll/.lib под нужную платформу при помощи NativeAOT.

Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка.

S>>А C++ — все можно. Даже важные сторонние библиотеки все собираются под все платформы — тот же boost.
S>Вы путаете две ортогональных вещи: кроссплатформенность и межъязыковую совместимость. Оттого, что boost можно "собрать" (на самом деле — нельзя) под все платформы, он не станет доступным из кода на Java или Object Pascal. "

Boost можно собрать под все платформы и использовать в своей C++ -библиотеке. А чтобы использовать уже вашу библиотеку в других языках — пишется FFI-интерфейсы — читай методы на голом C. И это то немногое, с чем могли договорится все народы мира.

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

S>>>Выше написал — нет сборщика мусора под все платформы
S>>от повторения ваше заблуждение не станет ближе к истине. Под какую из платформ вы не нашли CLR?

S>Под iOS и Android.

Я уже тебе давал ссылку https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus
В .Net 9+ все поддерживается. Только в андроиде no built-in Java interop. Для IOS нет проблем.

S>>>и возможности собрать стандартную .net-библиотеку под все платформы.
S>>Есть такая возможность. Аж два раза: можно запаковать в "библиотеку" зависимость от .net runtime, и поставлять байткод. А можно собрать из библиотеки .dll/.lib под нужную платформу при помощи NativeAOT.

S>Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка.
Ты ну не читатель. Генерится все через рослин обрабатывая UnmanagedCallersOnly
Тут обсуждают https://github.com/dotnet/runtime/issues/100747

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

S> Я уже тебе давал ссылку https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus
S>В .Net 9+ все поддерживается. Только в андроиде no built-in Java interop. Для IOS нет проблем.

Зачем ты даешь доку? Дай готовую библиотеку со скриптами сборки под все платформы и h-файлом, чтобы я мог подключить ее в Python, Node.js или Flutter.

S>>Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка.
S> Ты ну не читатель. Генерится все через рослин обрабатывая UnmanagedCallersOnly
S>Тут обсуждают https://github.com/dotnet/runtime/issues/100747

Ну вот когда наобсуждаете — тогда и посмотрим.

По итогам попробуйте написать библиотеку + h-файл + скрипты сборки под 6 платформ. Пока я не вижу результат. Возможно вы сделали просто запуск приложений и библиотеки только для .Net — но это не то.

Здравствуйте, Shmj, Вы писали:
S>Как мне ее собрать под iOS и вызвать из Flutter?
S>Как собрать из других 5 платформ и вызвать из Flutter?
S>Где скрипты сборки? Где описание процесса сборки?
S>Покажи что это реально работает. Желательно чтобы была авто-сборка в GitHub на всех платформах (хотя бы скрипты сборки под все 6 платформ человечества) — и h-файл для подключения.
Сразу после того, как вы завернёте алгоритмы STL в FFI и покажете, как отсортировать ими список строк на Java.
Можно даже без авто-сборки на всех платформах.

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

S>Сразу после того, как вы завернёте алгоритмы STL в FFI и покажете, как отсортировать ими список строк на Java.
S>Можно даже без авто-сборки на всех платформах.

STL не нужно заворачивать — используйте внутри библиотеки обычным образом.

А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?

Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.

Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.

Возможно ли это?

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

S>STL не нужно заворачивать — используйте внутри библиотеки обычным образом.

S>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?

Как это не может? Все передается через Json сериализацию или gRPC
А многие используют и memory mapped files

Опять же по gRPC можно получить описание используемых классов через .proto

S>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.

S>Возможно ли это?
Ну тебе же уже давали ссылку. Кроме того через Source Generator или обработку Il кода нет проблем создать h файлы. Я уже тебе давал ссылки.

Но еще раз. Видишь суслика — нет. А он есть.
Кому надо те делают. Большинству это просто не нужно. Проще использовать тот же gRPC
В том же андроиде многое сделано через обмен сообщений с сервисами

S>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?
S>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.

Вооот, уже потихоньку прогресс пошел.

Осталось сделать шажок "Относитесь к FFI как в WebAPI" -> "А может сразу сделать WebAPI к библиотеке и не мучаться".

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

S>>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?

S> Как это не может? Все передается через Json сериализацию или gRPC
S>А многие используют и memory mapped files

Объект класса — это не только данные, но и связанные с ними методами. Как ты его передашь через WebAPI?

Вот и рассматривай FFI как аналог API к твоей библиотеке — только очень быстрый и с доп. возможностями.

S>Опять же по gRPC можно получить описание используемых классов через .proto

Классов или структур? Методы то не инстанциальные.

S>>Возможно ли это?
S>Ну тебе же уже давали ссылку. Кроме того через Source Generator или обработку Il кода нет проблем создать h файлы. Я уже тебе давал ссылки.

На что ссылку? На документацию Native AOT? Дай пример библиотеки + скрипты сборки под 6 платформ, которая поддерживает FFI.

S> Но еще раз. Видишь суслика — нет. А он есть.
S> Кому надо те делают. Большинству это просто не нужно. Проще использовать тот же gRPC
S>В том же андроиде многое сделано через обмен сообщений с сервисами

Вот в том то и дело что проще — потому что иначе невозможно и вы делаете через такой костыль. А это не то и близко не то. Это и медленно и требует доп. ресурсов.

Пойми — человечество за тысячелетия своего существования смогло договориться не о таком уж большом количестве стандартов. Так вот FFI — это то немногое, к чему смогли прийти люди и с чем согласились за миллионы лет своего развития.

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

S>Осталось сделать шажок "Относитесь к FFI как в WebAPI" -> "А может сразу сделать WebAPI к библиотеке и не мучаться".

WebAPI расточительно. Это сервер нужен, запросы, отдельный процесс.

Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно.

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

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

S>Пойми — человечество за тысячелетия своего существования смогло договориться не о таком уж большом количестве стандартов. Так вот FFI — это то немногое, к чему смогли прийти люди и с чем согласились за миллионы лет своего развития.

На самом деле универсальный это COM Портирование COM на Linux
СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.

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

S> На самом деле универсальный это COM Портирование COM на Linux
S>СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.

Нет, это чисто фишка MS. Ну портировали на Linux — ОК, Там же и Wine есть. На остальных платформах ничего и близко нет.

Повторюсь. Не так много вещей есть, с все народы мира согласились и приняли за стандарт. FFI — одна из немногих таких вещей. Это работает везде — из любых ЯП вы можете вызывать FFI.

C# просто фундаментально не состоявшийся язык — нет возможности писать универсальные библиотеки. Возможно появится такая возможность в будущем — но пока ее нет

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

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

S>> На самом деле универсальный это COM Портирование COM на Linux
S>>СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.

S>Нет, это чисто фишка MS. Ну портировали на Linux — ОК, Там же и Wine есть. На остальных платформах ничего и близко нет.

S>Повторюсь. Не так много вещей есть, с все народы мира согласились и приняли за стандарт. FFI — одна из немногих таких вещей. Это работает везде — из любых ЯП вы можете вызывать FFI.

FFI это про функции, а COM это про классы! Чувствуешь разницу?
СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT.
Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля.
Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.

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

S>FFI это про функции, а COM это про классы! Чувствуешь разницу?
S> СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT.
S>Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля.
S>Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.

Больше — не значит лучше. ООП — это особенность реализации конкретного языка. В другом языке ООП может вовсе не быть. Теряется универсальность.

Понятный для вас пример — WebAPI. WebAPI простой как двери — но стандарт и более-мене используется. Только это не подходит для библиотек — это сервер, медленный канал обмена, отдельный процесс и т.д.

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

S>>FFI это про функции, а COM это про классы! Чувствуешь разницу?
S>> СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT.
S>>Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля.
S>>Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.

S>Больше — не значит лучше. ООП — это особенность реализации конкретного языка. В другом языке ООП может вовсе не быть. Теряется универсальность.

S>Понятный для вас пример — WebAPI. WebAPI простой как двери — но стандарт и более-мене используется. Только это не подходит для библиотек — это сервер, медленный канал обмена, отдельный процесс и т.д.

Ну вот COM была поддержка всех языков на Windows. Это не проблема.
А вот те кто пишет кроссплатформенные библиотеки, они же как правило еще и предоставляют нормальный интерфейс для каждого языка. Например SkiaSharp это обертка над нативными SKIA библиотеками.
Никому не интересны голый FFI.

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

S> Ну вот COM была поддержка всех языков на Windows. Это не проблема.

Причем тут Windows? Библиотека должна писаться под все 6 платформ, а не под одну.

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

И этот интерфейс — основан на FFI всегда — загляните внутрь. Т.е. основа всего — функции на голом С.

Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно.

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

S>> Ну вот COM была поддержка всех языков на Windows. Это не проблема.

S>Причем тут Windows? Библиотека должна писаться под все 6 платформ, а не под одну.

При том, что COM вполне реально можно перенести на все платформы. Или VMT запретили?
S>> А вот те кто пишет кроссплатформенные библиотеки, они же как правило еще и предоставляют нормальный интерфейс для каждого языка. Например SkiaSharp это обертка над нативными SKIA библиотеками.
S>>Никому не интересны голый FFI.

S>И этот интерфейс — основан на FFI всегда — загляните внутрь. Т.е. основа всего — функции на голом С.

Я так и написал. Но голый FFI не интересен. Нужны классы над этими FFI, а это уже намного больше работы!
Ты видел SkiaSharp. Там обертка вокруг FFI в тысячи раз больше чем сам FFI

S>Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно.
WebAPI нужен, как и gRPC и SOAP. Но они ну ни как не аналогичны FFI.
Посмотри на gRPC и тот же swagger. Никакого аналога и близко нет. Это намного более функциональная надстройка.

Здравствуйте, Shmj, Вы писали:
S>STL не нужно заворачивать — используйте внутри библиотеки обычным образом.
Не-не-не. STL — это и есть библиотека.
S>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.
Прекрасно. Относитесь к WebAPI, как к FFI, только глобально доступному и полностью (а не ограниченно, как в C ABI) кроссплатформенному.
S>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.
S>Возможно ли это?
Да, возможно. Но я подожду момента, когда вы вызовете из Java STL.

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

S>WebAPI расточительно. Это сервер нужен, запросы, отдельный процесс.
Не нужен никакой "сервер". А наличие отдельного процесса — благо. Когда криворукий автор на той стороне забора не может запороть моё адресное пространство просто потому, что он не знал, что нельзя скармливать переданный ему указатель в его free.
S>Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно.
Хмм. Я начинаю подозревать, что вы либо не пробовали вызывать "немучительный" FFI ни из каких языков, кроме одного. Либо вы готовы взять свои необдуманные слова про "из любого языка" обратно. Скорее и то и другое — вы просто не представляете себе машинерию, которой обложены вызовы FFI в какой-нибудь JVM, при этом уже начали сдавать назад, перейдя от "любых" языков к "нормальным".
С таким подходом вообще не имеет смысла вступать в дискуссию — я просто объявлю "нормальным" ровно один язык: C#. И все языки будут делиться на те, на которых библиотеки для C#-клиентов писать удобно (например, C#), приемлемо (С), и все остальные, которые просто идут лесом за свою бесполезную громоздкость (например, C++ и Java).

S>Другой вопрос — что C# просто не умеет так.
Умеет. Но спроса на то, чего вы хотите, нету.

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

S> Я так и написал. Но голый FFI не интересен. Нужны классы над этими FFI, а это уже намного больше работы!

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

S>Ты видел SkiaSharp. Там обертка вокруг FFI в тысячи раз больше чем сам FFI

Обертку на родном языке можете сделать какую вам удобно — а сам интерфейс общий должен быть на универсальном стандарте, который признали все народы.

S>>Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно.
S> WebAPI нужен, как и gRPC и SOAP. Но они ну ни как не аналогичны FFI.
S>Посмотри на gRPC и тот же swagger. Никакого аналога и близко нет. Это намного более функциональная надстройка.

Представь что FFI — это сверх быстрый и супер оптимизированный WebAPI.

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

S>Не-не-не. STL — это и есть библиотека.

И что? Зачем ее портировать — в каждом языке — своя STL, удобная для парадигм этого языка.

Портируют библиотеки более универсальные.

S>>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.
S>Прекрасно. Относитесь к WebAPI, как к FFI, только глобально доступному и полностью (а не ограниченно, как в C ABI) кроссплатформенному.

Вот поколение смузи пошло. Если для каждой либы будете создавать свой процесс со своим взаимодействием по HTTP — никаких ресурсов не хватит.

S>>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.
S>>Возможно ли это?
S>Да, возможно. Но я подожду момента, когда вы вызовете из Java STL.

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

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

S>Не нужен никакой "сервер". А наличие отдельного процесса — благо. Когда криворукий автор на той стороне забора не может запороть моё адресное пространство просто потому, что он не знал, что нельзя скармливать переданный ему указатель в его free.

Не прячься за криворукость. Если библиотека с багами — ее тестируют, исправляют баги. А не полагаются на то что процесс можно будет постоянно убивать и воссоздавать.

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

C# так же позволяет вызывать либы FFI — так же совместим. Но на нем нельзя сделать универсальную либо под все 6 платформ. Ну нету таких.

S>>Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно.
S>Хмм. Я начинаю подозревать, что вы либо не пробовали вызывать "немучительный" FFI ни из каких языков, кроме одного. Либо вы готовы взять свои необдуманные слова про "из любого языка" обратно. Скорее и то и другое — вы просто не представляете себе машинерию, которой обложены вызовы FFI в какой-нибудь JVM, при этом уже начали сдавать назад, перейдя от "любых" языков к "нормальным".

FFI используется для универсальных библиотек, а не для тех, которые заточены под конкретный язык.

Внутри C++ библиотеки используете все возможности языка и стандартной библиотеки. А уже на верх отдаете в строгом API — по возможностям оно будет эвкивалентно WebAPI — только во много крат более быстрое и не трбовательное к ресурсам.

S>>Другой вопрос — что C# просто не умеет так.
S>Умеет. Но спроса на то, чего вы хотите, нету.

Вы можете дать пример такой библиотеки и победить в дискуссии. Но нету. Куча слов — а воз и ныне там.

Дайте библиотеку с 1 функцией, которая принимает и возвращает строку. Но чтобы были скрипты сборки по 6 платформ + h-файл в C-стиле, для вызова из других языков. Если есть такое хотя бы одно во Вселенной — я пожму руку и признаю поражение. Но чтобы не нужно было штуку баксов за это платить ежегодно — как с www.remobjects.com

Здравствуйте, Shmj, Вы писали:
S>Портируют библиотеки более универсальные.
Вот как раз STL — более универсальная. Потому что там алгоритмы отделены от контейнеров. Была бы возможность использовать её из Java — использовали бы.

S>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Прекрасно. Вижу, вы начали понимать, в чём проблема. Оказывается, навелосипедить на С++ можно вовсе не любую библиотеку, а только с существенными оговорками и ограничениями. И использовать её можно будет не из любого языка, а с существенными оговорками и ограничениями. Объём обёрток "снаружи" и "внутри" зачастую будет таким, что выгоднее просто выполнить порт библиотеки в целевой язык, чем оборачивать обёртки.

Именно поэтому "умение поддерживать FFI" очень-очень редко является критерием для выбора языка реализации. А там, где оно является, внезапно С++ начинает проигрывать банальному C в удобстве разработки такой библиотеки.
Я вам ещё раз напомню, что библиотека матричной алгебры "для С++" пишется совершенно по-другому, чем та же библиотека для "FFI экспортов". И никаких особенных преимуществ от использования С++ вместо C при написании такой библиотеки вы так и не получите.
Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++.
Ответ, конечно же, очевиден — потому что заявленный вами критерий неважен даже для вас самого. Поэтому из трудностей публикации FFI-экспортов для iOS (которые вполне преодолимы) в C# не следует примерно ничего.

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

S>>Портируют библиотеки более универсальные.
S>Вот как раз STL — более универсальная. Потому что там алгоритмы отделены от контейнеров. Была бы возможность использовать её из Java — использовали бы.

C++ -овская STL — заточена только под C++, она не универсальна и для других языков ее адаптировать смысла нет.

Java имеет свою стандартную библиотеку — ничем не хуже.

Вы путаете — хорошая и богатая библиотека, заточенная под язык — это не значит универсальная.

Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM.

S>>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
S>Прекрасно. Вижу, вы начали понимать, в чём проблема. Оказывается, навелосипедить на С++ можно вовсе не любую библиотеку, а только с существенными оговорками и ограничениями. И использовать её можно будет не из любого языка, а с существенными оговорками и ограничениями. Объём обёрток "снаружи" и "внутри" зачастую будет таким, что выгоднее просто выполнить порт библиотеки в целевой язык, чем оборачивать обёртки.

Из других языков можно исользовать обертку на урезанном голом C — т.н. FFI.

Но язык C++ позволяет сделать это для всех 6 платформ. Т.е. вы сможете написать либу на C++, сделать FFI обертку (сведя все к голому С) — и потом использовать на всех 6 платформах человечества из любого ЯП.

Это признак универсальности и взрослости языка.

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

S>Именно поэтому "умение поддерживать FFI" очень-очень редко является критерием для выбора языка реализации. А там, где оно является, внезапно С++ начинает проигрывать банальному C в удобстве разработки такой библиотеки.

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

S>Я вам ещё раз напомню, что библиотека матричной алгебры "для С++" пишется совершенно по-другому, чем та же библиотека для "FFI экспортов". И никаких особенных преимуществ от использования С++ вместо C при написании такой библиотеки вы так и не получите.

C++ позволяет где это удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.

Просто относитесь к этому как в WebAPI. Внутри либы в можете использовать все конструкции — но наружу отдаете в строгом стандарте упрощенно.

S>Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++.
S>Ответ, конечно же, очевиден — потому что заявленный вами критерий неважен даже для вас самого. Поэтому из трудностей публикации FFI-экспортов для iOS (которые вполне преодолимы) в C# не следует примерно ничего.

Еще раз — внешний интерфейс — FFI — максимально упрощен и стандартизирован, там нет классов. Как WebAPI по возможностям (ну лучше, конечно).

Внутри C++ позволяет более удобно работать с ООП. Это важно.

А внешне — да, тот же С-интерфейс отдаете. Это универсально.

На C# я не видел чтобы была такая возможность под все 6 платформ. Найдете или сами напишите скрипты сборки под все 6 платформ + FFI-доступ — ну значит вы были правы.

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

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

S>А пока лишь отговорки почему это не так важно. Нет уж, это самый главный критерий для библиотек. Если этого нет — то нельзя написать универсальную библиотеку.
Сейчас 9 ка выйдет
https://learn.microsoft.com/en-us/dotnet/maui/macios/xcsync?view=net-maui-9.0

И создать скрипт содержащий типа

dotnet build /t:xcsync-generate /p:xcSyncTargetFrameworkMoniker=net9.0-ios
dotnet build /t:xcsync-generate /p:xcSyncTargetFrameworkMoniker=net9.0-maccatalyst

Ну и для других платформ.

нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации.
В конце концов как для блазора есть интерпретация кода.

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

S> нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации.
S>В конце концов как для блазора есть интерпретация кода.

Можно ли будет это использовать из других ЯП — т.е. есть ли универсальность библиотек? Или же это вещь в себе — дотнетчики только для дотнетчиков?

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

S>> нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации.
S>>В конце концов как для блазора есть интерпретация кода.

S>Можно ли будет это использовать из других ЯП — т.е. есть ли универсальность библиотек? Или же это вещь в себе — дотнетчики только для дотнетчиков?

Native AOT это не про дотнетчики только для дотнетчиков. Для этого существуют нормальные Nuget в MSIL коде.

Если выставишь для методов Native AOT UnmanagedCallersOnly.
https://github.com/dotnet/runtime/issues/88737
https://github.com/dotnet/runtime/pull/92141
https://github.com/dotnet/runtime/issues/80905

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

S>Native AOT это не про дотнетчики только для дотнетчиков. Для этого существуют нормальные Nuget в MSIL коде.
S>Если выставишь для методов Native AOT UnmanagedCallersOnly.
S>https://github.com/dotnet/runtime/issues/88737
S>https://github.com/dotnet/runtime/pull/92141
S>https://github.com/dotnet/runtime/issues/80905

Вы даете ссылку не на то — зачем не ваши внутренние обсуждения из багтрекеров или реквесты?

Покажите пример библиотеки, которая содержит скрипты сборки под все 6 платформ а так же FFI -интерфейсы для вызова из все ЯП. К примеру, чтобы я собрал эту либу под macOS и вызвал и node.js. Или чтобы собрал под iOS и вызвал из Dart.

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

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

S>>Native AOT это не про дотнетчики только для дотнетчиков. Для этого существуют нормальные Nuget в MSIL коде.
S>>Если выставишь для методов Native AOT UnmanagedCallersOnly.
S>>https://github.com/dotnet/runtime/issues/88737
S>>https://github.com/dotnet/runtime/pull/92141
S>>https://github.com/dotnet/runtime/issues/80905

S>Вы даете ссылку не на то — зачем не ваши внутренние обсуждения из багтрекеров или реквесты?

S>Покажите пример библиотеки, которая содержит скрипты сборки под все 6 платформ а так же FFI -интерфейсы для вызова из все ЯП. К примеру, чтобы я собрал эту либу под macOS и вызвал и node.js. Или чтобы собрал под iOS и вызвал из Dart.

Я тебе уже показывал. Но ты не читатель! Я тебе должен показать все команды
dotnet build
dotnet publish

https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8
https://github.com/dotnet/BenchmarkDotNet/issues/2593

https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile

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

S> Я тебе уже показывал. Но ты не читатель! Я тебе должен показать все команды
S>dotnet build
S>dotnet publish

S>https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8
S>https://github.com/dotnet/BenchmarkDotNet/issues/2593

Вы не внимательны. Нужно все 6 платформ — включая iOS, Android и WASM.

И мне нужны не обсуждения или дока — а просто репозиторий с либой и скриптами сборки. Либа может быть очень простой — функция FFI для вызова из других ЯП. Потом соберем и посмотрим что получается, какой размер будет, как быстро работает и т.д. Но это уже второй шаг — пока даже первого шага я не вижу.

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

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

S>> Я тебе уже показывал. Но ты не читатель! Я тебе должен показать все команды
S>>dotnet build
S>>dotnet publish

S>>https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=linux-ubuntu%2Cnet8
S>>https://github.com/dotnet/BenchmarkDotNet/issues/2593

S>Вы не внимательны. Нужно все 6 платформ — включая iOS, Android и WASM.

S>И мне нужны не обсуждения или дока — а просто репозиторий с либой и скриптами сборки. Либа может быть очень простой — функция FFI для вызова из других ЯП. Потом соберем и посмотрим что получается, какой размер будет, как быстро работает и т.д. Но это уже второй шаг — пока даже первого шага я не вижу.
Я тебе и на IOS давал, про блазор и прочее писал и про андроид
https://github.com/jonathanpeppers/Android-NativeAOT
https://byandriykozachuk.wordpress.com/2023/12/29/net-wasi-native-aot-performance/

Сам поищи. Почему я должен тратить время?

dotnet publish -r wasi-wasm -c <Configuration> /p:MSBuildEnableWorkloadResolver=false /p:UseAppHost=false –self-contained

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

S>Я тебе и на IOS давал, про блазор и прочее писал и про андроид
S>https://github.com/jonathanpeppers/Android-NativeAOT
S>https://byandriykozachuk.wordpress.com/2023/12/29/net-wasi-native-aot-performance/
S> Сам поищи. Почему я должен тратить время?
S>dotnet publish -r wasi-wasm -c <Configuration> /p:MSBuildEnableWorkloadResolver=false /p:UseAppHost=false –self-contained

Вы даете куски каких-то экспериментов, все разрозненно. Там кто-то попробовал для эксперимента запустить Android, почему то даже не официальный сайт. Та кто-то WASM, то уже иначе.

Это еще не готовое промышленное решение. Это эксперименты, результат не всегда удачен.

Когда сможете сделать универсальную библиотеку — тогда и приходите — посмотрю, проверю. Цель я вам указал: (1) работает на 6 платформах, (2) доступна для подключения через все ЯП — т.е. FFI.

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

S>>Я тебе и на IOS давал, про блазор и прочее писал и про андроид
S>>https://github.com/jonathanpeppers/Android-NativeAOT
S>>https://byandriykozachuk.wordpress.com/2023/12/29/net-wasi-native-aot-performance/
S>> Сам поищи. Почему я должен тратить время?
S>>dotnet publish -r wasi-wasm -c <Configuration> /p:MSBuildEnableWorkloadResolver=false /p:UseAppHost=false –self-contained

S>Вы даете куски каких-то экспериментов, все разрозненно. Там кто-то попробовал для эксперимента запустить Android, почему то даже не официальный сайт. Та кто-то WASM, то уже иначе.

S>Это еще не готовое промышленное решение. Это эксперименты, результат не всегда удачен.

S>Когда сможете сделать универсальную библиотеку — тогда и приходите — посмотрю, проверю. Цель я вам указал: (1) работает на 6 платформах, (2) доступна для подключения через все ЯП — т.е. FFI.

Ты утверждаешь — ты и опровергай. Бери те ссылки которые я тебе указал и проверяй.
Тебе доказывают, что ты не прав! Есть возможность и люди используют!

Здравствуйте, Shmj, Вы писали:
S>Вы путаете — хорошая и богатая библиотека, заточенная под язык — это не значит универсальная.
Я как раз ничего не путаю. Критерии качества библиотеки, в порядке убывания приоритетов:
1. функциональность
2. удобство использования.
3. производительность
...
99. Возможность использования из других языков

Зачем мне, скажем, на C# пердолиться с библиотекой матричной алгебры, написанной на С++? Родная библиотека, написанная на любом CLR-нативном языке, будет в разы удобнее. Как раз потому, что я смогу использовать естественные для C# способы записи интерфейсов.
Или вот, скажем, библиотека linq2db. Она при использовании из C# рвёт любые другие способы доступа к данным как тузик грелку. Нативные для Java, нативные для JavaScript.
Её не имеет смысла даже пытаться выставлять наружу через FFI, потому что её достоинства не переживут такой кастрации. Можно попробовать навелосипедить её аналог на C++. Теоретически. Меня ещё несколько лет назад убедили, что С++ стал достаточно взрослым языком, чтобы суметь сделать то, что нужно. Однако, на практике подобной библиотеки для С++ не существует. Стало быть, эта возможность так и остаётся в области фантазий. Делает ли это С++ плохим языком? Ну, для приложений, которые в основном занимаются обработкой данных, таки да. Для других применений — нет, не делает.

S>Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM.
Кому должна-то? Зачем? Вы ставите телегу впереди лошади: сначала должна быть задача, а уже потом — её решение.

S>>>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Кто такие "мы"? Что за "универсальные библиотеки"? "Библиотеки" бывают очень и очень разные.

S>Из других языков можно исользовать обертку на урезанном голом C — т.н. FFI.
Ну так это же — слабое подобие левой руки. Если мы пишем библиотеку на C, то возможность задействовать её из других языков — прекрасно. Но это не означает, что С является единственным приемлемым языком.
Вообще, скажу вам по секрету, не существует единственного идеального языка. Невозможно "выучить" один язык и всю жизнь пользоваться только им.

S>Это признак универсальности и взрослости языка.
Это признак того, что вы не понимаете, как устроены критерии выбора языка.

S>C# пока такого не позволяет сделать. Т.е. вещь в себе — только для внутреннего использования.

S>Для разработки универсальной библиотеки — это главный критерий. А сейчас кроссплатформенность и возможность использования из родных платформ — очень важно.
Вы ещё даже не определились, что ваша библиотека будет делать.
S>C++ позволяет где это удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.

S>>Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++.
S>Внутри C++ позволяет более удобно работать с ООП. Это важно.
Преимуществ от ООП вы через FFI никаких не получите. Поэтому важность этой возможности для разработки универсальной библиотеки — околонулевая.

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

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

S>Ты утверждаешь — ты и опровергай. Бери те ссылки которые я тебе указал и проверяй.
S>Тебе доказывают, что ты не прав! Есть возможность и люди используют!

Я утверждаю что нет ни одной реально используемой C#-библиотеки (открытой), которая бы собиралась под все платформы (6 штук) и была адаптирована для использования чрез FFI.

Возможно какие-то эксперименты на частном уровне проводятся, так же существуют решения за деньги — типа remobjects.com (по 1000 долларов в год на каждого разраба). Но вот промышленного решения от MS пока нет и не факт что появится.

Опровергнуть меня очень легко. Даете ссылку на репо этой либы, где бы были скрипты сборки под 6 платформ и h-файл для вызова из других языков. Только пожалуйста не давайте ссылки на обсуждения и эксперименты. Просто репо покажи и все. Скрипты сборки обязательно.

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

S>Или вот, скажем, библиотека linq2db. Она при использовании из C# рвёт любые другие способы доступа к данным как тузик грелку. Нативные для Java, нативные для JavaScript.

Есть библиотеки, которые заточены исключительно под ваш язык и платформу. Центральная тема таких либ — ПЛАТФОРМА, ТЕХНОЛОГИЯ. Они для разработчиков, которые используют конкретный ЯП.

А есть либы, которые заточены под КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ, ПРОДУКТ. К примеру, либа для работы с мессенджером, крипто-либа, финансовая либа (крипта и пр.), сетевая (tor) — ее нет нужны писать для каждой платформы с нуля. Вы можете написать один раз — и использовать из всех платформ и языков.

Т.е. когда в центре — пользователь и его конкретная нужда — лучше писать универсальную либу для работы на всех платформах и вызова из всех языков.

S>>Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM.
S>Кому должна-то? Зачем? Вы ставите телегу впереди лошади: сначала должна быть задача, а уже потом — её решение.

Это нужно чтобы не делать одну и ту же работу n раз. Если нет универсальной либы — вам нужно 6*10 разных кодов поддерживать — для каждой из 6 платформ (ОС) + для каждого из 10 популярных ЯП.

Вместо этого — лучше сделать одну либу, которая собирается везде и которую можно вызвать из любого ЯП.

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

Зато существуют языки, на которых можно написать либу под все платформы и вызывать из всех ЯП.

то удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.

S>Преимуществ от ООП вы через FFI никаких не получите. Поэтому важность этой возможности для разработки универсальной библиотеки — околонулевая.

FFI — только снаружи виден. На внутреннюю реализацию это никак не влияет.

Это все равно что WebAPI — внешне вы даете в виде простого WebAPI — а внутри у вас сложная архитектура из множества классов.

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

Основное все должно быть в библиотеке. GUI и пр. нужно стремиться делать декларативным с минимумом сложных языковых конструкций. Все сложное нужно стремиться перенести в ядро в виде универсальных библиотек.

Здравствуйте, Shmj, Вы писали:
S>Есть библиотеки, которые заточены исключительно под ваш язык и платформу. Центральная тема таких либ — ПЛАТФОРМА, ТЕХНОЛОГИЯ.
Не обязательно. В STL центральная тема — не "платформа" или "технология". А отделение алгоритмов от структур. Центральная тема linq2db — это типизированный язык запросов.
Просто выясняется, что вот такие "центральные темы" невозможно выразить в терминах "плоских функций". Это не делает эти библиотеки плохими. Это делает плохой идею реализовывать такие библиотеки в терминах "плоских функций".

S>А есть либы, которые заточены под КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ, ПРОДУКТ. К примеру, либа для работы с мессенджером, крипто-либа, финансовая либа (крипта и пр.), сетевая (tor) — ее нет нужны писать для каждой платформы с нуля. Вы можете написать один раз — и использовать из всех платформ и языков.
"Работа с мессенджером", my ass. Современные мессенджеры управляются по WebAPI. То есть "либа" нужна не для того, чтобы вообще "работать с мессенджером". А для того, чтобы ошибочный код по взаимодействию с WebAPI обнаруживался компилятором. Например, правила работы с чатами/группами/каналами Телеграма удобно выражать в виде некой системы типов, несводимой к "целым числам разной разрядности" и "указателям на целые числа разной разрядности". Поскольку системы типов в разных языках совершенно разные, не имеет смысла писать "FFI обёртку" для C++-ной либы и потреблять её из Java. Имеет смысл выразить API телеграма в виде набора типов Java, или набора типов С++, или набора типов C#, или набора типов typescript. С-шная "библиотека" по работе с Телеграмом имеет отрицательную ценность при работе из любого языка, кроме С.
То же самое касается, скажем, "крипто-либы" по работе с Ethereum. То же самое — "финансовая либа". То же самое — "сетевая либа". Мне в дотнете нафиг не упали какие-то вызовы нативных функций по работе с tor. Мне надо идиоматическую обёртку, которую я могу использовать вместо обычного HTTP-соединения. Ничего этого мне С++ не даст.

S>Это нужно чтобы не делать одну и ту же работу n раз. Если нет универсальной либы — вам нужно 6*10 разных кодов поддерживать — для каждой из 6 платформ (ОС) + для каждого из 10 популярных ЯП.
Более-менее нормальные языки позволяют писать либу 1 раз, не задумываясь о платформе. Например, тот же C#, или Java, или Typescript. Write once, run everywhere — слыхали?
Не существует "linq2db для iOS". То, что С++ требует от вас унижаться при компиляции под каждую платформу — это его проблема, а не достоинство.

S>Вместо этого — лучше сделать одну либу, которая собирается везде и которую можно вызвать из любого ЯП.
Ещё раз поясню самую трудную для вас вещь: для всех перечисленных вами областей либа, специфичная для какого-то языка, будет в разы удобнее и полезнее т.н. "универсальной". Если вы собрались ставить во главу угла конечного пользователя, то последнее, что стоит делать — это кастрировать С++ библиотеку до extern "C".
А если вы собрались делать обёртки на всех 10 языках — то а) все эти обёртки вам всё равно придётся меинтейнить, и б) даже если вы сможете выделить из них какой-то общий код, который был бы вызывабелен через FFI, то этот код скорее всего удобнее будет писать на С, а не на С++.

Посмотрите на реальные примеры: https://core.telegram.org/tdlib/docs/td__json__client_8h.html Внезапно библиотека "по работе с мессенджером" из любого языка предлагает JSON в качестве формата данных. Читай — ребята изобрели WebAPI. Чисто для справки: этот FFI при использовании не будет шибко эффективнее, чем честный WebAPI или там передача JSON через сокет. Потому что в современных платформах сокет на localhost работает примерно так же, как и FFI вызов, только безопаснее с т.з. адресного пространства. Кроме того, обёртки вокруг сокетов на любом языке программирования уже сделаны безопасным образом — в частности, там решены все потенциальные проблемы с контролем за временем жизни передаваемого буфера. В вашем подходе рулить этим велосипедом предлагается самостоятельно.

S>FFI — только снаружи виден. На внутреннюю реализацию это никак не влияет.
Ну так используете-то вы библиотеку снаружи, а не изнутри. Если вы хотите превратить жизнь пользователя в ад — да, ок, добро пожаловать в extern "C". То, что вы там у себя внутри что-то где-то используете, никак ему не поможет. Я же вам привёл простые примеры — даже из С++ использовать библиотеку, написанную на С++, но бинарно скомпилированную и выставленную наружу через extern "C", в разы противнее, чем напрямую потреблять С++ из С++.

S>Основное все должно быть в библиотеке. GUI и пр. нужно стремиться делать декларативным с минимумом сложных языковых конструкций. Все сложное нужно стремиться перенести в ядро в виде универсальных библиотек.
Что "основное"-то? Приведённые вами примеры выглядят неубедительно.

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

S>>Это нужно чтобы не делать одну и ту же работу n раз. Если нет универсальной либы — вам нужно 6*10 разных кодов поддерживать — для каждой из 6 платформ (ОС) + для каждого из 10 популярных ЯП.
S>Более-менее нормальные языки позволяют писать либу 1 раз, не задумываясь о платформе. Например, тот же C#, или Java, или Typescript. Write once, run everywhere — слыхали?
S>Не существует "linq2db для iOS". То, что С++ требует от вас унижаться при компиляции под каждую платформу — это его проблема, а не достоинство.

Тут дело не только в запуске на 6 платформах — важно дать возможность вызова из других ЯП в качестве библиотеки.

А стандарт у нас один — FFI. Другого стандарта, извиняйте, человечество не придумало.

Поднимать для каждой либы сервер с HTTP-доступом — идиотизм. Люди придумали FFI, другого ничего нет — с этим согласились все народы и у нас просто нет другого выбора. Только это.

Если язык не поддерживает сборку на всех 6 платформах с возможностью создавать библиотеки с FFI-доступом — этот язык еще не зрелый.

Вот вам примеры таких библиотек:

1. OpenMVG https://github.com/openMVG/openMVG/blob/develop/BUILD.md#checking-out-the-project-and-build-it
2. Caffe https://github.com/BVLC/caffe
3. libtorrent https://github.com/arvidn/libtorrent
4. tensorflow https://github.com/tensorflow/tensorflow
5. ATen https://github.com/zdevito/ATen

— это очень удобно — делаете 1 раз для всех платформ, потом либа готова для использования из любого ЯП — обычно по умолчанию делают вызовы из Python.

Это на C++, но такая же идеология применяется и для C. По сути основа — договоренность — это язык C упрощенный. Но язык C++ позволяет сделать чуть удобнее внутри — а снаружи все-равно приводим к тому же FFI — это C, то с чем человечество смогло договориться.

Это самые крутые либы в мире, у которых много поклонников и на которых зиждется наша цивилизация. ATen — это математика для всех нейросетевых либ — на ней все зиждется. Без нее не будет ни GPT ни мечт от ИИ.

C# в фундаменте своем не позволяет вам работать на таком уровне. Т.е. уже изначально в самом фундаменте лажа. Чисто песочница детям играться во взрослых дядей.

От:	rameel	https://github.com/rsdn/CodeJam
Дата:	14.03.24 15:44
Оценка:	157 (4) +1

	От:	dmitry_npi
	Дата:	14.03.24 19:15
	Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	28.03.24 17:24
Оценка:

От:	_FRED_	@ViIvanov
Дата:	28.03.24 21:44
Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	29.03.24 10:08
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	14.06.24 19:52
Оценка:	14 (1) +2

	От:	Baiker
	Дата:	03.09.24 01:53
	Оценка:

	От:	Shmj
	Дата:	10.10.24 15:19
	Оценка:

	От:	Shmj
	Дата:	10.10.24 15:45
	Оценка:

	От:	Shmj
	Дата:	10.10.24 15:58
	Оценка: