Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use string_view for non-owning string references #2634

Open
oysstu opened this issue Sep 30, 2024 · 3 comments
Open

Use string_view for non-owning string references #2634

oysstu opened this issue Sep 30, 2024 · 3 comments
Labels

Comments

@oysstu
Copy link
Contributor

oysstu commented Sep 30, 2024

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.

@mjcarroll
Copy link
Member

I think since we are C++17, there isn't anything blocking this from a compiler perspective. As you mention, we make pretty heavy use of null-terminated strings in the RCL and RMW layers. Changing that would be invasive, though not impossible.

I wonder if an alternative would be to look into something like this SO Answer suggests and create a zstring_view that allows string_view to be used with null-terminated strings?

@clalancette
Copy link
Contributor

The other thing here is that I've heard a lot of horror stories about the lifetimes of string_view, and how it is super easy to create dangling references (i.e. https://medium.com/@stackyjoe/yet-another-gripe-about-std-string-view-87fe1ee7a45e). So I'd want to make sure we aren't getting into those situations.

@mjcarroll
Copy link
Member

@oysstu is this something that would be potentially interested in prototyping so we could come up with concrete recommendations and identify any issues as @clalancette mentions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants