You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the API uses const std::string & for non-owning references to strings (e.g., topic names, node names). A more modern solution would be to use string_view. String constants can be declared as string_view in a header without initializing them in every translation unit. They are also constexpr, which can potentially open up some compile-time usage.
Feature description
The blocker for implementing this right now is that the rcl layer expects null-terminated strings. It's not possible to know if the byte following the string_view buffer is a null byte or simply uninitialized memory, so one would have to copy the data to a string anyway.
Right now, I don't see how this is viable without modifying the rcl API to accept string + length parameters. I thought I'd make the issue regardless, as from a pure C++ API standpoint, using string_views would perhaps be better.
The text was updated successfully, but these errors were encountered:
Feature request
Currently, the API uses
const std::string &
for non-owning references to strings (e.g., topic names, node names). A more modern solution would be to use string_view. String constants can be declared as string_view in a header without initializing them in every translation unit. They are also constexpr, which can potentially open up some compile-time usage.Feature description
The blocker for implementing this right now is that the rcl layer expects null-terminated strings. It's not possible to know if the byte following the string_view buffer is a null byte or simply uninitialized memory, so one would have to copy the data to a string anyway.
Right now, I don't see how this is viable without modifying the rcl API to accept string + length parameters. I thought I'd make the issue regardless, as from a pure C++ API standpoint, using string_views would perhaps be better.
The text was updated successfully, but these errors were encountered: