0

I have two short files located in the same directory. The contents of each are shown below.

  • File test.cpp contains:

    int main()
    {
        #include <test.h>
    }
    
  • File test.h contains:

    syntax_error
    

Upon compiling test.cpp with either g++ or clang++, I get an error which is expected.

test.cpp:3:11: error: 'test.h' file not found with <angled> include; use
  "quotes" instead
    #include <test.h>
             ^~~~~~~~
             "test.h"

However, I also get a second error which seems to contradict the first error.

In file included from test.cpp:3:
./test.h:1:1: error: use of undeclared identifier 'syntax_error'
syntax_error
^

Essentially, the first error reports that the compiler cannot find the file test.h, and the second reports a syntax error in the file that the compiler reported it could not find.

These are the only two errors generated.

I understand why the compiler reports the first error and that I should use quotes with #include in this case. Why, though, does the compiler say it cannot find the file when it clearly has found it? And, why would it continue to report errors in the "unfound" file?

Grayscale
  • 1,462
  • 1
  • 13
  • 20
  • 1
    First message is quite plain: It is saying, "I found it, but in the wrong spot. Use the quotes, Luke." Looks like you accidentally used `<>`. – user4581301 Aug 18 '17 at 18:17
  • 1
    Related: [What is the difference between #include and #include “filename”?](https://stackoverflow.com/questions/21593/what-is-the-difference-between-include-filename-and-include-filename) – user4581301 Aug 18 '17 at 18:20
  • Thanks for the links, though I am familiar with the difference between `include – Grayscale Aug 18 '17 at 18:23
  • Not curious. `<>` has implementation defined behaviour. This particular implementation also looks in the local folder and is kind enough to tell you that your program is non-compliant, why, and how to fix it, and then heads off to find more errors. – user4581301 Aug 18 '17 at 18:26
  • 1
    If you read more carefully, the message doesn't say that the file wasn't found, it says that it couldn't be found in one of the `<>` search paths. If it couldn't be found at all, you'd get a different message. – molbdnilo Aug 18 '17 at 18:27
  • Actually yeah this does seem like logical behavior, and the point by @molbdnilo that the compiler states `file not found *with include*` resolves my initial confusion about the wording. – Grayscale Aug 18 '17 at 18:31

1 Answers1

3

This is a feature, not a bug.

The idea is that if the error is trivial (like a missing semicolon), then the compiler will try to continue compiling as if you had already fixed the error. This enables you to fix multiple errors in one go. This is especially useful when compiling your code takes a long time.

Imagine fixing a missing semicolon, recompiling for five hours, just so that the compiler finds another missing semicolon. And then you have to recompile again. That would be very frustrating, no?

Basically, the compiler will try to recover from any errors as far as it is able to, to be able to report as much errors as possible. Most compilers have a flag for this.

Why, though, does the compiler say it cannot find the file when it clearly has found it?

The compiler found the file yes, that's why it gave you a hint to use "" instead of <>. If it hadn't, it might not have given you the hint. Still, the compiler is not allowed to compile your code correctly, because your code is ill-formed.

As an analogy, just because the compiler found a missing semicolon, that doesn't mean that it can just compile the code with that missing character (if it tries to be Standards compliant). It will however recover and try to find other errors, if any.

Rakete1111
  • 47,013
  • 16
  • 123
  • 162