What is the difference between these two sentence:( <> and " ")?
#include <rtl.h>
#include "rtl.h"
When you use <> the compiler looks in the compilers standard include directories.
When you do "" it first looks relative the current directory.
You should use "" for your include files and <> for header files supplied with the compiler.
By the way - this is documented in any book about C/C++ programming and also in the language standard. I recommend that you get a good book to read. When done, then get the official language and use as a reference.
It's actually implementation defined, not mandated by the standard. The OP should consult the Keil documentation.
Yes. #include "xxx" is defined by the standard to first do one implementation-defined search, and if that fails a new attempt is made - this time using the rules for #include <xxx>.
The standard really has to be that vague since we once had MS-DOS 1.0 that didn't even had subdirectories. And an OS isn't even required to have a tree structure.
But the important thing is that no modern compiler will not perform an initial search in the current directory when seeing #include "xxx". The open issue then is if the current directory is the directory where the compiler was started, or the current directory where the source file was. Some compilers first tries the directory where the source file was, and then the directory where the compiler was started.
No, they are both implementation defined.
But the important thing is that no modern compiler will not perform an initial search in the current directory when seeing #include "xxx".
I have no evidence to the contrary but still think that statement is assuming an awful lot.
Yes again. They are both implementation defined. But the "" version must, after doing the implementation defined thing and failing, then do the same thing as the <> version, as defined in 6.10.2 section 3.
"...the directory where the compiler was started, or the current directory where the source file was"
OR, possibly, the directory where the Project file is, etc,...
Yes, several IDE-based solutions first looks in the same directory where the C or C++ file was, and then looks in the root directory for the project (and in the extra directories added to the project)
...Please read the manual!
Yes, in the end, it's likely time to figure out where to add any -I<dir> to inform the compiler where to look.
The rule-book states that any "< >" includes are a big red-flag that cautions a potential non-portable source-code reference.
In general all source should be in the project's directory. The few exceptions are the ANSI standard inclusions like <stdio.h>.
One should not rely upon the IDE's environment variables to build the software (e.g. exactly where the <stdio.h> is located).
If you have multiple cross-compilers or even PC compilers or other software that has include path information you better make sure your IDE is referencing the right subdirectory.
The IDE package usually controls this fairly well, but "the rule-book" tries to force the code-monkey into having a single project directory (with potential subdirectories) which contains all of the code needed for a build, and should not rely upon the tool-chain's implied include paths.
Yes, I know that a build itself implies the IDE's inclusion path, but the fewer "< >" inclusions, the better the encapsulation of the source code is.
This becomes especially important when a 'new' library is added to your IDE's tool-chain. You just cannot assume that a new machine with Keil's IDE installed will also contain the 'new' library information; and thus not able to build an executable based upon the source code and the cross-compiler.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Yes again.
Ah, I misunderstood what you said. Apologies.
Yes, it is definitely better to have 3rd-party libraries hard-linked to projects, instead of having them installed system-wide and after an update of the library find out that 3 out of 12 projects suddenly doesn't build.
I normally install extra libraries in directories that specifies the exact library version and have the different project specify exactly what library version to use. That allows multiple versions to be available at the same time and existing projects can be rebuilt without any changes.
Another danger when having extra header files in the <> namespace is the potential namespace collision. It isn't so fun when the order of the path controls which header files that gets used.
No problem. Better with too much than too little clarifications.