Sign in to follow this  
sipickles

File linking order

Recommended Posts

sipickles    240
If I am advised to link one file before another, how do I achieve this when I don't know which order the files will link? CEGUI needs a link to cegui.h before windows.h to avoid duplicating the defines for min and max, but I don't know how to do this. I've tried linking to cegui.h before windows.h in every file that uses windows.h but no luck. I still get a message saying Macro definition of max detected - undefining Macro definition of min detected - undefining Any suggestions? Thanks! Simon

Share this post


Link to post
Share on other sites
Antheus    2409
You're talking about "including". Linking is a completely different process and is done after compilation.

One way is to not include these files separately.

Create one header only, common.h

#ifndef COMMON_H
#define COMMON_H

// the very first include
#include "cegui.h"

// directly followed by
#include "windows.h"

// any other header

#endif



Then, always include only and only common.h as the very first include. Never cegui.h directly. That's the only way I can think of that could somewhat reliably guarantee include order.

Some reason is that some headers can directly or indirectly include windows.h, or parts included by windows.h.

Share this post


Link to post
Share on other sites
Evil Steve    2017
First, the term is "including" .h files. Linking usually referrs to .lib files.

The order a file is included in is well defined, since the file will be processed from top to bottom. However, any header you include may also have #include directives in it, and they will also be parsed from top to bottom.

You might have something like this:
File1.cpp:

#include "File1.h"
#include "cegui.h"



File1.h:

#include "windows.h"

// Declarations here which requires windows.h


In this case, File1.h is included, which includes windows.h, and then cegui.h is included.

Share this post


Link to post
Share on other sites
sipickles    240
Funnily enough I used to have a hub.h which held all the includes for my app.

Was huge tho!

Wouldn't linking only where needed help compilation speed, etc?

Share this post


Link to post
Share on other sites
sipickles    240
Okay sorry about the LINKING term.... my bad.

Steve, my problem is I have 50 files, so which is your 'file1'?

Is it the file with the WinMain entry point in?

Share this post


Link to post
Share on other sites
jpetrie    13099
Quote:

Funnily enough I used to have a hub.h which held all the includes for my app.

This is generally a very bad idea, as it massively inflates compile times and dependencies, and can cause some very subtle errors that look like they are completely impossible.

The preprocessor define NOMINMAX is the proper way to suppress the definition of the min and max macros in windows.h; if the symbol is defined prior to including windows.h, windows.h will not define min and max on its own. This should prevent the errors.

While the technique of using a "global.h" or "common.h" style header that contains everything is generally bad, it is acceptable and even a good idea to use a compatibility header to wrap other tightly-coupled includes and preprocessor symbols that gate their expansion. SDL does this with the OpenGL headers, I believe, because there are inclusion orders and preprocessor issues between GL's headers and windows.h, as well.

You'd want to have this compatability header do as little as possible. It's acceptable to include both CEGui and Windows headers from it, but I would strongly suggest trying to get it to work with just windows.h, first. For example, you might call the file "CompatibleWindows.h" and it might contain:

#ifndef COMPATIBLE_WINDOWS_H_
#define COMPATIBLE_WINDOWS_H_

#define NOMINMAX
#include <windows.h>

#endif

Then you'd include CompatibleWindows.h in lieu of windows.h, but only where appropriate. That way the ordering relative to CEGui should not matter (unless there are additional conflicts, in which case you can try to fix them without including CEGui stuff in CompatibleWindows.h, but you might not be able to.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this