Cmath cant open math.h
I was following an SDL tutorial, and it all was going okay up until I had to include some new directories in the SDL files regarding textures. After this, I got a hell of a lot of errors(626 in all), and I realized they are all coming from the CMath file. I scrolled all the way to the top and realized that Cmath is unable to open math.h. I have no idea where to go with this, or what the problem could be.
<cmath> is the same as <math.h> except for one important difference:
the former is a C++ file and wraps everything in the
It is okay if in #include <math.h> instead. If that doesn't fix the errors, point us to the tutorial you are following and we'll see if we can see what the error is (beyond age rot).
the former is a C++ file and wraps everything in the
std namespace.It is okay if in #include <math.h> instead. If that doesn't fix the errors, point us to the tutorial you are following and we'll see if we can see what the error is (beyond age rot).
if <cmath> cannot find <math.h> then your compiler and tools installation is corrupted somehow.
case matters, just in case you had <Cmath> ?
case matters, just in case you had <Cmath> ?
Last edited on
I'm not even using cmath in any of my files, it just came up as an error within the cmath file, not within the code I am making.
Alas, I'm too impatient to watch an 18 minute video through, and I have no interest in playing with DropBox just to get at that Dev.zip.
For now, the way to figure out what went wrong is to roll back to a point where you last made changes that did not break the build.
From that point forward, pay close attention to what could have happened. When you discover the thing that causes the breakage, analyze it.
Have you moved files around? Changed the directory structure?
MSVC is a little unique about how it handles library and header includes -- you must explicitly add each external item to every project you do. (I do recommend keeping include, bin, and lib folders under C:\Users\Public\Documents\Visual Studio\ and/or C:\Users\moosymann\Documents\Visual Studio\ for your common libraries and adding it to the IDE's "include these directories automatically" options, but that seems oddly rare in MSVC-land compared to everyone else.)
A project file cannot keep things in absolute paths -- otherwise once you give someone the source to your code they wouldn't be able to compile it -- so all the project files are relative. (Warning -- that was a simplification.) What it means, though, is that you can confuse the compiler by moving things.
I think this is the most likely what-happened. But without a more direct hand in your code, it is just a guess.
Good luck!
For now, the way to figure out what went wrong is to roll back to a point where you last made changes that did not break the build.
From that point forward, pay close attention to what could have happened. When you discover the thing that causes the breakage, analyze it.
Have you moved files around? Changed the directory structure?
MSVC is a little unique about how it handles library and header includes -- you must explicitly add each external item to every project you do. (I do recommend keeping include, bin, and lib folders under C:\Users\Public\Documents\Visual Studio\ and/or C:\Users\moosymann\Documents\Visual Studio\ for your common libraries and adding it to the IDE's "include these directories automatically" options, but that seems oddly rare in MSVC-land compared to everyone else.)
A project file cannot keep things in absolute paths -- otherwise once you give someone the source to your code they wouldn't be able to compile it -- so all the project files are relative. (Warning -- that was a simplification.) What it means, though, is that you can confuse the compiler by moving things.
I think this is the most likely what-happened. But without a more direct hand in your code, it is just a guess.
Good luck!
I switched the libraries in the general tab in linker to 64 bit, and that solved this problem.
Ah, I should have thought of that. (I had been under the assumption that it compiled against SDL successfully at some point, so I didn't think to consider 32/64 bit mismatches.)
Good job!
Good job!
Topic archived. No new replies allowed.