I have exactly the opposite problem to VSCode turn of _WIN32 define - Visual Studio Code is failing to define _WIN32 for me. This is in a cross-platform project that is being developed on Windows with the Microsoft compiler, but needs to also be able to compile on Linux, so I have
#ifdef _WIN32
#include <windows.h>
failing, and VS Code then marks all references to Windows API types etc. with red underlines. (The include mechanism itself is working fine, e.g. it has no problem including regular C++ headers.)
Is there any known reason why VS Code on Windows might fail to define _WIN32? The question I linked suggests it should, and I haven't knowingly changed any settings related to it.
Most likely, the problem is VSCode is using the wrong C++ compiler to gather the predefined macros, and that compiler does not predefine _WIN32.
To check, in Command Palette (Ctrl+Shift+P), run "C/C++: Log Diagnostics". The output will show you which compiler VSCode found and what it detected as its built-in include path and preprocessor defines. If my guess is correct, the diagnostics will show the wrong compiler being used, and _WIN32 missing.
Assuming so, to solve this, use the command Palette to run "C/C++: Edit Configurations (UI)", then set "Compiler path" to point at your compiler executable (cl.exe in this case). That should solve the problem because VSCode will then query that compiler to determine the predefined macros, which will include _WIN32. Re-run the diagnostics to confirm.
(I just gave a similar answer to the question linked to in the question above, as I think both questions have essentially the same problem and solution, just with different details.)
Related
I am using Visual Studio 2013 to write code for AVR. I have been following this tutorial.
Whilst writing the code, I noticed that Visual Studio kept on underlining things like DDRB or PORTB and I keep on getting errors like Error: identifier "PORTB" is undefined, however, the program compiles correctly.
Interestingly enough, upon pressing alt-F12 Visual finds numerous files where they are defined.
Your Makefile runs compiler with an option -mmcu=YOURCHIP. This implicitly defines macro corresponding to your chip. For instance for atmega32u4 the macro is AVR_ATmega32U4. Intellisense is run 'outside' of your compiler so it's not aware of this macro and when parsing standard avr header - like avr/io.hit skips the proper inclusion of header file for your particular MCU. It's something like:
#elif defined (__AVR_ATmega32U4__)
# include <avr/iom32u4.h>
So, if you want to have intellisense support for stuff defined in those headers you might need to define that macro, at the top of your source, like this:
#define __AVR_ATmega32U4__
#include <avr/io.h>
int main() {
char a = PORTB;
}
You may find what macro corresponds to which MCU in the middle of this page
i would suggest to simply use the original IDE as Make-File generator and just call that makefile from the VS2013. This has the overhead for maintaining two different projects (but mostly actions that require changes to makefile are rare) but leaves the comfort of the good VS IDE and leaves you the way back to original IDE for debugging.
you also have to set the include directories in the vs2013 project settings to get the intellisense work.
I'm working on a C++ project (VS 2010) using CPLEX.
I have included the required cplex libraries in the project settings as follows:
added the "additional include directories" under C/C++ > general
added the "additional library directories" under linker > general
added the .lib files as "additional dependecies" under linker > input
Everything compiles fine, however my problem is that intellisense still reports errors (red squiggly underlines) such as "cannot open source file" in the #include line, and "identifier undefined" when using variable types defined in the CPLEX library.
The only difference with other projects that don't have this behaviour is that this time I have used windows environment variables in setting the include path, i.e. the library directories and include directories are defined similar to: %CPLEX_STUDIO_DIR%\cplex\include
I have set it like this so that I can build this project on different machines without messing around in the project properties. Since CPLEX is installed separately, using relative paths to specify additional directories is not really an option.
I'd like to repeat that the project compiles, it's only the intellisense errors that are bothering me.
I know I can turn off the intellisense error reporting, but if someone has a workaround for this I'd love to hear about it.
Kind regards,
This problem is known to Microsoft:
http://connect.microsoft.com/VisualStudio/feedback/details/779874/intellisense-cant-handle-using-environemt-variable-in-include-path
The only way I know of to avoid it is to manually enter the full literal path. The bug is marked "deferred" which I think means Microsoft has regarded it not serious enough to be fixed soon.
The solution is to replace %CPLEX_STUDIO_DIR%\cplex\include with $(CPLEX_STUDIO_DIR)\cplex\include. This is the syntax Visual Studio uses for its built-in variables such as $(VCInstallDir), but it also works for environment variables (so long as they don't have the same name as a built-in variable) and is recognised by intellisense as well as the compiler.
(I realise this is an old question, but it ranks highly in search results so it could help others even if not the original poster.)
I am porting code from Solaris to Windows Visual Studios. To make the code compatible with both, I am using statements such as #if defined (Win32) and #ifdef(OSTYPE_solaris). I found where Win32 is defined, but I cannot find where OSTYPE_solaris is defined. I am thinking that I may not find the definition of it because I am looking for it on Visual Studios, and the header that defines OSTYPE_solaris is not available on Visual Studios. Am I correct in that assumption? If so, does anyone know where OSTYPE_solaris is defined? I googled it a bit, but I was not finding luck with this question. I am also having the same conundrum with OSTYPE_linux.
My guess is they are defined by compiler itself. If Solaris is using gcc as compiler, you could check compiler defined variables like this:
echo "" | gcc -E -dM -
But i think you should not ifdef by platform in most cases, it is better to use feature based defines like HAVE_SOCKET_H. But that requires much more work on multiplatform build system providing these defines and you may not need them.
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.
I usually like to have a lot of warnings enabled when programming. However, some libraries contains code that easily causes warnings (.., python, Qt, ..). When compiling with gcc I can just use -isystem instead of -I to silence that. How can I do the same with the MS compiler? I know of the warning #pragma, but I would like a solution that does not involve compiler specific code all over the place. I also know that I can turn off specific warnings, but that is not what I want either.
BTW: isystem should be a tag of this question, but I was not allowed to do that..
SUMMARY: I want to see all warnings from my code, and no warnings from external code.
As of 2017-08-17 this still seems impossible.
I added a feature request here:
https://developercommunity.visualstudio.com/content/problem/96411/impossible-to-ignore-warnings-from-system-librarie.html
Update 2018:
The issue is now closed as fixed and is available in the standard MS VS installation [source].
A blog post from the MS team goes through the new features [here].
The solution from MS is flexible. You can not only differentiate using paths like you do with --isystem, but for example also by whether you use #include "" or #include <>. The blog post is worth a read to see all the various customization points.
This now exists under /experimental:external /external:I system_include_path /external:W0. See https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/ for many more details.
No clue why MS never picked this up.
We can only try voting on https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/14717934-add-a-cl-exe-option-for-system-headers-like-gcc-s
No, MSVC doesn't have an -isystem equivalent.
look at the output output from cl /? :
/wd disable warning n
/we treat warning n as an error
/wo issue warning n once
/w set warning level 1-4 for n
Note that this disables the warnings for your entire project; I remember when using Qt I'd rather change it's main header with the #pragma warning disable and enable at the end again so I could still see all warnings for my own source.
Edit the author edited his question, updated answer: there is no way to get your code with warnings and Qt code without warnings using compiler flags: how are you going to tell the compiler what is 'your' code?
Note that the above flags can be applied at file level as well, so this would allow you to disable the warnings for only those files in which you include Qt headers, but that still means you cannot see them for your own code in that files.
So I stay with the answer above; it is not quite pretty, but I'm pretty sure it's the only way: use #pragma at the beginning and the end of the Qt header(s). Either change the Qt headers (even more ugly), or choose a less invasive way like this:
//your source/header file
#include "shutuppqt.h"
#include <QString>
#include "enableallwarnings.h"
example "shutuppqt.h"
#ifdef MSVC
#pragma warning ( disable : 4222 ) //or whatever warning Qt emits
#else
//....
#endif
example "enableallwarnings.h"
#ifdef MSVC
#pragma warning ( enable : 4222 ) //or default instead of enable
#else
//....
#endif