profile
viewpoint
Amund Desmarais Daspien27 Canada

Daspien27/CrazyEights 0

Trying to make use of as many modern c++ features as I can.

Daspien27/DelegateEvent 0

based off of C# example by Thomas Pryde

Daspien27/ModernCppOpenGL 0

Testing CPP RAII and Design Patterns in OpenGL

Daspien27/Set-Solver 0

Solver for the card game "Set"

Daspien27/sqlite_wrapper 0

An easy-to-use, extensible and lightweight C++17 wrapper for SQLite

issue commentheroiclabs/nakama-cpp

Nakama::opt::optional performs unexpected conversions when compiling with different C++ language standards

Thanks for report of the error. We will try to resolve it. By now I propose two solutions:

  1. build nakama-cpp with same C++ standard. Open nakama-cpp\src\CMakeLists.txt, line 63 and set C++20:
target_compile_features(nakama-cpp PUBLIC cxx_std_20)
  1. use nakama-cpp as shared library https://github.com/heroiclabs/nakama-cpp#use-as-dynamic-library

Opting to modify CMakeLists is more in line with my goals, and I can verify the incorrect behavior resolves.

Thanks for looking into resolving this error!

Daspien27

comment created time in 2 months

issue openedheroiclabs/nakama-cpp

Nakama::opt::optional performs unexpected conversions when compiling with different C++ language standards

With further investigation, I can confirm it is due to misaligned language standards. By changing my project from C++latest to C++14 Nakama::opt::make_optional aligns with the nonstd::optional_lite::optional class.

This is unfortunate that the nakama-cpp headers changes types depending on the language version. I think a potential fix would be to provide the two optional class interfaces in parallel (introducing a std::optional when available) or to just commit to a more hardened Nakama::NOptional type that could potentially allow conversions with nonstd::optional_lite::optional or std::optional.

Originally posted by @Daspien27 in https://github.com/heroiclabs/nakama-cpp/issues/24#issuecomment-633558997

created time in 2 months

issue commentheroiclabs/nakama-cpp

[NRtClient::onTransportMessage] NRtError: BAD_INPUT

With further investigation, I can confirm it is due to misaligned language standards. By changing my project from C++latest to C++14 Nakama::opt::make_optional aligns with the nonstd::optional_lite::optional class.

This is unfortunate that the nakama-cpp headers changes types depending on the language version. I think a potential fix would be to provide the two optional class interfaces in parallel (introducing a std::optional when available) or to just commit to a more hardened Nakama::NOptional type that could potentially allow conversions with nonstd::optional_lite::optional or std::optional.

stonekase

comment created time in 2 months

issue commentheroiclabs/nakama-cpp

[NRtClient::onTransportMessage] NRtError: BAD_INPUT

I am experiencing this problem after building nakama-cpp by myself (as the original binaries were giving the same issue). I can verify the addMatchmaker and listMatches calls actually appear to have the same issues with their min, max [and query] Nakama::opt:optional parameter types. I am working with x64.

In certain cases I even encounter an access violation.

StackIssue

I have not tried dynamic linking yet.

Here is a watch window of the parameters inside addMatchmaker: Watches

I initialized the min and max both to be 2, but yet we see garbage in them at this point. We can see the query is "*" but after the operator* it will seemingly pass garbage values as well.

The best conclusion I have come up with so far is that the C++ language both projects are being built in are different (C++latest in my project) because I pass my optionals using Nakama::opt::make_optional (which resolves to std::make_optional) going into the function, but the stack shows they are passed into a function taking nonstd::optional_lite::optional which would explain why the pointers end up becoming garbage.

stonekase

comment created time in 2 months

more