Ok, this warrants some explanation....

I use Windows to program, and up until a few months ago, i always used Microsoft Visual C++ IDE (2010, mainly).

But recently i wanted to start developing projects with multi platforms in mind (desktops only, no mobile), and also to experiment on using multiple compilers on the same project, to start writing portable code (both platform wise and compiler wise).

So, in order to do this, i started using Code::Blocks with both GCC and VC10 as the compilers.

My current project is fairly large, but hadn't been a problem until recently, that is, when compiling using GCC only.

I'll explain further.

When i compile my code using GCC, i get the error "file something.h": No such file or directory.

This would be trivial, if the file didn't actually exist, but i noticed that the problem is with the way GCC handles the relative paths to the included file.

Here's a concrete example:

In the "MaterialManager.h" file, i include:

#include "..\..\Shader Manager\_Manager\Program Shader Manager\ProgShaderManager.h" 

Now, say that Renderer includes "MaterialManager.h" (which as above, in turn, includes "ProgShaderManager.h").

The problem, is that after a few nested includes, GCC expands this to something like:

D:\ZTUFF\Projects\EDGE\Source\Engine\Systems\Renderer\Render Engine\_Implementations\Render_GL_MultiPass\..\..\..\..\..\Gameplay\Core Objects\Light Object\..\..\..\Game\State Manager\..\..\Resource Managers\Material Manager\_Manager\MaterialManager.h

And this is what is printed in the build log, right before the "No such file or directory".

In my opinion, the reason it fails, is that it exceeds the maximum path size for relative paths, in WIndows (the large string above, has 250 characters, and i think that when GCC tries to append yet another file name, it exceeds the 260 characters).

I've confirmed this, in that, if i replace any #include path that gives an error, by the it's absolute path, it works.

For example:

"D:\ZTUFF\Projects\EDGE\Source\Engine\Resources\Material Resource\MaterialResource.h"

I thought about prepending a macro of the project source code's absolute path to each #include path, but i would like to avoid if possible.

I should mention again, that VC10 never gave me this sort of problem.

Again, this may end up being a simple thing, that i am simply unaware of, since i'm not that much experienced in GCC, and if someone could enlighten me in how to avoid this problem, I'd be quite thankful.

Thanks in advance, and if there's something that is not clear, I'll work to explain it better.

Yup, replace those bad boys.

In the C language the use of \ in an #include is undefined behavior. (See C99 6.4.7.3 for several character sequences that are illegal or undefined.)

In C++ the processing is completely implementation defined. Specifically, "The appearance of either of the characters ’ or \ or of either of the character sequences /* or // in a q-char-sequence or an h-char-sequence is conditionally supported with implementation-defined semantics" with a footnote that "Thus, a sequence of characters that resembles an escape sequence might result in an error, be interpreted as the character corresponding to the escape sequence, or have a completely different meaning, depending on the implementation."

Even though you can normally encode character strings, the preprocessor include directive is handled differently.

Try #include "\u0066\u0069\u006c\u0065\u002e\u0068" and see what happens. It could look for something called "file.h", it could look for file u0068 five directories deep, or it could do something else entirely.

Well, that sure solves my probblem. You guys are awesome.

I guess a still got quite a bit to learn about multiplatform coding/compilers.

Also, i really forgot to say, and even though it doesn't really matter know, the GCC version is indeed 4.8.1, and the OS is Windows Vista. If anyone is wondering, this is also the reason why i use Visual C++ 2010 and not the most recent, because Vista is no longer supported.

Thanks a lot, really.