I've copied and pasted some files from my windows machine to my linux one and ran into a few understandable problems with the conio.h and Windows.h headers, but I can't remember what they're needed for.
They're only in the main function so I commented them out and ran the program again thinking the errors would show me where they're needed so I could then google what headers would work similarly for linux.
The problem I have is that all the errors I get are in header files I've included in the main function, but don't have the Windows.h or conio.h headers included.
The question I have is how/why: -
Does the compiler look at each header file in turn, get to the windows.h header and stop then when that's commented out it get's to my "Chapter_7.h" header and find all the problems in there.
Or could the commenting out of the headers in the main.cpp somehow affect the headers I wrote.
Or (possibly more likely) Is there another option I've overlooked?
Thanks for any answers.
It is due to the way .h files are "INCLUDED" in the .cpp. During compilation, all the text in the header files is copy pasted into the including .cpp file. This means later .h files will have access to earlier ones.
This looks to be what is happening in your case, windows.h would have been the first include, and subsequent headers have been using it all along.
//#include <window.h>
//#include <conio.h>
#include "myheader.h" // can no longer use windows.h or conio.h
#include "myheader2.h"
You can say header contents are copy-pasted inside the file they're included in, if that's what you mean.
Or could the commenting out of the headers in the main.cpp somehow affect the headers I wrote.
Definitely. Assume:
//header1.h
#define X 1
//header2.h
#ifdef X
int a = 0;
#else
int a = 1;
#endif
a will be defined differently if header1.h is included before or after header2.h.
The first step of fixing "I'm using headerfiles that I can't use on this machine" is to remove those files, compile the code and see where things break - it's nearly always making compiler errors, so you should be able to find it quite easily.
conio.h allows console io, and it may require a bit of work to fix that into Linux. Depends on exactly what you are using.
windows.h is much more complex to explain, as it essentially gives you all of the Windows API functions, and a huge number of type declaration, and there are many of those. Most of which your program probably never uses [directly].
One of the common problems with "using a headerfile that doesn't exist somewhere else" is that you end up using some types that are declared in the headerfile. So for example, windows.h will declare LONG, HANDLE, and a vast number of other types. These types are then used in structures and function declarations elsewhere, and when you remove windows.h it will cause all manner of follow-on problems.
My approach is always to fix the first problem first, then compile again. The reason for this is that the compiler often gets "confused" if something strange appears. It's a bit like if you were to tell a friend how to drive to your house, and you say "When you see the big-oaktree on the left, you take the next right". Unknown to you, the oak-tree has been cut down because it was dieing, and is no longer there. So your friend drives where the oak-tree used to be, and turns right after another oak-tree later on along the road. Of course, now all OTHER instructions are completely uselss, because your friend is miles away from the correct road, and is never going to find your house without new instructions. The same thing happens when the compiler finds "surprising" or "missing" bits in the source-file. So fixing the first error, then compiling, fixing, compiling, usually gets you to a point where your code compiles. Sometimes this involves writing new functions like this:
int GetTimeOfDay(void)
{
printf("%s:%d:%s: doesn't work yet, exiting...", __FILE__, __LINE__, __func__);
exit(1);
return 0; // to keep compiler happy.
}
Once you got all the code compiling, you start working out how to implement/replace those functions that you added to make it compile.
Related
The code I am working has multiple headers and source files for different classes face.cc, face.hh, cell.cc, cell.hh edge.cc edge.hh and the headers contain includes like this,
#ifndef cellINCLUDED
#define cellINCLUDED
#ifndef faceINCLUDED
#define faceINCLUDED
I saw through http://www.cplusplus.com/forum/articles/10627/ and saw the way to write include guard is
#ifndef __MYCLASS_H_INCLUDED__
#define __MYCLASS_H_INCLUDED__
So in above code that I am working on, does compiler automatically understands it is looking for face.hh or cell.hh files?
better question : Is writing __CELL_H_INCLUDED__ same as cellINCLUDED ?
#ifndef __MYCLASS_H_INCLUDED__
#define __MYCLASS_H_INCLUDED__
So in above code that I am working on, does compiler automatically
understands it is looking for face.hh or cell.hh files?
No, the compiler doesn't automatically understand what you mean.
What really happens is that, when compiling a translation unit, the Compiler holds a list of globally defined MACROs. And so, what you are doing is defining the MACRO __MYCLASS_H_INCLUDED__ if it doesn't already exists.
If that macro is defined, that #ifndef until #endif will not be parsed by the actual compiler.
Hence you can test for the existence of that MACRO to determine if the Compiler has parsed that header file to include it once and only once in the translation unit... This is because the compiler compiles each translation unit as one flattened file (after merging all the #includes)
See https://en.wikipedia.org/wiki/Include_guard
Is writing __CELL_H_INCLUDED__ same as cellINCLUDED ?
Yes it is.... The reason some prefer using underscored prefixed and suffixed MACROs for include guards is because they have extremely low probability of ever being used as identifiers... but again, underscore could clash with the compiler...
I prefer something like this: CELL_H_INCLUDED
If you use cellINCLUDED, there are chances that someday, somebody may use it as an identifier in that translation unit
The preprocessor definitions have no special meaning. The only requirement is that they stay unique across the modules, and that's why the file name is typically a part of them.
In particular, the mechanics for preventing double inclusion aren't "baked in" the language and simply use the mechanics of the preprocessor.
That being said, every compiler worth attention nowadays supports #pragma once, and you could probably settle on that.
As the link you have referenced says, "compilers do not have brains of their own" - so to answer your question, no, the compile does not understand which particular files are involved. It would not even understand that '__cellINCLUDED' has anything conceptually to do with a specific file.
Instead, the include guard simply prevents the logic contained between its opening #ifndef and closing #endif from being included multiple times. You, as the programmer, are telling the compiler not to include that code multiple times - the compiler is not doing anything 'intelligent' on its own.
Nope, This is essentially telling the compiler/parser that if this has already been put into the program, don't puthave already been loaded.
This should be at the top (and have an #endif at the bottom) of your .h file.
Lets say you have mainProgram.cpp and Tools.cpp, with each of these files loading fileReader.h.
As the compiler compiles each cpp file it will attempt to load the fileReader.h. unless you tell it not to it will load all of the fileReader file in twice.
ifndef = if not defined
so when you use these (and the #endif AFTER all your code in the .h file)
you are saying:
if not defined: cellINCLUDED
then define: cellINCLUDED with the following code:
[code]
end of code
so this way when it goes to load the code in your .h file a second time it hits the if not defined bit and ignores the code on the second time.
This reduces compile time and also means if you are using a poor/old compiler it isn't trying to shove the code in again.
For example in foo.h:
typedef struct foo_t foo_t;
/* Lots of function declarations dealing with foo_t... */
int foo_print(const foo_t *foo); /* Print foo to stdout. */
int foo_fprint(FILE *f, const foo_t *foo); /* Print foo to file f. */
I don't want to litter foo.h with too many other header files that users of foo.h might not have wanted to include, but I do need to declare functions that take types such as FILE*. I doubt that I am the first to encounter this dilemma, so what do people usually do in these circumstances? Or am I misguided in wanting to avoid including stdio.h in my header files?
EDIT:
People seem not to be understanding my question. To clarify, here are some potential solutions:
Just include stdio.h and not worry about it causing conflicts in my clients' code (such as if they happened to have their own function that happened to be called getchar).
Use an #ifdef to find out if stdio.h had already been included, and only then declare the FILE*-related functions. The downside of this is that it would impose a particular ordering to #includes in my clients' code.
Move all I/O-related declarations to a separate header file such as foo_io.h.
What question is what is the best thing to do?
Short answer: you are trying to solve a non-existing problem.
If you use FILE, you include stdio.h or cstdio in C++. It's that simple.
Trying to "optimize" #includes, besides obvious cases of unused ones, will not buy you anything and cause problems.
You should strive to have header files compile cleanly in an empty source module. For example:
#include "myheader.h"
and that's it. If you put that in a C++ source file and compiled it with no other code, you should get no compiler errors.
If you do get errors, then you need to justify why there are errors. The only legitimate reason I would think of for errors is that the header is internal in your library, and was not meant to be used standalone by the user of your library.
If the header is supposed to be used by your clients, do not "fix" the problem by taking the test source file above and adding headers to the source. You fix it by including the proper headers within (in my simple case) myheader.h
Refering to the updated question:
Conditionally enabling or disabling blocks of code (or features) depending on order of included files stinks as hell. It's a straight way to hell.
If you want to enable or disable your functionality, making your code more modular, you can use preprocessor macros, possibly requiring user to explicitly choose compilation mode.
#ifdef USE_STDIO
#include <stdio.h>
#endif
lotsa lotsa code
#ifdef USE_STDIO
int foo_print(const foo_t *foo);
int foo_fprint(FILE *f, const foo_t *foo);
#endif
Downside of this solution: code becomes harder to follow.
Second option is to extract those methods to foo_io.h (and possibly foo_io.c). The downside of this solution is that you're forcing user to include two files instead of one.
You've already answered your own question. Both 1) and 3) are valid solutions. If you use FILE* in one of your functions then it only makes sense to use your function in combination with the header where FILE is declared. As others noted, there is no header that would forward declare FILE, so your only choice is to include stdio.h.
If your client includes your header file, assume that all the functions will be used. Do not use conditional compilation for cutting out include's. If I'd include your header file and see that that it contains a declaration of a function that uses FILE* I would expect to have stdio.h included as well.
If you're using a standard library functionality, just include that standard header full stop. Don't try to over-think that someone may have a function with the same name as something in the standard library: Their code is already fragile/broker and you shouldn't worry about such cases.
I can't make out if your code is C++ or C though (note that even though C++ may have roots in C they are distinct languages). If it's C++ you can use cstdio instead of stdio.h and use features from the std namespace instead of the global namespace. Otherwise if your code is C you have to use stdio.h
I was wondering if there is some pro and contra having include statements directly in the include files as opposed to have them in the source file.
Personally I like to have my includes "clean" so, when I include them in some c/cpp file I don't have to hunt down every possible header required because the include file doesn't take care of it itself. On the other hand, if I have the includes in the include files compile time might get bigger, because even with the include guards, the files have to be parsed first. Is this just a matter of taste, or are there any pros/cons over the other?
What I mean is:
sample.h
#ifdef ...
#include "my_needed_file.h"
#include ...
class myclass
{
}
#endif
sample.c
#include "sample.h"
my code goes here
Versus:
sample.h
#ifdef ...
class myclass
{
}
#endif
sample.c
#include "my_needed_file.h"
#include ...
#include "sample.h"
my code goes here
There's not really any standard best-practice, but for most accounts, you should include what you really need in the header, and forward-declare what you can.
If an implementation file needs something not required by the header explicitly, then that implementation file should include it itself.
The language makes no requirements, but the almost universally
accepted coding rule is that all headers must be self
sufficient; a source file which consists of a single statement
including the include should compile without errors. The usual
way of verifying this is for the implementation file to include
its header before anything else.
And the compiler only has to read each include once. If it
can determine with certainty that it has already read the file,
and on reading it, it detects the include guard pattern, it has
no need to reread the file; it just checks if the controling
preprocessor token is (still) defined. (There are
configurations where it is impossible for the compiler to detect
whether the included file is the same as an earlier included
file. In which case, it does have to read the file again, and
reparse it. Such cases are fairly rare, however.)
A header file is supposed to be treated like an API. Let us say you are writing a library for a client, you will provide them a header file for including in their code, and a compiled binary library for linking.
In such scenario, adding a '#include' directive in your header file will create a lot of problems for your client as well as you, because now you will have to provide unnecessary header files just to get stuff compiling. Forward declaring as much as possible enables cleaner API. It also enables your client to implement their own functions over your header if they want.
If you are sure that your header is never going to be used outside your current project, then either way is not a problem. Compilation time is also not a problem if you are using include guards, which you should have been using anyway.
Having more (unwanted) includes in headers means having more number of (unwanted) symbols visible at the interface level. This may create a hell lot of havocs, might lead to symbol collisions and bloated interface
On the other hand, if I have the includes in the include files compile time might get bigger, because even with the include guards
If your compiler doesn't remember which files have include guards and avoid re-opening and re-tokenising the file then get a better compiler. Most modern compilers have been doing this for many years, so there's no cost to including the same file multiple times (as long as it has include guards). See e.g. http://gcc.gnu.org/onlinedocs/cpp/Once_002dOnly-Headers.html
Headers should be self-sufficient and include/declare what they need. Expecting users of your header to include its dependencies is bad practice and a great way to make users hate you.
If my_needed_file.h is needed before sample.h (because sample.h requires declarations/definitions from it) then it should be included in sample.h, no question. If it's not needed in sample.h and only needed in sample.c then only include it there, and my preference is to include it after sample.h, that way if sample.h is missing any headers it needs then you'll know about it sooner:
// sample.c
#include "sample.h"
#include "my_needed_file.h"
#include ...
#include <std_header>
// ...
If you use this #include order then it forces you to make sample.h self-sufficient, which ensures you don't cause problems and annoyances for other users of the header.
I think second approach is a better one just because of following reason.
when you have a function template in your header file.
class myclass
{
template<class T>
void method(T& a)
{
...
}
}
And you don't want to use it in the source file for myclass.cxx. But you want to use it in xyz.cxx, if you go with your first approach then you will end up in including all files that are required for myclass.cxx, which is of no use for xyz.cxx.
That is all what I think of now the difference. So I would say one should go with second approach as it makes your code each to maintain in future.
I started writing a simple interpreter in C++ with a class structure that I will describe below, but I quit and rewrote the thing in Java because headers were giving me a hard time. Here's the basic structure that is apparently not allowed in C++:
main.cpp contains the main function and includes a header for a class we can call printer.h (whose single void method is implemented in printer.cpp). Now imagine two other classes which are identical. Both want to call Printer::write_something();, so I included printer.h in each. So here's my first question: Why can I #include <iostream> a million times, even one after the other, but I can only include my header once? (Well, I think I could probably do the same thing with mine, as long as it's in the same file. But I may be wrong.) I understand the difference between a declaration and an implementation/definition, but that code gives me a class redefinition error. I don't see why. And here's the thing that blows my mind (and probably shows you why I don't understand any of this): I can't just include printer.h at the top of main.cpp and use the class from my other two classes. I know I can include printer.h in one of the two classes (headers) with no trouble, but I don't see why this is any different than just including it before I include the class in main.cpp (as doing so gives me a class not found error).
When I got fed up, I thought about moving to C since the OOP I was using was quite forced anyway, but I would run into the same problem unless I wrote everything in one file. It's frustrating to know C++ but be unable to use it correctly because of compilation issues.
I would really appreciate it if you could clear this up for me. Thanks!
Why can I #include a million times, even one after the other, but I can only include my header once?
It is probably because your header doesn't have an include guard.
// printer.h file
#ifndef PRINTER_H_
#define PRINTER_H_
// printer.h code goes here
#endif
Note that it is best practice to chose longer names for the include guard defines, to minimise the chance that two different headers might have the same one.
Most header files should be wrapped in an include guard:
#ifndef MY_UNIQUE_INCLUDE_NAME_H
#define MY_UNIQUE_INCLUDE_NAME_H
// All content here.
#endif
This way, the compiler will only see the header's contents once per translation unit.
C/C++ compilation is divided in compilation/translation units to generate object files. (.o, .obj)
see here the definition of translation unit
An #include directive in a C/C++ file results in the direct equivalent of a simple recursive copy-paste in the same file. You can try it as an experiment.
So if the same translation unit includes the same header twice the compiler sees that some entities are being defined multiple times, as it would happen if you write them in the same file. The error output would be exactly the same.
There is no built-in protection in the language that prevents you to do multiple inclusions, so you have to resort to write the include guard or specific #pragma boilerplate for each C/C++ header.
I've been wondering if the msvc++ 2008 compiler takes care of multiple header includes of the same file, considering this example:
main.cpp
#include "header.h"
#include "header.h"
Will the compiler include this file multiple times or just one? (I'm aware I can use the #ifndef "trick" to prevent this from happening)
Also, if I include "header.h" which contains 10 functions, but I only call or use 2, will it still include all 10 or just the 2 I need and all of their needs?
#include is basically a synonym for "copy-and-paste". If you do identical #includes, the contents of that header file will be copy-and-pasted twice, sequentially.
As to your second question, it doesn't really make sense. #includes are executed by the preprocessor, which runs before the compiler and the linker. The preprocessor doesn't know or care what the content of the header file is, it simply copy-and-pastes it in. The linker may be able to eliminate unnecessary functions, but that's completely independent of the preprocessor.
No, the compiler (or, more accurately, the pre-processor) doesn't take care of this "automatically". Not in Visual C++ 2008, or in any other version. And you really wouldn't want it to.
There are two standard ways of going about this. You should choose one of them.
The first is known as include guards. That's the "#ifndef trick" you mentioned in your question. But it's certainly not a "trick". It's the standard idiom for handling this situation when writing C++ code, and any other programmer who looks at your source file will almost certainly expect to see include guards in there somewhere.
The other takes advantage of a VC++ feature (one that's also found its way into several other C++ toolkits) to do essentially the same thing in a way that's somewhat easier to type. By including the line #pragma once at the top of your header file, you instruct the pre-processor to only include the header file once per translation unit. This has some other advantages over include guards, but they're not particularly relevant here.
As for your second question, the linker will take care of "optimizing" out functions that you never call in your code. But this is the last phase of compilation, and has nothing to do with #include, which is handled by the pre-processor, as I mentioned above.
The MSVC 20xx preprocessor (not the compiler -- the compiler never sees preprocessor directives) does not in any sense "take care of" multiple #includes of the same file. If a file is #included twice, the preprocessor obeys the #includes and includes the file two times. (Just imagine the chaos if the preprocessor even thought about trying to correct your source file's "bad" #include behavior.)
Because the preprocessor is so meticulous and careful about following your instructions, each #included file must protect itself from being #included twice. That protection is what we see when we find lines like these at the top of a header file:
#ifndef I_WAS_ALREADY_INCLUDED // if not defined, continue with include
#define I_WAS_ALREADY_INCLUDED // but make sure I'm not included again
[ header-file real contents ]
#endif // I_WAS_ALREADY_INCLUDED
When you write a header file, you must always be sure to protect it in this way.
Why do you care? It doesn't add really much burden on the compiler because the compiler conditionally (with #ifdefs, for example) excludes code it doesn't need to compile.
Preprocessor will include 2 times these headers. Thats why guards in header files are required.
As far as I know the linker is most cases will remove code (functions) that are newer used to reduce executable file size.