Я вам рекомендую посмотреть: как реализуются компараторы на c; каким образом происходит чтение/запись файла на c/c++ - Все там кастуется именно по такой схеме.
В шарпе майкрософт сделал другой однобайтовый тип и назвал его bytes.
Вы еще может считайте, что в шарпе вы напрямую с физической памятью работайте?)
Вот что говорит чат по этому поводу:
В других языках программирования, таких как Python, Java, JavaScript и Ruby, тип данных `char` обычно используется для представления символов, а не байтов.
Например, в Python тип данных `char` не поддерживается, вместо этого для представления символов используется тип данных `str`.
В Java и C# тип данных `char` представляет собой 16-битное беззнаковое целое число, которое используется для представления символов в Unicode.
В JavaScript и Ruby тип данных `char` не поддерживается, вместо этого для представления символов используется тип данных `string`.
Таким образом, в большинстве языков программирования тип данных `char` используется для представления символов, а не байтов. Однако, в некоторых языках, таких как C/C++, `char` может использоваться для представления байтов.
Только потому что в C он занимает 1 байт, и автоматически кастуется в uint8, и фактически равен ему, для универсальности используют его. Правильнее сказать, что там тоже нет отдельного char, а есть именно byte, который назван
А в других языках иначе.
Напрямую с памятью только ассемблер работает.
В остальном абстракции.
Я не говорил, что чары хранятся в памяти, я говорил, что к ним кастуются. В принципе разницы нет, как будет называться однобайтный тип.
Числа от 0 до 255 соотвествуют кодировке символов - все верно.
Char в шарпе, сугубо мое мнение, решили сделать двубайтным из-за типа bytes, чтобы явно показать разработчику, мол, хочешь передавать/сохранять данные используй bytes. И вроде бы и удобно должно быть, а вроде и упоранство какое-то.
char 2 байта потому что это utf16, что бы любой символ обрабатывать универсально.
И ничего более.
Никто данные для передачи не кастует в char. И нигде байты не называются char. Это отдельный именно текстовый тип, и что бы отправить его по сети, нужно всё равно перевести char в byte, он же uint8
Это происходит только ну низком уровне хранения именно типа char, который предназначен для хранения символов.
Это c/c++. Минимально адресуемая ячейка памяти это 1 байт, а размер чара как раз таки и равен 1 байту.
А так называемые, с ваших слов, нормальные языки, очень часто используют библиотеки, которые изначально были написаны на си (python например), которые и осуществляют преобразования типов к типу чар, а если еще быть болле точным там кастуются указатели.
Кстати, на каком вы языке передачу данных реализуете?
Это библиотека на C#, и всё остальное тоже на нём.
И char у нас это 2 байта.
Это в простой кодировке был бы один, и везде это отдельный от byte тип.
Даже в питоне есть bytes, но она легко преобразует в string, и даже есть тип bytestring
Поэтому может показаться, что они хранятся в чарах.
На самом деле чаще отображаются переводя в чары.
Но можно и в числах, от 0 до 255
Просто чар в простой кодировке тоже имеет размер 1 байт.
Но передаются и хранятся в памяти байты, а не чары.
Значит касты у вас внутри библиотеки, т.к. чтобы считывать по байтам нужно кастовать в чару.
Это какой язык?
Как бы все данные в байтах хранятся, а не в чарах.
И все нормальные языки умеют обращаться к памяти. Никаких кастов, тем более чаров.
Это что то прямо очень старое. Может PHP?
Думал, что это открытая спека, как мсгпак
Просто недавно реализовывал мсгпак на плюсах, ибо в наш целевой дистриб не завезли..
У меня других языков на сервисах пока не планируется.
Только JSON на своём уровне реализую, скорее через встроенный хватит. Для хранения в БД, без привязки к очерёдности полей, и удобного частичного чтения.
Даже самый сложный клиент использует 3D библиотеку Veldrid, потом вероятно перейду на Silk.Net
Все потребности покрываются, никакого Легаси.
Если будет нужно другие языки подключить, то только маршалингом как модуль к программе.
Что бы проверить работу именно моей системы.
Тестируется не между серверами, а вообще приём-передача байтов.
Что бы состояние передавалось в состояние другого объекта уже в конечные структуры или методы.
И вообще в коде не знать о существовании сетевого уровня.
А иметь объекты представляющие удалённые устройства и объекты.
Быстрее, но за счет постоянной длины.
Нет рефлексии, можно компилировать новым методом, AOT или как его.
Поищите по memorypack vs messagepack
Это же один разработчик сделал.
MemoryPack новее и устраняет недостатки. Но и немного другая специализация.
А мой уровень, генерирует классы, реализующие RPC двустороннюю с уведомлениями.
Что бы был объект, когда в нём меняешь свойство, он отправляет пакет данных на связанный на другой стороне объект, и оно меняется там, и вызывает OnChanged
И методы вызываются удалённо, вместе с возвратом результата.
Внутри общаясь структурами MemoryPack
Пишу просто класс как обычно, на другой стороне реализую методы, и на свой стороне достаточно вызвать метод, а вся сетевая часть уже написана автоматически.
На каждое свойство и метод в среднем около 20-30 строк обслуживающих генерируется.
И не нужно писать вручную например . on("eventname", ()=>{})
Или switch для типов команд.
Между чем угодно, хоть сервер и клиент, хоть сервер сервер, хоть клиент клиент.
В основном конечно между серверами и приложениями.
В отличии от protobuf, не нужно отдельный файл с заголовками для простых структур.
А для своего слоя в любом случае нужен другой класс наследуемый от репликации, и создаётся совсем отдельный. А заголовочный скрывается. Как и в protobuf.
