I have not tested the new functions yet. I am also unsure of what change_endianness_utf16 should return. Could it just be a void function? For now, it returns something silly.

I am also unsure of what change_endianness_utf16 should return. Could it just be a void function?

Definitively. I think it should return void.

@NicolasJiaxin This code looks very good to me. I just think that we ought to test it (at least minimally).

I added all tests and I did have a few bugs. But it is all working now, except that the debug tests on Visual Studio are getting stuck and I don't know why.

I added all tests and I did have a few bugs. But it is all working now, except that the debug tests on Visual Studio are getting stuck and I don't know why.

Let me investigate.

@NicolasJiaxin When you do (for example)

    std::vector<char16_t> utf16be;
    utf16be.reserve(size);
    implementation.change_endianness_utf16(utf16le, size, utf16be.data());

You will have that utf16be.size() is zero. Your code is technically unsafe. The reserve call is just an optimization hint, it may not allocate the memory the way you think (though it will in practice).

So you want to go through and do the following...

    std::vector<char16_t> utf16be(size);
    implementation.change_endianness_utf16(utf16le, size, utf16be.data());

That should solve the issue. You can also replace reserve with resize.

Note that your code is 'practically correct' but memory checkers might complain so better fix it.

One problem with using std::vector is that the input is guaranteed to be zeroed. If you'd want to avoid that... You could also do the following...

std::unique_ptr<char16_t[]> utf16be_unique(new char16_t[size]);
char16_t * utf16be = utf16be_unique.get();
implementation.change_endianness_utf16(utf16le, size, utf16be);

But I am not sure what the benefit would be.

Ahh, thanks!

@NicolasJiaxin Try adding some bits of documentation to the README. And then I think we will merge.

Great stuff. Merging.