Здравствуйте, 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'е.
Но лично я по старым привычкам да, отстаю на один-два стандарта от самых последних плюсов
короче совместимость и протируемость современного c++(n+1) — так себе и даже хуже.
