search

WebAssembly / wasm-c-api

Wasm C API prototype
Apache License 2.0
550 stars 77 forks source link

Consider C++17/20 #60

Open ghost opened 5 years ago

ghost commented 5 years ago

It's unfortunate that the API has chosen very old C++ standard. With C++20 you can construct a module from, say, std::span<const std::byte> and there is no need to reinvent the wheel. Please consider bumping the C++ version.

rossberg commented 5 years ago

This was a conscious decision, since many potential clients still have to operate or build in environments where C++14 availability is the best you can hope for and C++11 is an even safer assumption.

(Also note that std::span is not the same as wasm::vec, since the latter has element ownership associated with it. However, I agree that it is ugly and I'm still considering simpler options.)

ghost commented 5 years ago

Since the module constructor doesn't need to own the bytes you give it to it and just need to read them and convert them to internal representation, std::span is enough. Or does the spec require vec here? Does that mean no support for modules that occupy more than 4 GiB of data on disc?

rossberg commented 5 years ago

Yes, it is indeed true that ownership would not be needed in the case of Module::make, but for most of the other uses of vec.

Not sure I understand your 4 GiB question -- both span and vec use size_t, so the choice shouldn't make a difference regarding possible sizes.

ghost commented 5 years ago

My assumption was that wasm::vec models vec from the spec and spec limits it to 2^32 elements. For that reason it is very hard to use std::vector and I inherited my own class from std::vector to enforce the size invariant. Otherwise, I don't see the point in wasm::vec.

rossberg commented 5 years ago

Ah, no, it has nothing to do with the notion of vec in the spec.