Fix MacOS build for Xcode 16.3

[figueroa1395]

As mentioned in Xcode 16.3 release notes: The base template for std::char_traits has been removed. If you are using std::char_traits with types other than char, wchar_t, char8_t, char16_t, char32_t or a custom character type for which you specialized std::char_traits, your code will stop working. The Standard does not mandate that a base template is provided, and such a base template is bound to be incorrect for some types, which could previously cause unexpected behavior while going undetected.

This affects us indirectly as we use nlohmann/json and they still use std::char_traits, resulting in failed compilation attempt (only for MacOS devs with Xcode16.3) due to the usage of std::vector<std::byte> as an argument of nlohmann::ordered_json::from_msgpack() in our tests.

In this PR, we modify our tests such that this is not an issue anymore.

Note: There was a recent release of the library, but it didn't address this issue.

[TonyXiang8787]

@figueroa1395 did you raise issue at nlohmann/json board?

[figueroa1395]

@figueroa1395 did you raise issue at nlohmann/json board?

I haven't, but I will. I will post here when I do.

[mgovers]

Converted back to Draft because not all issues have been resolved yet. Sustainable solution will take a bit longer.

[figueroa1395]

Issue created in nlohmann/json#4756

[TonyXiang8787]

@mgovers @figueroa1395

If I understand correctly, we just need to change from std::vector<std::byte> to std::vector<char> in the following line, the problem is going away right?

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Line 84 in fc123b3

std::vector<std::byte> msgpack_data{};

[figueroa1395]

@mgovers @figueroa1395

If I understand correctly, we just need to change from std::vector<std::byte> to std::vector<char> in the following line, the problem is going away right?

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Line 84 in fc123b3

std::vector<std::byte> msgpack_data{};

@TonyXiang8787 Yes, and that was my first quick and naive solution. However, if we just do that, I think we would be taking a step back. At the CPP API level we should be able to use std::byte when handling raw data, not just go back to char which can also be used for characters or even numbers.

Apparently there is someone interested in implementing a PR to solve my issue in nlohmman/json, so we can just wait a bit more there. In any case, I'll be giving my input as well. I just didn't have the time to do the PR myself.

[TonyXiang8787]

@mgovers @figueroa1395
If I understand correctly, we just need to change from std::vector<std::byte> to std::vector<char> in the following line, the problem is going away right?

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Line 84 in fc123b3

std::vector<std::byte> msgpack_data{};

@TonyXiang8787 Yes, and that was my first quick and naive solution. However, if we just do that, I think we would be taking a step back. At the CPP API level we should be able to use std::byte when handling raw data, not just go back to char which can also be used for characters or even numbers.

Apparently there is someone interested in implementing a PR to solve my issue in nlohmman/json, so we can just wait a bit more there. In any case, I'll be giving my input as well. I just didn't have the time to do the PR myself.

@figueroa1395 @mgovers
We do not have to change the CPP API. But just cast the pointer to char const*. It will then solve the problem. So change the lines:

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Lines 84 to 86 in edc1018

	std::vector<std::byte> msgpack_data{};
	msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
	auto const json_document = nlohmann::ordered_json::from_msgpack(msgpack_data);

To:

                std::vector<std::byte> msgpack_data{};
                msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
                auto const char_start = reintepret_cast<unsigned char const*>(msgpack_data.data());
                auto const char_end = char_start + msgpack_data.size();
                auto const json_document = nlohmann::ordered_json::from_msgpack(char_start, char_end);

[figueroa1395]

@mgovers @figueroa1395
If I understand correctly, we just need to change from std::vector<std::byte> to std::vector<char> in the following line, the problem is going away right?

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Line 84 in fc123b3

std::vector<std::byte> msgpack_data{};

@TonyXiang8787 Yes, and that was my first quick and naive solution. However, if we just do that, I think we would be taking a step back. At the CPP API level we should be able to use std::byte when handling raw data, not just go back to char which can also be used for characters or even numbers.
Apparently there is someone interested in implementing a PR to solve my issue in nlohmman/json, so we can just wait a bit more there. In any case, I'll be giving my input as well. I just didn't have the time to do the PR myself.

@figueroa1395 @mgovers We do not have to change the CPP API. But just cast the pointer to char const*. It will then solve the problem. So change the lines:

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Lines 84 to 86 in edc1018

	std::vector<std::byte> msgpack_data{};
	msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
	auto const json_document = nlohmann::ordered_json::from_msgpack(msgpack_data);

To:

                std::vector<std::byte> msgpack_data{};
                msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
                auto const char_start = reintepret_cast<unsigned char const*>(msgpack_data.data());
                auto const char_end = char_start + msgpack_data.size();
                auto const json_document = nlohmann::ordered_json::from_msgpack(char_start, char_end);

I implemented it in c3609a8. I'm fine with this local fix here until nlohmann/json#4756 is addressed and released. @mgovers any thoughts?

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[mgovers]

@mgovers @figueroa1395
If I understand correctly, we just need to change from std::vector<std::byte> to std::vector<char> in the following line, the problem is going away right?

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Line 84 in fc123b3

std::vector<std::byte> msgpack_data{};

@TonyXiang8787 Yes, and that was my first quick and naive solution. However, if we just do that, I think we would be taking a step back. At the CPP API level we should be able to use std::byte when handling raw data, not just go back to char which can also be used for characters or even numbers.
Apparently there is someone interested in implementing a PR to solve my issue in nlohmman/json, so we can just wait a bit more there. In any case, I'll be giving my input as well. I just didn't have the time to do the PR myself.

@figueroa1395 @mgovers We do not have to change the CPP API. But just cast the pointer to char const*. It will then solve the problem. So change the lines:

power-grid-model/tests/native_api_tests/test_api_serialization.cpp

Lines 84 to 86 in edc1018

	std::vector<std::byte> msgpack_data{};
	msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
	auto const json_document = nlohmann::ordered_json::from_msgpack(msgpack_data);

To:

                std::vector<std::byte> msgpack_data{};
                msgpack_serializer.get_to_binary_buffer(0, msgpack_data);
                auto const char_start = reintepret_cast<unsigned char const*>(msgpack_data.data());
                auto const char_end = char_start + msgpack_data.size();
                auto const json_document = nlohmann::ordered_json::from_msgpack(char_start, char_end);

I implemented it in c3609a8. I'm fine with this local fix here until nlohmann/json#4756 is addressed and released. @mgovers any thoughts?

Ok!

[figueroa1395]

@mgovers @TonyXiang8787 FYI: The issue I created relevant to this has already been closed as completed via nlohmann/json#4760. Now we have to wait until they make their next release. Since that may take very long, should I create a simple issue here to keep track of it for once it gets released on nlohmann/json's side?