-
Notifications
You must be signed in to change notification settings - Fork 418
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
reserved identifier violation #874
Comments
The ROS 2 code base uses a trailing underscore but no leading underscore so it doesn't match either of the two cases described in the referenced doc. Can you point to a reference why identifiers with a trailing underscore are a violation? |
Are you referring to the double underscore?
The double underscore is being used to make the include guards unique: google/styleguide#78 . It might be a reserved name, but it seems very unlikely conflict since the guards are so long. |
How do you think about to avoid that this software depends on undefined behaviour? |
Just to include the relevant snippet here:
That is a good reason to consider alternatives. Do you have a specific proposal with what the current identifiers could be replaced? |
|
Wouldn't that result in the problem described in google/styleguide#78 which is the reason why we use double underscores as the directory separator?
Using |
I would prefer C++ standard compliant solutions. |
To be clear (I think that's what you're implying) that means no |
We could use |
We have discussed this in today's meeting and agree that the current use two consecutive underscores is undesired since it doesn't follow the spec.
Since the current usage works (even though it doesn't comply with the C++ spec) and we are not aware of any actual problem caused by it we don't see a good enough alternative to switch to. As a consequence we don't plan to make a change to the header guards at the moment. Therefore I will mark the ticket with "wontfix" and go ahead and close it. |
|
I think I have described in details in my previous comment that we would like to have a standard compliant solution which doesn't have real-world drawbacks like collisions. So I am not sure why you are asking these questions. @elfring Please feel free to make concrete proposals. |
I found my suggestion for a better name selection concrete enough. |
Assuming you are referring to your one-line UUID reference please describe with a few more words how you imagine that to be done. |
|
The question is: with what to replace them? Please see my previous comment enumerating all the options we have considered.
Please be more concrete how exactly that process would look like on all the targeted platforms (Linux, macOS, Windows). |
I suggest to take just another look at known approaches to generate unique identifiers (also for include guards). |
Please read the above comments. That case has been explicitly discussed and the problem with that approach pointed out.
Again: please make concrete proposals. Above we iterated over some proposed separators and also argued explicitly why we don't think they are a good solution. |
If you do still not like a single underscore as a simple replacement, you can choose a more pleasing text instead. |
Your comments are not helpful and you are repeatedly ignoring feedback already given. I am sorry but I won't be able to iterate with you on this (without any significant new input). |
It seems to be easier for you to reject extra development efforts for achieving desirable C++ standard compliance. |
I think UUIDs could be a solution we would adopt, but we would need some tools to help our developers and contributors when they are making new headers. Do you have recommendations on such tools? Note, "use editor X" is probably not a good solution, since people will want to use their own editors and not be convinced to switch for such a narrow feature. Maybe there's a website that generates them or something?
@elfring I hope you can see why we feel that this isn't helpful feedback... We did take time out of our weekly meeting to brainstorm ideas and didn't come up with anything better. If you also cannot come up with a better mechanism, then please stop suggesting we pick a different one. It doesn't move the issue forward. |
Signed-off-by: Emerson Knapp <eknapp@amazon.com>
I would like to point out that identifiers like “
RCLCPP_ACTION__QOS_HPP_
” and “RCLCPP__EXECUTOR_HPP_
” do not fit to the expected naming convention of the C++ language standard.Would you like to adjust your selection for unique names?
The text was updated successfully, but these errors were encountered: