.h C++ header recognized as C header

[chfast]

C++ headers can have *.h file extension. Can some additional heuristic be applied to recognize C++ headers from C headers. E.g. checking if class keyword is used in the file.

I'm willing to fix that, but I don't know where to start. I've scanned the source but the package is quite declarative. Where can I find logic behind language recognition?

[winstliu]

All .h headers are now identified as C++ rather than C, which should give better highlighting in most cases.

[boazsegev]

This update produces syntax error notification when the .h file is a C header.

For example, C does not define char16_t as an internal type, which means that a types.h file will need to define it (i.e. typedef unsigned short char16_t), which raises an error in C++ but is valid in C.

The issue is worst when using inline functions in C headers (which is important for some performance optimizations), since void * casting is legal in C and illegal in C++...

I understand that C++ is prevalent, but C developers are made to suffer unless a better heuristic / control flow is provided.

[winstliu]

This package only provides syntax highlighting, so another community package is causing the syntax error notifications that you're experiencing. You can define custom file types by following this FAQ.

[boazsegev]

@50Wliu ,

I am thankful for the package and for the Atom development environment.

However, I hope you could consider my point of view.

Please consider that this might not be a specific project that is affected, but rather a whole community convention that is questioned.

This syntax highlighting issue was resolved by changing the association of *.h files from C to C++, even though C++ specific headers are often differentiated from C header files by the use of the *.hpp extension (this change signals that they are not compatible with C).

It's true that *.h files are used for both C and C++, but the assumption here is that they allow for certain functionality to be available from both languages and that *.h files should be C header files or C compatible header files.

It's true that I can keep writing project specific configuration files for every project I handle... but I believe that the community convention should be the norm rather than the exception to the rule.

[winstliu]

It's true that I can keep writing project specific configuration files for every project I handle

The FAQ entry I linked you to is global, not project-specific. Here is @thomasjo's comments on this: #156 (comment)

[boazsegev]

Hi @50Wliu , thanks for the quick reply.

Three points to think about:

1. The historical merger and comments were all about syntax highlighting. At the time I read about the upcoming change and didn't think it might effect me. I didn't care if some keywords are mis-highlighted. In fact, I thought it would make compatibility (where needed) easier to maintain.

   However, time had proven me wrong, since other packages are effected (i.e. lint, clang-format) and I constantly get reports regarding "errors" that don't really exist.

2. I notices that global solutions don't work so well and they cause inadvertent effects to different projects. Also, people who collaborate on a project don't share a global state, but they do get confused with these C vs. C++ errors... meaning it's important to maintain an optimal setting for each shared project rather than an optimal private environment.

3. I am very thankful for this project. I am only discussing this because I think it's for the benefit of everyone to revisit this change, especially now that time and experience exposed some issues and effects that weren't as clear at the time.

Thank you for your consideration.

[winstliu]

Ok, can you please open a new issue? While there's not much we can do about it short-term except to revert the PR, it'll still help to serve as a reminder when we have more capable tools to deal with this.

[boazsegev]

Done. I opened issue #204 to both explain and remind.

By the way, although heuristic recognition might be nice to have, the highlighting issue could be simply resolved by being opinionated about the use of a C++ specific extension, such as .hpp... since .h headers are meant to be used by both languages, it's possible that supporting language specific features is counter productive (just a thought).