Typedefs automatically imported in header files

[Sythical]

I recently noticed that I don't need to include the required header files inside header files that I have written myself. As as example, GLuint is defined using typedef unsigned int GLuint; inside glew.h. If I create a sample.hpp header file and mention GLuint without including glew.h, the compiler automatically works out that there is a typedef in glew.h. However, if I mention GLuint in a source file the compiler starts to complain. Why is this happening? I have seen this happen in VS 2010 and 2013. Thanks!

Edit: I should have mentioned that I am not including any other header files so I'm not indirectly including glew.h

In case you need to look at the code:

#ifndef CP_SHADER_LOADER_H
#define CP_SHADER_LOADER_H


namespace cp {

	class Shader {

		GLuint program_ID;

	public:
		Shader(const GLchar *vertex_source, const GLchar *fragment_source);

		~Shader();

		GLuint get_program_ID() { return program_ID; }
	};
}

#endif 

[Peter87]

In the source file you probably include glew.h before you include sample.hpp.

[helios]

In the source that includes the header in question, you're probably including -- either directly or indirectly -- glew.h before including the header, and so the typedef exists at the point the compiler gets to its usage. But if you simply don't include anything in a source, the typedef just isn't there.

Here's a simple test: Go to any usage of the typedef and hit F12. This will bring you to the definition. Add below the typedef something like

#error The typedef exists!  

If glew.h is included at all, the compilation will fail.

[Sythical]

Sorry, I never knew that headers included in a source file are visible to other headers which are also included. These are the files I am using at the moment along with their include statements:

// main.cpp
#include <GL/glew.h>
#include <SDL.h>

#include "shader_library.hpp"
#include "shader_loader.hpp" 

// shader_library.hpp
// includes nothing 

// shader_loader.hpp
#include <GL/glew.h> 

// shader_loader.cpp
#include "shader_loader.hpp" 

In main.cpp, changing the order of the includes doesn't seem to make any difference but removing #include <GL/glew.h> causes shader_library.hpp to complain.

If I #include <GL/glew.h> in shader_loader source instead of shader_loader header, it gives me an error saying that I haven't declared some of the variables. I feel as if I'm forcing the program to work at the moment by including headers at different places. From the tutorials I have read online, all I know is that to use a header file I need to include it. I also just had a look my copy of C++ Primer and found nothing useful. Can you please talk a bit more about include visibility or point me in the right direction? Thank you both for your responses, they've helped me understand the issue better.

[keskiverto]

I never knew that headers included in a source file are visible to other headers which are also included.

They don't. Kind of.

When you compile your main.cpp, a preprocessor processes it first. It executes the directives like #include.

You had main.cpp:

#include <GL/glew.h>
#include <SDL.h>

#include "shader_library.hpp"
#include "shader_loader.hpp"

// code of main 

That converts to:

// contents of GL/glew.h
// contents of SDL.h
// contents of shader_library.hpp
// contents of shader_loader.hpp
// code of main 

But wait! The shader_loader.hpp has an #include. No worries, preprocessor is recursive:

// contents of GL/glew.h (1)
// contents of SDL.h
// contents of shader_library.hpp
// contents of GL/glew.h (2)
// rest of contents of shader_loader.hpp
// code of main 

Oh no, we got some code twice! That is surely an error?

Yes it is, but no we didn't. Each header should have inclusion guards that stop the preprocessor copying their contents more than once into the same translation unit. The glew.h is a good header and that is why its second inclusion adds nothing.

When the preprocessor has finished, the compiler gets the resulting text.


Order is important. You have to declare first, before use.


Herb Sutter has written many times on his Guru of the Week series about include's dos and don'ts.

[helios]

In main.cpp, changing the order of the includes doesn't seem to make any difference but removing #include <GL/glew.h> causes shader_library.hpp to complain.

I'm willing to bet that some orders do break the compilation. For example,

#include "shader_library.hpp"
#include <GL/glew.h>
#include <SDL.h>

#include "shader_loader.hpp" 

I feel as if I'm forcing the program to work at the moment by including headers at different places. From the tutorials I have read online, all I know is that to use a header file I need to include it.

Yep. shader_library.hpp needs glew.h, so just include it there and leave it alone.

Sorry, I never knew that headers included in a source file are visible to other headers which are also included.

Can you please talk a bit more about include visibility or point me in the right direction?

Headers don't really exist as far as the compiler is concerned. #include just takes a file and copies its contents onto another file. What the compiler sees is simply a really long monolithic source. For example,

// main.cpp
//(contents of GL/glew.h)
//(contents of SDL.h)

// shader_library.hpp
// includes nothing
// shader_loader.hpp
//(contents of GL/glew.h are skipped due to an include guard) 

It's not that headers see each other. Everything in the output of the preprocessor sees everything that came before it.

[Sythical]

That makes perfect sense, thank you everyone :)