Comments 8
const WasmModule = require(path.join(__dirname, '..', 'build', 'native.example.js'));
Лучше сразу преобразование кода в модули делать. Потом меньше проблем с подключением будет.
Как ни крути, а очень важна возможность использовать либы на всех платформах. У меня для C++ есть готовые проверенные CMake -файлы, чтобы собирать код сразу под: Windows, Linux, MacOS, Android, iOS и WASM. Сразу 6 платформ, к которым пришло человечество на текущий момент существования. И будет работать везде.
Чем-то аналогичным может похвастаться не так много ЯП. Голый C слишком не удобен, все равно там колхозят ООП на основе универсального указателя void*, что весьма неудобно. Rust вроде бы хорош, во многом прогрессивнее C++ - но не имеет удобного и привычного всем ООП-стиля, а то что имеет - не так удобно. Т.е. пока преимущества Rust не покрывают его недостатки.
У rust во много раз круче ооп, чем в cpp, но там другая проблема - программист по умолчанию макака, и это забота программиста доказать компилятору обратное.
Ну что значит "круче"? В смысле сложнее что-либо там реализовать и сложнее разобраться и если ты смог написать ООП на Rust - то ты крут среди пацанов? Ну может разве что в таком смысле. А так давайте на конкретно на примерах посмотрим:
Пример на CPP: https://www.programiz.com/online-compiler/1FWx2dzzP9GFe
То же самое на Rust: https://www.programiz.com/online-compiler/52EHKtXHVfGnO
В Rust даже на таком маленьком примере - куча бойлерплейт-кода. Понятно что и на голом C можно писать ООП, но там бойлерплейта еще больше.
ООП нужен, он используется, его используют. Во всех популярных языках - Java, C#, C++, TypeScript, отчасти JS, Dart - ООП есть и реализован примерно схожим образом. Это классические инкапсуляция, наследование, полиморфизм.
Вы можете полюбить Rust и как бы себя убеждать - ну нет, давайте условно примем что в нем хотя и нет уровней доступа, нет удобного наследования - убедим себя что это кручено. Нет, не круче.
Как передавать булево значение
Тут всё просто - один байт с нулем или единицей:
OMG. Зачем так? Что мешает передать bool как i32 с нулем или единицей, зато без дополнительных аллокаций?
Создадим структуру в С++
Я подозреваю что в зависимости от размеров полей компилятор может применить паддинг (выравнивание), и между полями структуры могут оказаться "дырки" без значений. Это нужно учитывать при заполнении структуры со стороны JS, либо использовать всякие pragma чтобы объявить структуру как packed.
Что мешает передать bool как i32 с нулем или единицей, зато без дополнительных аллокаций?
Привет, потому что нужно было показать саму возможность такого типа.
между полями структуры могут оказаться "дырки" без значений
Делал много примеров перед статьей и с таким не сталкивался ни разу и сказать не могу
Вот тут подробно расписано: http://www.catb.org/esr/structure-packing/
Если компилятор выравнивает по четырем байтам (учитывая что в wasm минимальный тип 32-битный), то есть вероятность что паддинг может произойти даже от структуры типа { char, int } или { short, int } там после первого поля будет дырка в три или два байта размером. А может и не будет, зависит от того выравнивает ли компилятор данные для этого конкретного таргета.
А может и не будет, зависит от того выравнивает ли компилятор данные для этого конкретного таргета
Обычно сложные типы передают туда-сюда как JSON, если нет особых требований по скорости. Или как массив байт типа uint8_t, там тоже дырок не будет.
А так да, согласен - даже если работает сейчас - не факт что будет работать потом.
Как построить мост между JavaScript и C++ через WASM, или гайд для самых маленьких