Skip to content
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

.H file extension being counted as C Header file Instead of C++ Header file. #574

Open
srmfx opened this issue Jan 17, 2025 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@srmfx
Copy link

srmfx commented Jan 17, 2025

Describe the bug
.H filename extensions aren't counted as C++ Header files, 'scc' instead counts it as a C Header file.
At least on GCC Manual (Man Pages), C++ can have .H and .HPP as header filename extension along with these other following file extensions: .hh, .H, .hp, .hxx, .hpp, .HPP, .h++, .tcc

On a further note, the inner contents of the .H header files I have are just class definitions with '#define' preprocessor directive surrounding them.

To Reproduce
To reproduce this issue, have C++ source and header files with .CPP and .H extensions respectively and type:
scc ./source/*

Image

Expected behavior
Scc should count .H and other C++ header filename extension as C++ Header File in the result screen instead of saying it's a C Header file.

I've not checked yet, but it's very likely that this issue is also plaguing other filename extensions for C/C++.

Desktop:

  • OS: Archlinux
  • Kernel: 6.12.9-zen1-1-zen
  • SCC Version: 3.4.0
  • GCC Version: 14.2.1 20240910
@boyter
Copy link
Owner

boyter commented Feb 5, 2025

Yeah.... so the problem is the sharing of the extension.

Most languages identified have a unique extension. Where this is not the case scc will look at the first 10,000 bytes checking for keywords which would indicate which language it is.

Now in this situation I don't know if its possible to do this because my understanding is that they will look almost the same between C and C++ (correct me if I am wrong here please).

Its possible I could add in logic that checks if files around it are C++ and changes the header type based on that... although thats not going to be an easy tweak.

Another option is the proposed addition of dotfile support where you can add remaps such as .h to always be cpp headers or vice versa by adding in the --count-as option. You could of course use this now if that helps achieve your goals.

Ill have more of think on this though.

@boyter boyter added the enhancement New feature or request label Feb 5, 2025
@srmfx
Copy link
Author

srmfx commented Mar 8, 2025

Now in this situation I don't know if its possible to do this because my understanding is that they will look almost the same between C and C++ (correct me if I am wrong here please).

Its possible I could add in logic that checks if files around it are C++ and changes the header type based on that... although thats not going to be an easy tweak.

I'm not sure if this could be easily achieved, but one way to do this is to assume a header file(.h or .H) is C++ code if and when it contains one or more class definition.

#ifndef EXAMPLE_CLASS
#define EXAMPLE_CLASS
class ExampleClass{
          public:
                       ExampleClass();
                       MethodA();
         private:
                       MethodB();
};
#endif

Just in case you need help understanding it, the #ifndef and #define preprocessor keywords allows the compiler to declare the class definition only one time, so this way other classes can include this same class header file without compiler issues, otherwise you'd get same class definition errors everywhere the header file is included.

In this case, #ifndef is considered a C Preprocessor and along with the Class keyword this would make it an hybrid C/C++ Code.

Maybe just looking for the keyword 'class' should suffice in classifying it as C++,
And if it has keywords from C, then this would make it an hybrid C/C++.

No idea how feasible this would be.

@srmfx srmfx closed this as completed Mar 8, 2025
@srmfx srmfx reopened this Mar 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants