Hi,
I just started video 1 of the 'intro to C', and I'm already stuck ... :unsure:
After adding the include for windows.h, I still have the 'unresolved external symbol _WinMain@16' link error ...
Anyone more experienced can help me find out why this is happening ?
Thanks !
I have VS2015 Community edition on Windows 7.
I have programmed before, but obviously not in C B)
I just started video 1 of the 'intro to C', and I'm already stuck ... :unsure:
After adding the include for windows.h, I still have the 'unresolved external symbol _WinMain@16' link error ...
Anyone more experienced can help me find out why this is happening ?
Thanks !
I have VS2015 Community edition on Windows 7.
I have programmed before, but obviously not in C B)
Can you share the code that's giving you this problem? That and the build settings might help us in figuring out the problem.
It could be that you're using 'main' instead of 'WinMain', or it could be a 32bit vs 64bit problem, and so on.
It could be that you're using 'main' instead of 'WinMain', or it could be a 32bit vs 64bit problem, and so on.
Edited by Jeroen van Rijn
on
As pointed out on IRC by d7samurai, Casey actually discusses this very error in the video.
Thanks for helping, Kelimion !
Yes, Casey addresses this issue, but if I understood correctly, the link error should be gone after adding the include ... This does not happen for me.
I'm following along With the Youtube video. There is hardly any code in the file yet :
For Casey this compiles and links just fine; I get the same link error that I had before I added the include.
As for the build settings ... I'm not really sure where to find that info.
Is it 'debug -x86 - local windows debugger' ?
Or is it 'project properties > config > general' ? Because there I can see something that cannot be right : target platform version Windows 8.1.
I'm on Windows 7 SP1, which should be ok for VS2015. I also installed the .NET Framework 4.0, which I think is for Windows 7 ? But I can't see a way to change the 8.1 setting ... :unsure:
Yes, Casey addresses this issue, but if I understood correctly, the link error should be gone after adding the include ... This does not happen for me.
I'm following along With the Youtube video. There is hardly any code in the file yet :
1 2 3 4 5 6 7 8 | #include "Windows.h" int CALLBACK WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); |
For Casey this compiles and links just fine; I get the same link error that I had before I added the include.
As for the build settings ... I'm not really sure where to find that info.
Is it 'debug -x86 - local windows debugger' ?
Or is it 'project properties > config > general' ? Because there I can see something that cannot be right : target platform version Windows 8.1.
I'm on Windows 7 SP1, which should be ok for VS2015. I also installed the .NET Framework 4.0, which I think is for Windows 7 ? But I can't see a way to change the 8.1 setting ... :unsure:
yes, they are both used. but "" is typically used for files local to your project, while <> are used for system headers.
in this case, both would work - what tripped you up was that you didn't have a function body (it was only "forward declared") - but since the code you are following used <>, you should have done so, too.
your problem was simply that you didn't pay close enough attention to what casey was doing.
in this case, both would work - what tripped you up was that you didn't have a function body (it was only "forward declared") - but since the code you are following used <>, you should have done so, too.
your problem was simply that you didn't pay close enough attention to what casey was doing.
Edited by d7samurai
on
As a person who has gotten stuck like this I'll just point out that in the videos * and + look very similar but Casey usually separates + with spaces but not * (I believe this is because the compiler does * before + in a line of code.)
ex. int MySum = One + Three*Three;
"" vs <> in layman speak (how I remember it)
use "" if you made the file
use <> if you include other peoples the files. (ex. if its a separate library)
So don't feel bad about getting stuck on the small stuff, I spent 3 hours yesterday trying to find two errors, (on day 121)
1. a loop that was using (less-than or equals) <= instead of just < (less-than).
- I had found this error but I had another that caused the same error.
2. a conditional set that I wrote in a different order than Casey did and the variable names where very similar. (basically I was using height as width and visa versa)
these both resulted in Memory access violations so when I found the first I didn't understand it really was an error, because I was still getting the same error.
Because its hard to know what of the small stuff is important when you are new I asked a kind of desperate kind of dumb/weird question on stream yesterday so now in about 100 episodes I'll be reminded about a mistake I made yesterday :)
edit:
(OP don't freak out if you don't understand this question, you will in about 120 episodes)
My question was if it mattered what type of int i used to iterate memory a pointer. My desperate logic being that I was stepping to much or too little because I was mixing int and int32... as if the size of the type mattered not only its value. (Just needed to get this off my chest, so my logic for asking this doesn't seem as nuts/stupid as it might have.)
ex. int MySum = One + Three*Three;
"" vs <> in layman speak (how I remember it)
use "" if you made the file
use <> if you include other peoples the files. (ex. if its a separate library)
So don't feel bad about getting stuck on the small stuff, I spent 3 hours yesterday trying to find two errors, (on day 121)
1. a loop that was using (less-than or equals) <= instead of just < (less-than).
- I had found this error but I had another that caused the same error.
2. a conditional set that I wrote in a different order than Casey did and the variable names where very similar. (basically I was using height as width and visa versa)
these both resulted in Memory access violations so when I found the first I didn't understand it really was an error, because I was still getting the same error.
Because its hard to know what of the small stuff is important when you are new I asked a kind of desperate kind of dumb/weird question on stream yesterday so now in about 100 episodes I'll be reminded about a mistake I made yesterday :)
edit:
(OP don't freak out if you don't understand this question, you will in about 120 episodes)
My question was if it mattered what type of int i used to iterate memory a pointer. My desperate logic being that I was stepping to much or too little because I was mixing int and int32... as if the size of the type mattered not only its value. (Just needed to get this off my chest, so my logic for asking this doesn't seem as nuts/stupid as it might have.)
Edited by Jim R. Didriksen
on
d7samurai
yes, they are both used. but "" is typically used for files local to your project, while <> are used for system headers.
...
My understanding is that the include files within brackets are ISO standard files that are part of the language standard. Every implementation of C will/should have them if they conform to the standard.
Quoted include files are application, local system, or platform specific. Many programming environments mix the language and platform include files together. This leads to using brackets for everything.
Windows.h is platform specific and should be quoted. Microsoft would have you believe otherwise.
Every platform should have a bracketed file; the rest are suspect; that was the intent AFIK.
YMMV
- tim
Edited by Timothy McCarthy
on
Reason: typo
Standard actually says that search order is implementation defined. Every compiler can do whatever they want. So this is not specified in standard. Each compiler decides on its own what does that mean.
Afaik for GCC/Clang bracket include first looks up in paths specified by -I argument, then in folders specified by -isystem argument and then in other system specific places (configured at gcc compile time).
For quoted includes it first looks up folder where the file that has the #include statement is, then in folders specified by -iquote argument. If it doesn't find it there, then it tries to lookup in same way as for bracket includes.
For MSVC bracket includes first look up in /I argument, then in INCLUDE environment variable. Quoted include first look up in the folder where the file that has the #include statement is, then they follow bracket include order. Typically IDE or vcvars bat file sets up INCLUDE env variable for you (it contains C/C++ runtime headers and OS headers like windows.h).
There are other minor differences between MSVC and gcc/clang - for example, with relative paths. It's very tricky. Here's a video from LLVM 2015 conference that mentions it: https://youtu.be/rXi065XC6zY?t=753 (description has slides, page 35).
OSX has additional fun with framworks - you can add them with "-F" which also modifies include path. Complete bananas.
And there is no single convention what people use. Some people use quoted includes for your own application/library and brackets for everything else (system includes, C/C++ runtime, third-party system library like libpng). Some people simply use quotes for everything, and that also works.
Afaik for GCC/Clang bracket include first looks up in paths specified by -I argument, then in folders specified by -isystem argument and then in other system specific places (configured at gcc compile time).
For quoted includes it first looks up folder where the file that has the #include statement is, then in folders specified by -iquote argument. If it doesn't find it there, then it tries to lookup in same way as for bracket includes.
For MSVC bracket includes first look up in /I argument, then in INCLUDE environment variable. Quoted include first look up in the folder where the file that has the #include statement is, then they follow bracket include order. Typically IDE or vcvars bat file sets up INCLUDE env variable for you (it contains C/C++ runtime headers and OS headers like windows.h).
There are other minor differences between MSVC and gcc/clang - for example, with relative paths. It's very tricky. Here's a video from LLVM 2015 conference that mentions it: https://youtu.be/rXi065XC6zY?t=753 (description has slides, page 35).
OSX has additional fun with framworks - you can add them with "-F" which also modifies include path. Complete bananas.
And there is no single convention what people use. Some people use quoted includes for your own application/library and brackets for everything else (system includes, C/C++ runtime, third-party system library like libpng). Some people simply use quotes for everything, and that also works.
Edited by Mārtiņš Možeiko
on