WASMは低レベルの仮想マシンであるため、バイナリ配列として表される文字列を処理できる必要があります。
.fromUTF8と.toUTF8の便利なメソッドがあります: https :
ただし、これらは3つの点で非対称です。
fromUTF8
は文字列の長さの知識を必要としますが、 toUTF8
はその値を返しません。 lengthUTF8
個別に呼び出す必要がありますが、これは無駄です( toUTF8
すでに呼び出されています)fromUTF8
は文字列内の\0
ユニコード文字を正しく処理しますが、 toUTF8
はこれらがサポートされていないという印象を与えますfromUTF8
は、エンコードされた文字列の純粋なサイズ(バイト単位)が必要ですが、 lengthUTF8
は、バイトパディングがゼロのサイズを返します。 既存のテストでさえ、それを明示的に調整する必要があります: //github.com/AssemblyScript/assemblyscript/blob/b7e7be20cfe2d35c689d7927ee0e4207a443bb6f/tests/compiler/std/string-utf8.ts#L24これは非効率的で紛らわしいアプローチです。 AssemblyScriptの目標が高レベルのWASMに適した言語になることである場合、nullで終了する文字列への裸のポインタのようなC-ismを標準ライブラリに含めることは、それらの目標に反するように感じます。
私の提案は、.lengthUTF8と.toUTF8の名前を.lengthUTF8ZeroTerminated、.toUTF8ZeroTerminatedに変更し、正しいコンテンツとサイズが入力されたArrayBufferを返す.toUTF8Bufferを導入することです。 このAPIは、ユーザーにとってはるかに明確で便利です。
別の解決策は、次のような基本タイプを導入することです。
class MemSlice {
constructor(readonly offset: usize, readonly length: usize) {}
...
}
これは一般的に非常に便利です
同意しましたが、これらのAPIは理想的ではありません。 それらを文字列クラスから、特に相互運用を対象とするもの(Cを使用)に移動することも理にかなっているかもしれません。
このPRではUTF8 / UTF16APIが改善されました
最も参考になるコメント
別の解決策は、次のような基本タイプを導入することです。
これは一般的に非常に便利です