Use ".h" suffix for header files

[tkem]

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-file-suffix

[degski]

So it says (a.o.): "... Headers are more often shared with C to compile as both C++ and C, which typically uses .h, and it’s easier to name all headers .h instead of having different extensions for just those headers that are intended to be shared with C...".

You seem optimistic, but I don't think my c-compiler is gonna like fsmlite (and that's what the above assumes). You could write a number of free C-functions (init, destroy, whatever), passing the instance as the first parameter of the free functions (i.e. extern "C" C-style classes, the same way it works in C++, but in the C-context visible, not hidden)), to provide this functionality in C. For that header you should use the .h extension, .hpp is the way to go for the C++ API, as fsmlite is not a std:: lib yet.

[tkem]

Well your C compiler wouldn't like fsmlite if you wrote #include <fsmlite.hpp> in a C program either, so that's irrelevant. Though it might be debatable, I decided to follow the Core Guidelines unless there's really good reason not to - which in this case, I think there's not.

[degski]

"Well your C compiler wouldn't like fsmlite if you wrote #include in a C program either, so that's irrelevant."

If the header has the extension .hpp, I wouldn't try to include it in a C-source file (that's the relevance), because it screams at me that it's a C++ header. You're NOT following the core guidelines. The premise in the CGL is: "... Headers are more often shared with C to compile as both C++ and C ...". Your C++ header will NEVER EVER compile in C, so the CGL does not apply (in respect of this issue).

[tkem]

As it states, "it’s easier to name all headers .h instead of having different extensions for just those headers that are intended to be shared with C". Anyway, this issue is closed - you're flogging a dead horse.