Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше.
Чего ему не хватает? В чем проблемы?
Здравствуйте, Codealot, Вы писали:
C>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>Чего ему не хватает? В чем проблемы?
Нет нормального способа ее использовать. Я даже сам задумывался портировать на нее net и сделать нормальный фреймворк для работы.
Здравствуйте, Qulac, Вы писали:
C>>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>>Чего ему не хватает? В чем проблемы?
Q>Нет нормального способа ее использовать. Я даже сам задумывался портировать на нее net и сделать нормальный фреймворк для работы.
ну почему нет. Тот же Ren'Py — это игровой движок для визуальных новел. Я как-то пробовал ради интереса запустить на свое сервере — вполне норм, даже на мобиле вполне играбельно
Здравствуйте, Codealot, Вы писали:
C>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>Чего ему не хватает? В чем проблемы?
Да нет особых проблем. Я использую, все отлично — пример сайта
Здравствуйте, Codealot, Вы писали:
C>Чего ему не хватает? В чем проблемы?
Сейчас WASM не имеет доступа к системным функциям. Т.е. даже если хочешь получить время — то вызывай JS-функцию. Т.е. уже сходу нужно кучу оберток писать на JS, что увеличивает размер приложения ну или кто-то должен это сделать за тебя, т.е. создать фреймворк.
Но это еще пол беды. В принципе, если бы был удобный фреймворк для полноценного создания сайтов — то можно было бы юзать. Но сейчас разве что Flutter можно назвать таким полноценным фреймворком.
C>>Чего ему не хватает? В чем проблемы?
Ф>Не так то, что опрокинули тучу людей с флэшем. На флэше было дофига разного сделано, от мультиков и игр, до полноценных приложений. Веры больше нет.
Здравствуйте, Codealot, Вы писали:
C>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>Чего ему не хватает? В чем проблемы?
Уже выросло поколение, которое скорее backend на JS напишет, чем Java на frontend потащит.
Старое никто портировать не будет. Для нового логичнее использовать устоявшиеся технологии, под которые и с фреймворками всё понятно и специалистов на рынке много.
Будет тот же Microsoft дальше свой Blazor развивать и не кинет как с Silverlight — постепенно доля вырастет.
Здравствуйте, Codealot, Вы писали:
C>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>Чего ему не хватает? В чем проблемы?
Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
Здравствуйте, D. Mon, Вы писали:
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
IMHO для пользовательско интерфейса в веб-приложениях webassembly малоплоезно. Здесь javascript справляется отлично.
Но есть куча "числодробительных", "парсинговых", "файловых", "обработки изображений" и прочих библиотек, которые не имеют UI, и которые доступны допустим как nuget (для .net например)
Теперь это все достаточно просто скомпилировать в webassembly и вызывать просто как библиотечную функцию из javascritpt, с приемлемой производительностью, и все локально.
Здравствуйте, Codealot, Вы писали:
C>Насколько я могу судить со своей колокольни, не используется никем, кроме горстки фриков. Даже Ява-апплеты в свое время использовались на порядок больше. C>Чего ему не хватает? В чем проблемы?
Могу описать сугобо мое личное ИМХО, и было это давно может сейчас ситуация изменилась.
Прочитал я как-то про чудесную вещь Web-Assembly, Звучит супер, можно писать на любом языке, скомпилировать под платформу браузера и программа прям в браузере и будет работать.
Ура, я наконец-то смогу прям в браузере что-то свое запустить и для этого мне не надо учить JS! Вот написал я Hello World, и ищу как его скомпилировать и запустить.
Оказалось, все не так просто, и чтобы ее скомпилировать нужны были танцы с бубном, а запустить еще сложнее. А вот чтобы увидеть что она действительно вывела "hello world" надо ее немного модицицировать, так как в браузере нат консолького ввода вывода по умолчанию. И вообще, чтобы сделать что-нибудь, надо как-то извращенно вызывать JS функции, то есть все равно учить JS. В итоге забил я на это.
По скорости работы, я так понимаю у JS оно не особо выигрывает, на фронтенде каких-то сложных вычислений запускать смысла нет.
Конечно, если бы оно мне было сильно нужно, я бы наверное справился, но мне оно было не нужно.
Человеку занимающимуся фронтендом оно тоже не нужно, так как ему проще на JS все сделать.
Человеку не знакомому с фронтендом, разобраться с этим не так простото, так как все равно не разбираясь во фронтенде и JS ничего с ним особо не сделаешь.
Конечно есть узкие ниши, где Web-Assembly реально полезен, но они очень узкие.
Здравствуйте, Codealot, Вы писали:
C>Чего ему не хватает? В чем проблемы?
Используется профессионалами. Вот хороший пример, того что можно сделать. И тут еще много.
Здравствуйте, Codealot, Вы писали:
C>Чего ему не хватает? В чем проблемы?
Прямого DOM баиндинг нет, а значит надо с JS возюкаться, вот смысл и потерялся. На фреймворках типа Blazor(.net) или Dash(py) можно писать без JS, используя стандартные html/css. При этом Blazor довольно хорошо поддерживают wasm(MS костыли дописал в виде относительно бесшовного байдинга), но оно не сильно востребованно.
Здравствуйте, bnk, Вы писали:
bnk>Blazor для того чтобы скомпилировать .net в webassembly больше не нужен (начиная с .net 7), теперь можно комилировать напрямую без него.
Так штука в том, что без Blazor wasm не съедобен.
Здравствуйте, karbofos42, Вы писали:
K>Будет тот же Microsoft дальше свой Blazor развивать и не кинет как с Silverlight — постепенно доля вырастет.
Blazor и через websocket прекрасно работает, если сетка нормальная, а она теперь почти всегда нормальная. WASM он вряд ли спасет.
Здравствуйте, novitk, Вы писали:
bnk>>Blazor для того чтобы скомпилировать .net в webassembly больше не нужен (начиная с .net 7), теперь можно комилировать напрямую без него.
N>Так штука в том, что без Blazor wasm не съедобен.
Почему нет? Вполне.
Вот например я пару лет назад подробности описал когда сам понял как.
Сейчас (.NET8+) детали чуть поменялись, немного даже упростили все, но в принципе все так же.
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
вряд-ли оно взлетит из-за GC
и даже из-за API вряд-ли
оно продавалось как "вы даже не представляете, насколько оно будет быстрее"
а оказалось что не очень-то и будет. ну так, иногда кое-где.
так что осталась только ниша "скомпилировать сишный код который и так уже где-то работает"
что тоже неплохо, но от былой славы не осталось и следа
Здравствуйте, koenig, Вы писали:
K>так что осталась только ниша "скомпилировать сишный код который и так уже где-то работает" K>что тоже неплохо, но от былой славы не осталось и следа
Не только С-шный, но и высокоуровневый C++ с умными указателями, которые в не слишком кривых руках не особо уступают GC.
S>Не только С-шный, но и высокоуровневый C++ с умными указателями, которые в не слишком кривых руках не особо уступают GC.
глубочайшим образом побарабану
берешь с/с++ и компилишь
что там с мемори менеджментом тебе глубоко похрен, лишь бы не текло слишком быстро — смысл в том, чтобы готовый код использовать, а не в том, чтобы писать на каком-то там языке
Здравствуйте, koenig, Вы писали:
K>глубочайшим образом побарабану K>берешь с/с++ и компилишь K>что там с мемори менеджментом тебе глубоко похрен, лишь бы не текло слишком быстро — смысл в том, чтобы готовый код использовать, а не в том, чтобы писать на каком-то там языке
И готовый код и так же универсальные библиотеки, которые работают:
1. В Windows 32|64|ARM.
2. Android 32|64|ARM32|ARM64.
3. iOS
4. MacOS 64|ARM
5. Linux 32|64|ARM.
6. WASM.
— на каком языке, кроме С++ ну и разве что Rust (и то не уверен) — можно написать код и собрать под все эти платформы, после чего подключать либу из любой платформы и использовать из любого ЯП?
S>И готовый код и так же универсальные библиотеки, которые работают:
S>1. В Windows 32|64|ARM. S>2. Android 32|64|ARM32|ARM64. S>3. iOS S>4. MacOS 64|ARM S>5. Linux 32|64|ARM. S>6. WASM.
S>- на каком языке, кроме С++ ну и разве что Rust (и то не уверен) — можно написать код и собрать под все эти платформы, после чего подключать либу из любой платформы и использовать из любого ЯП?
Ты не поверишь. C#!
Правда внутри он использует С++.
Для примера Unity, Native AOT, BLAZOR ...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>- на каком языке, кроме С++ ну и разве что Rust (и то не уверен) — можно написать код и собрать под все эти платформы, после чего подключать либу из любой платформы и использовать из любого ЯП?
Ха,ха,ха. qt6 на c++ соберите его под любой winxp, или хотя бы под win7
Здравствуйте, Serginio1, Вы писали:
S>Ты не поверишь. C#! S>Правда внутри он использует С++.
S>Для примера Unity, Native AOT, BLAZOR ...
А какого размера минимальная библиотека получается для WASM?
Ну и второе, вроде нет поддержки то:
Windows x86 (32-bit) — ⚠️ поддержка есть, но экспериментальная/ограниченная
Android (x86, x64, ARM32, ARM64) ❌ официально — нет Native AOT ✔️ Но можно через .NET for Android (часть MAUI) — но это не Native AOT, а Mono AOT (интерпретатор + компиляция ahead-of-time).
iOS
❌ Нет официального Native AOT для iOS.
MAUI использует Mono AOT (LLVM) для iOS — это не .NET Native AOT, но тоже ahead-of-time компиляция.
Поддержка специфическая и в основном для UI приложений, а не CLI.
. WASM
❌ Native AOT не поддерживается.
Есть проект dotnet wasm и Blazor WebAssembly, но это не Native AOT, а Mono WASM + интерпретация/AOT.
Как видите — когда реально коснешься — ничего не работает. А C++ реально работает и на нем есть библитеки, которые работают и используются под все платформы на самом деле, а не в мечтах.
Здравствуйте, kov_serg, Вы писали:
S>>- на каком языке, кроме С++ ну и разве что Rust (и то не уверен) — можно написать код и собрать под все эти платформы, после чего подключать либу из любой платформы и использовать из любого ЯП? _>Ха,ха,ха. qt6 на c++ соберите его под любой winxp, или хотя бы под win7
А причем тут QT6? Речь про стандартный C++ и его стандартную библиотеку. Ну и для старых версий — придется использовать C++ старой версии — который будет работать даже на самых современных ОС.
Здравствуйте, Shmj, Вы писали:
S> И готовый код и так же универсальные библиотеки, которые работают:
S> 1. В Windows 32|64|ARM. S> 2. Android 32|64|ARM32|ARM64. S> 3. iOS S> 4. MacOS 64|ARM S> 5. Linux 32|64|ARM. S> 6. WASM.
S> — на каком языке, кроме С++ ну и разве что Rust (и то не уверен) — можно написать код и собрать под все эти платформы, после чего подключать либу из любой платформы и использовать из любого ЯП?
Здравствуйте, novitk, Вы писали:
n> K>Будет тот же Microsoft дальше свой Blazor развивать и не кинет как с Silverlight — постепенно доля вырастет.
n> Blazor и через websocket прекрасно работает, если сетка нормальная, а она теперь почти всегда нормальная. WASM он вряд ли спасет.
Не понял, причем тут вебсокеты, нормальная сетка и как оно все связано с блазором
S>>Для примера Unity, Native AOT, BLAZOR ...
S>А какого размера минимальная библиотека получается для WASM?
S>Ну и второе, вроде нет поддержки то:
S>Windows x86 (32-bit) — ⚠️ поддержка есть, но экспериментальная/ограниченная
S>Android (x86, x64, ARM32, ARM64) ❌ официально — нет Native AOT ✔️ Но можно через .NET for Android (часть MAUI) — но это не Native AOT, а Mono AOT (интерпретатор + компиляция ahead-of-time).
S>iOS S>❌ Нет официального Native AOT для iOS. S>MAUI использует Mono AOT (LLVM) для iOS — это не .NET Native AOT, но тоже ahead-of-time компиляция. S>Поддержка специфическая и в основном для UI приложений, а не CLI.
S>. WASM S>❌ Native AOT не поддерживается. S>Есть проект dotnet wasm и Blazor WebAssembly, но это не Native AOT, а Mono WASM + интерпретация/AOT.
S>Как видите — когда реально коснешься — ничего не работает. А C++ реально работает и на нем есть библитеки, которые работают и используются под все платформы на самом деле, а не в мечтах.
We’re extending .NET 8 support to IL2CPP across all major platforms. Initially, we’re bringing the .NET 8 BCL to core platforms, with plans to expand this over the next few months. Later, we’ll work on optimizing IL2CPP with .NET hardware intrinsics support and addressing the increase in C++ code generation as more .NET code is written in C#. IL2CPP will continue to rely on the Boehm GC.
Здравствуйте, Shmj, Вы писали:
S> aarch64-win64 — ⚠️ экспериментально, с ARM64 компилятором — доступно, но требует настройки.
Настройки оно не требует, если использовать fpcupdeluxe для установки.
S> WASM В FPC есть экспериментальный бэкенд WebAssembly (начиная с 3.2.x), но он ограничен
FPC supports three Wasm compilation targets: WASIp1 (WASI 0.1, also known as WASI Preview 1), WASIp1threads (WASI 0.1 with the wasi-threads proposal) and Embedded. See WebAssembly/Compiler on how to build and install FPC for Wasm.
S> Ну и главное — сравните количество библиотек на C++ и на Pascal. Вам придется все писать самому с нуля
Не придется. На паскале просто дофигища доступных библиотек.
Здравствуйте, Serginio1, Вы писали:
S>Все работает! C# это же не только MS — Mono WASM + интерпретация/AOT, Unity IL2CPP это все C#!
Ну если вы найдете хотя бы одну библиотеку на C#, которая умеет собираться под все платформы — будет о чем говорить. Я таких не встречал. Пионером быть не хочется.
Здравствуйте, Shmj, Вы писали:
S>А причем тут QT6? Речь про стандартный C++ и его стандартную библиотеку. Ну и для старых версий — придется использовать C++ старой версии — который будет работать даже на самых современных ОС.
Ага а у вас уже везде auto constexpr concept-ы корутины и std::filesystem и приехали только новый с++, старый не собирает.
Здравствуйте, kov_serg, Вы писали:
S>>А причем тут QT6? Речь про стандартный C++ и его стандартную библиотеку. Ну и для старых версий — придется использовать C++ старой версии — который будет работать даже на самых современных ОС. _>Ага а у вас уже везде auto constexpr concept-ы корутины и std::filesystem и приехали только новый с++, старый не собирает.
В каком смысле? g++ и clang++ — собирают C++98. Вам мало 98? Пишите изначально на более низкой версии C++, если нужны старые системы
Здравствуйте, Shmj, Вы писали:
S>>Все работает! C# это же не только MS — Mono WASM + интерпретация/AOT, Unity IL2CPP это все C#!
S>Ну если вы найдете хотя бы одну библиотеку на C#, которая умеет собираться под все платформы — будет о чем говорить. Я таких не встречал. Пионером быть не хочется.
Здравствуйте, bnk, Вы писали:
bnk>Почему нет? Вполне.
Дак, я же не спорю, что можно. Просто не понятно зачем. Blazor позволяет забыть про js, хотя и через костыли, a чистый wasm нет.
Здравствуйте, rudzuk, Вы писали:
R>Не понял, причем тут вебсокеты, нормальная сетка и как оно все связано с блазором
В Blazor есть interactive server. Он не требует wasm.
Здравствуйте, novitk, Вы писали:
n> R>Не понял, причем тут вебсокеты, нормальная сетка и как оно все связано с блазором
n> В Blazor есть interactive server. Он не требует wasm.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, novitk, Вы писали:
n>> R>Не понял, причем тут вебсокеты, нормальная сетка и как оно все связано с блазором
n>> В Blazor есть interactive server. Он не требует wasm.
R>А вебсокеты и нормальная сетка, это о чем?
Вероятно речь о т.н. Blazor Server (server side), генерация UI, состояние, обработка — всё на сервере, вебсокет (с пом. SignalR) — коммуникация клиента (браузера) с сервером, норм.сетка — отзывчивость UI. Ранее рекомендовали для интранета (норм.сетка).
Здравствуйте, rudzuk, Вы писали:
n>> В Blazor есть interactive server. Он не требует wasm. R>А вебсокеты и нормальная сетка, это о чем?
Так оно в этом режиме работает через вебсокет. Если сетка с плохой latency в UI будут лаги.
Здравствуйте, novitk, Вы писали:
n>>> В Blazor есть interactive server. Он не требует wasm. R>>А вебсокеты и нормальная сетка, это о чем? N>Так оно в этом режиме работает через вебсокет. Если сетка с плохой latency в UI будут лаги.
Все-таки нужно по максимуму перевесить работу на компьютер клиента. Еще и нагружать сервер рендером — лишние затраты финансовые.
Непонятно откуда инфа, что мало кто пользуется.
Пользуются чуть более чем все, кому нужна высокая производительность в вебчике и даже не в вебчике.
Вон в telegram веб-клиенте каждая анимированная клубничка на стикере головой машет на 60fps именно с помощью WS.
Здравствуйте, novitk, Вы писали:
n> Так оно в этом режиме работает через вебсокет. Если сетка с плохой latency в UI будут лаги.
Все, теперь понял. Просто, сначала подумал, что есть какие-то сложности с вебсокетами на "плохих" сетках, что меня удивило, учитывая почти нулевой оверхед вебсокетов.
Здравствуйте, Shmj, Вы писали:
S>В каком смысле? g++ и clang++ — собирают C++98. Вам мало 98? Пишите изначально на более низкой версии C++, если нужны старые системы
И тут мы приходим к мысли что так никто не собирается делать. Так что c++(n+1) уже давно не очень-то и портируемый
Здравствуйте, kov_serg, Вы писали:
S>>В каком смысле? g++ и clang++ — собирают C++98. Вам мало 98? Пишите изначально на более низкой версии C++, если нужны старые системы _>И тут мы приходим к мысли что так никто не собирается делать. Так что c++(n+1) уже давно не очень-то и портируемый
Ну вроде C++20 таки можно собрать для Windows 7. Но речь больше не о старых системах — а о новых, о широте охвата: Windows, Android, iOS, MacOS, Linux, WASM — и помножьте на процессоры (кроме WASM — там же, по сути, байткод).
Здравствуйте, Shmj, Вы писали:
S>Ну вроде C++20 таки можно собрать для Windows 7. Но речь больше не о старых системах — а о новых, о широте охвата: Windows, Android, iOS, MacOS, Linux, WASM — и помножьте на процессоры (кроме WASM — там же, по сути, байткод).
Именно широта охвата у современного c++ не очень. Вот у обыного С горадо выше. И тут мы приходим к https://vlang.io который компилирует в C кстати c++ раньше так умел.
S>>Ну вроде C++20 таки можно собрать для Windows 7. Но речь больше не о старых системах — а о новых, о широте охвата: Windows, Android, iOS, MacOS, Linux, WASM — и помножьте на процессоры (кроме WASM — там же, по сути, байткод). _>Именно широта охвата у современного c++ не очень. Вот у обыного С горадо выше.
Та чего выше? Даже для стиральных машинок можно на C++ фигачить. Каких девайсов вам реально не хватает?
Здравствуйте, kov_serg, Вы писали:
S>>Ну вроде C++20 таки можно собрать для Windows 7. Но речь больше не о старых системах — а о новых, о широте охвата: Windows, Android, iOS, MacOS, Linux, WASM — и помножьте на процессоры (кроме WASM — там же, по сути, байткод). _>Именно широта охвата у современного c++ не очень. Вот у обыного С горадо выше.
В чем отличие? Если Qt 6 не собрать под Win7, так это не от C++ зависит, а от авторов Qt.
Я только одну платформу встречал, где нет никакого C++ — это MSC-51, а не, вру, ещё лет 15 назад видел пром контроллер на 186ом, под который SDK и тулчейн был на TurboC. Вполен, впрочем, допускаю, что есть ещё какие-то фрические платформы без плюсов
Процесс публикации AOT в машинном коде создает автономный исполняемый файл с подмножеством библиотек среды выполнения, которые специально предназначены для вашего приложения. Компиляция обычно использует статический анализ приложения, чтобы создать наилучшие возможные выходные данные. Однако термин "лучше всего" может иметь много значений. Иногда можно улучшить выходные данные компиляции, предоставив указания процессу публикации.
Оптимизация размера или скорости
Во время компиляции процесс публикации принимает решения и компромиссы между созданием теоретически наиболее быстрого исполняемого файла и размером исполняемого файла. По умолчанию компилятор выбирает смешанный подход: создает быстрый код, но учитывайте размер приложения.
Пока я не видел чтобы кто-то реально написал на C# кросс-платформенную библиотеку (под 6 платформ человечества), настроил авто-сборку и эта библиотека реально использовалась. Возможно предпосылки к этому уже есть и возможно даже это уже и возможно, но не факт. Хотите быть пионером?
И фишка в том что этот сборщик мусора хотя и удобен, все-таки к умным указателям привыкнуть не так сложно — а практически все стандартные ситуации они покрывают. Ну да, нужно примерно недели две потратить, чтобы разобраться с концепцией перемещения памяти и умных указателей. Но после этого вы поймете что сборщик мусора не так уж важен.
S>>Параметры обрезки S>>Подготовка библиотек .NET для обрезки S>>Можно создать один обрезанный файл (PublishSingleFile) S>>Уменьшаем размер двоичного файла на C# в 90 раз
S>Ни и сколько по итогу получается WASM-модуль?
S>Пока я не видел чтобы кто-то реально написал на C# кросс-платформенную библиотеку (под 6 платформ человечества), настроил авто-сборку и эта библиотека реально использовалась. Возможно предпосылки к этому уже есть и возможно даже это уже и возможно, но не факт. Хотите быть пионером?
А смысл? Смысл прежде всего в кроссплатформенности. Он есть. А вот кроссплатформенные библиотеки это побочный эффект.
S>И фишка в том что этот сборщик мусора хотя и удобен, все-таки к умным указателям привыкнуть не так сложно — а практически все стандартные ситуации они покрывают. Ну да, нужно примерно недели две потратить, чтобы разобраться с концепцией перемещения памяти и умных указателей. Но после этого вы поймете что сборщик мусора не так уж важен.
То есть ты хочешь сказать, что на С++ намного удобнее писать код чем на C#?
Или все таки наоборот? Суть пиши на C# и компилируй в C++. Это удобнее.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>А смысл? Смысл прежде всего в кроссплатформенности. Он есть. А вот кроссплатформенные библиотеки это побочный эффект.
Библиотеки, которые можно использовать из любого ЯП — так же очень важны.
S> То есть ты хочешь сказать, что на С++ намного удобнее писать код чем на C#?
Не, на C# немного удобнее писать. Но это не так чтобы сильно уж критично — может быть 20% разницы, не в разы.
S>Или все таки наоборот? Суть пиши на C# и компилируй в C++. Это удобнее.
Оно того не стоит. Там же еще куча всего добавляется + проблемы. И это не официальная фича от MS.
На C++ есть те же классы, то же наследование. Ну нет сборщика мусора — но смарт. указатели — практически 99% вещей покрывают.
S>>Или все таки наоборот? Суть пиши на C# и компилируй в C++. Это удобнее.
S>Оно того не стоит. Там же еще куча всего добавляется + проблемы. И это не официальная фича от MS. S>На C++ есть те же классы, то же наследование. Ну нет сборщика мусора — но смарт. указатели — практически 99% вещей покрывают.
Угу если было бы так, то питоны, JS и прочие недоязыки не имели бы место на существование.
Как сказал мой коллега перешедший с С++ на C# что последний это детский язык, но очень мощный.
Native AOT это официальная фича от MS. Il2CPP это фича Unity, но они друг с другом взаимодействуют, обогащая друг друга
Опять же учитывая тримминг как раз проще распространять библиотеки на байткоде, уменьшая размер итогового приложения!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Marty, Вы писали:
M>Я только одну платформу встречал, где нет никакого C++ — это MSC-51, а не, вру, ещё лет 15 назад видел пром контроллер на 186ом, под который SDK и тулчейн был на TurboC. Вполен, впрочем, допускаю, что есть ещё какие-то фрические платформы без плюсов
Дело не в том что без плюсов, а с плюсами но более древними чем c++26 короче совместимость и протируемость современного c++(n+1) — так себе и даже хуже.
Здравствуйте, kov_serg, Вы писали:
M>>Я только одну платформу встречал, где нет никакого C++ — это MSC-51, а не, вру, ещё лет 15 назад видел пром контроллер на 186ом, под который SDK и тулчейн был на TurboC. Вполен, впрочем, допускаю, что есть ещё какие-то фрические платформы без плюсов _>Дело не в том что без плюсов, а с плюсами но более древними чем c++26 короче совместимость и протируемость современного c++(n+1) — так себе и даже хуже.
А можно пример? На вскидку, могу припомнить только uVision Keil, в котором оригинальный армовский компилятор был, поддерживал C++11, но либа была от C++03, приходилось бэкпортить std из GCC. Но это ARMCC v5, а ARMCC v6 уже на базе Clang'а, и нормально всё поддерживал.
А так вообще всю встройку на GCC пишут, иногда на Clang'е.
Но лично я по старым привычкам да, отстаю на один-два стандарта от самых последних плюсов
только новый с++, старый не собирает.
