printf without stdio.h
-
I am in Microsoft Visual Studio Community 2022 (64-bit). I noticed that I can use printf even without including stdio.h. It works if I do this:
#include
Any idea why this works? Thanks.
The chain of include files can be long and tortuous. In this particular case: iostream -> istream -> ostream -> ios -> cstdio -> stdio.h Should you rely on compiler include chains? Depends if you expect your code to be compiled with a different compiler and how long the chain is. In this particular case, there is a strong probability that all C++ iostream operations will end up like C function calls so you are pretty safe.
Mircea
-
I am in Microsoft Visual Studio Community 2022 (64-bit). I noticed that I can use printf even without including stdio.h. It works if I do this:
#include
Any idea why this works? Thanks.
mike7411 wrote:
It works if I do this: C++ #include <iostream> Any idea why this works?
I guess, because there is a declaration of printf or or this is #included
-
I am in Microsoft Visual Studio Community 2022 (64-bit). I noticed that I can use printf even without including stdio.h. It works if I do this:
#include
Any idea why this works? Thanks.
iostreamprovides very complex facilities to C++, and requires a great deal of supporting infrastructure. You can get a list of all the include files that a compilation unit needs by using the/showIncludesflag in your compiles (-H for gcc/clang). Using [Compiler Explorer](https://godbolt.org/), I see over 100 additional files included, includingnew,string,istream,ostream,atomicandcstdio(which gets you printf), just to name a few. As others have pointed out, you can just go ahead and use printf for example, and not add#includeto your source file. However, as compilers evolve, you may find that this is no longer the case, at which point your code will fail to compile. Its good practice to #include all the relevant headers. System headers, at least, will have guards against multiple inclusions, so there's no harm in being explicit about what headers your program, or module, requires."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
The chain of include files can be long and tortuous. In this particular case: iostream -> istream -> ostream -> ios -> cstdio -> stdio.h Should you rely on compiler include chains? Depends if you expect your code to be compiled with a different compiler and how long the chain is. In this particular case, there is a strong probability that all C++ iostream operations will end up like C function calls so you are pretty safe.
Mircea
-
I'm looking at the ios file, and I don't see where cstdio gets included. I did a search in the file for cstdio, and it doesn't seem to be there. Thanks.
I skipped a step: ios -> xlocnum -> cstdio.
Mircea
-
iostreamprovides very complex facilities to C++, and requires a great deal of supporting infrastructure. You can get a list of all the include files that a compilation unit needs by using the/showIncludesflag in your compiles (-H for gcc/clang). Using [Compiler Explorer](https://godbolt.org/), I see over 100 additional files included, includingnew,string,istream,ostream,atomicandcstdio(which gets you printf), just to name a few. As others have pointed out, you can just go ahead and use printf for example, and not add#includeto your source file. However, as compilers evolve, you may find that this is no longer the case, at which point your code will fail to compile. Its good practice to #include all the relevant headers. System headers, at least, will have guards against multiple inclusions, so there's no harm in being explicit about what headers your program, or module, requires."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
k5054 wrote:
Its good practice to #include all the relevant headers
I agree. This specific case is rather simplistic but in larger applications with company code all over the place relying on chains is just a maintenance (preventable) problem waiting to happen.
