arithy
reserved identifier violation
I would like to point out that identifiers like “PCC_INCLUDED__” and “STRING_FLAG__IDENTIFIER” do eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?
Thank you for your advice. I replaced every double underscore __ with a single underscore if it is in an identifier that consists of uppercase letters and underscores. Please check out the branch 'develop'.
Thanks for your renaming of affected identifiers.
:crystal_ball: Can a name selection trigger any corresponding software development concerns?
How do you think about to rename also functions?
I don't want to rename them anymore. I determined the function naming convention like 'class name'__'method name' to distinguish it plainly from other word delimiters '_'.
Can a name selection trigger any corresponding software development concerns?
Sorry, I couldn't understand what you mean. Could you express it more simply?
I don't want to rename them anymore.
This implementation detail can be fine according to the naming convention for the programming language “C”. Can anybody get concerned about remaining risks for undefined behaviour if contents from C files will be treated as C++ source code anyhow?
Could you express it more simply?
Is there a possibility that an identifier will be constructed (together with the prefix “PCC_INCLUDED_”) that does not result in an acceptable include guard?
Identifiers ending with "_t" are also reserved in C++. I see many instances of this in packcc, even in the develop branch. https://stackoverflow.com/a/228797/
I also see "__pcc_in", "__pcc_out", and "__pcc_ctx" in the develop branch, all of which C++ considers to be reserved identifiers due to the leading double underscores.
As @elfring says, C++ has stricter rules than C regarding which identifiers are considered reserved.
Just for C. You can use it with a C++ compiler, but I don't support such usage.
Just because @elfring wanted to use PackCC with C++, I think. I accepted a part of @elfring's suggestion since I thought it had better comply with C++ standard as much as possible. Anyway, I can close this issue if I strictly stand on the specification: just for C.
@elfring, @MaxBarraclough, I'm going to close this issue because of the following reasons:
- PackCC generates a C source code in a
.cfile (not in a file with the C++ extension such as.cpp). - PackCC generates a C header file that can be included from C++ source files with no problem.
- I strongly disagree too vast the identifier pattern that POSIX claims to reserve.
If you have any objection against closing this issue, let me know by the end of this month (Aug. 2022).
:thought_balloon: I became curious if interests could grow further for involved standard compliance aspects.
thought_balloon I became curious if interests could grow further for involved standard compliance aspects.
Why not putting some ads on Youtube instead of violating the scope of this project?
Some development concerns can be tackled together for the programming languages “C” and “C++”, can't they?
I became curious if interests could grow further for involved standard compliance aspects.
It might be just your impression, and isn't persuasive.
Some development concerns can be tackled together for the programming languages “C” and “C++”, can't they?
I never deny using C and C++ together. I already wrote "PackCC generates a C header file that can be included from C++ source files with no problem". The generated C code is callable from C++ codes.