reserved identifier violation about openpose

[NyaMisty]

Hi Markus,

In fact, that identifier does not has any special meaning, and is autogenerated by the IDE or other tools. It is only used to prevent that header from being processed for more than once, and it won't be in the final executables. So we needn't change it at all.

[elfring]

How do you think about to avoid that this software depends on undefined behaviour?

[gineshidalgo99]

Hi @elfring, I am interested in following the naming convention of the C++ language standard. But I have a question after reading your links. How is OPENPOSE__CORE__RENDERER_HPP not fitting the naming convention? In the link you sent me I just found not to use underscores at the beginning/end and not to repeat names used in the std library. Thanks!

[elfring]

I recommend to reconsider the use of double underscores here according to the rules of the C++ programming language.

[gineshidalgo99]

@elfring OK! I will remove it within this week. Thanks! Given your better experience, may I also ask you how would you distinguish between separating folders (I was using double underscores) and separating Upper case letters (I was using single underscore)? I did not find a standard way to do it so far. Thanks!

[elfring]

I was not concerned about a name selection for folders in this use case. I am curious if some C++ identifiers (like affected include guards) will be adjusted.

[gineshidalgo99]

The include guards have been changed for the next release (1.0.0rc3) by changing __ by _. I am still finishing some other small issues, and then I will commit and push everything at the same time. But it should be done by this week.

[gineshidalgo99]

@elfring Thank you again for your demanding feed-back and recommendations. __ were removed in our last commit (BTW we also added face).

Please, feel free to post any other naming rule not followed or recommendations you might have.

[elfring]

Did you publish corresponding changes in a separate commit?

[gineshidalgo99]

No, it was a common commit with other changes. We were quite in a hurry at that moment and did it this way, but you are completely right and we should avoid doing that. Thanks