Newb question about includes in Dev-C++
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
I'm a beginning student in C, and have been using Dev-C++ for a little while to do some of my lab work at home. Working on a program tonight I used a library function (getcwd) and realized I didn't actually know which header it came from, but the program still compiled and ran without any issues. Out of curiousity removed the already included headers one-by-one from the program to determine which it was contained in.. until I'd removed them all, and the program still compiled flawlessly. I take it Dev-C++ is doing something behind the scenes to automatically include needed headers, but I havn't been able to figure out what by poking around in the options. Can someone clue a novice into what's going on here? I don't want to miss including a header that's necessary to compile graded assignments when the prof. does so on his own system :)
Are you compiling a Windows app or a plain console application?
The windows.h includes by itself a buch of other headers.
Oh! Sorry about missing that, it's just a console app (I've been creating a C project for each of my assignments), and I'm using Dev-C++ v4.9.9.2
In C, if a function is called without a declaration the compiler make the assumption that it returns an int and has undefined parameters. If you have not set appropriate appropriate warning options it will quietly compile it. I suggest addding -Wall -Werror to your compiler options to trap this.
The problem with the default assumption is that it may be wrong, and it inhibits correct parameter checking.
In C++ you cannot do this because it has stronger type checking and it would preclude C++'s support for function overloading.
It is in io.h BTW (text searching the headers in c:\dev-cpp\include is the possibly the fastest way to figure that out, if you search for "<io.h>", you will discover that it is included in a number of other headers.
Clifford
That does it, the compiler halts on implicit declarations now with those arguments added to the options, which saves me worrying about missing something. I'm curious about these implicit declarations, though. Was the compiler automatically adding the appropriate library code for functions such as printf() and system() because they're standard functions?
>> Was the compiler automatically adding the appropriate library code
>> for functions such as printf() and system() because they're standard
>> functions?
Not exactly. The header files do not contain the code for those functions - the header file is not the library. It merely contains declarations which serve to allow the compiler to generate code to correctly call the function and also to check that correct (or compatible) parameters and return types are used.
The compiler itself knows nothing about the function other than the declaration in the header - that is it knows only what it's interface is, so it places a place-holder (an unresolved link) in the object code. The linker then resolves any unresolved links with the addresses of functions from other object files or libraries.
The code for these functions is provided by the library (in this case Microsoft's C Runtime implemented in MSVCRT.DLL). This library's export lib (libc.a) is linked by default (as is libstdc++.a if using C++). The C++ library is slightly different in that much of the code is in fact 'in-lined' in the headers themselves - this is due to limitations in the support for C++ templates.
It may help to understand the end-to-end build process, see: https://sourceforge.net/forum/message.php?msg_id=2670009
Clifford
Ah! That's just what I was looking for. Thanks so much for taking the time to explain things, Clifford! The nuts and bolts of the build process is something we've yet to cover in class, so I'm ahead of the game on top of having my curiousity satisfied.
That always annoys me about academic programming courses. If I were designing a course it might start something like this:
1) Hello, world
2) The compilation and linking process (how "hello, world" was built)
3) Using the debugger (how "hello, world" runs)
... then all the rest of the stuff about loops, functions, classes, data types etc.
Understanding the build process makes it much easier to make sense of the error messages, and being able to use the debugger can lead to far less frustration when developing your own code and assignments, and makes the kind of trivial programs you typically have to write when learning, far more interesting as you can minutely study their actual workings step by step.
Clifford