In a way this is a duplicate as the question some questions have been asked about the watch window not working under DIFFERENT VERSIONS OF THE SOFTWARE, but not under 2017 so I ask afresh.
My app C++99 and it's using a library I've written part C (C89) and part C++99. It all compiles and links without warning.
A C file has a global variable, declared extern in its header, of structure type.
When I put a breakpoint in the file with that structure, it appears in the variable watch window as having all-zero contents, despite the function clearly changing variables in it and reacting to those variables.
Other variables, including other file-scoped variables (a static int) display fine, though.
The only unusual thing about this variable is that C++ modules are including the .h file, and I had to put the extern for the variable into the extern "C" block along with the C functions. I tried a conditional compile so that this compilation unit wouldn't see the extern, but that didn't help. However, if I simply add a second structure named msDecoy to the variable definition, Visual Studio can now see the contents of the first variable. (msDecoy is referred to nowhere in the software.)
MyStruct_T ms, msDecoy;
I've used Visual Studio since 6.0 for a total of say 3-4 man-years, and used 2017 for man-months of work. I've programmed C/C++ surely 25 man-years at this point. That is to say, it's not basic unfamiliarity with C or the debugger that is the issue.
I assume it's a Visual Studio bug, but does anyone have an alternate explanation or a better workaround?
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.
The problem: My syntax highlighting and IntelliSense are broken. I have a C++ source file like this:
#include "stdafx.hpp"
#ifdef SOMETHING
do_some_stuff;
#endif
where stdafx.hpp (the precompiled header for the project) includes a .h file that says:
#ifdef DEFINE_SOMETHING
#define SOMETHING
#endif
and DEFINE_SOMETHING is defined in the project properties for the project (under C++ / Preprocessor).
Visual Studio is losing track, and displaying do_some_stuff; (which is actually lots of lines of code) in plain grey - I have neither syntax colouring nor IntelliSense.
The question: How can I either make Visual Studio get this right (unlikely) or switch off the fact that it's greying-out code that it thinks is #ifdef'd out?
(Rearranging the code is not an option - it's a large and complex system whose files are built in various environments, Visual Studio being only one of them. I'm using Visual Studio 2005, but I'd be interested to know whether this is fixed or workaroundable in a later version.)
If someone still interested - to turn off graying out #ifdef:
Go to Tools -> Options
Open Text Editor -> C/C++ -> Formatting
Uncheck Colorize inactive code blocks in a different color
In VS19, it's Tools / Options / Text Editor / C/C++ / View / Inactive Code / Show Inactive Blocks.
Following previous answer of aousov I check my VSCode and found this setting:
C_Cpp: Dim Inactive Regions
Controls whether inactive preprocessor blocks are colored differently than active code. This setting has no effect if IntelliSense is disabled or if using the Default High Contrast theme.
in Extensions / C/C++
This may be related to the version you are using (in my case 1.46.1).
Best,
Geoffroy
The problem you describe is par for the course in VS 2005. It is fixed in Visual Studio 2010 and later due to the completely redesigned Intellisense system. This is not directly applicable to your problem, but here's some info on the underlying architecture: http://blogs.msdn.com/b/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
There are some things you could try, and some project structure changes that can help minimize the problem's frequency, but whatever you do will be hit or miss, and the problem will eventually resurface again regardless. The only real solution is to use a newer IDE.
You can continue to use the VS 2005 build tools by installing VS 2010 along with Daffodil (http://daffodil.codeplex.com), then build your projects with the v80 platform toolset in VS 2010. This makes the migration fairly straightforward, with no need for any source code changes.
Since #define SOMETHING is defined inside stdafx.hpp, indicating that it's always defined since DEFINE_SOMETHING is defined in project configuration, would it be out of the question to also define SOMETHING explicitly in project configuration?
I used to have similar issues in VS2005 and 2008, and redundant explicit definitions sometimes helped.
I fixed this (in VSCode) by changing C_Cpp.default.intelliSenseMode
"C_Cpp.default.intelliSenseMode": "windows-gcc-x64"
I am building an ARM project on a micro-controller. Its not 64 bit either. But this does parse the directives correctly.
For Science I tried Widows-gcc-ARM and that also correctly lit up the regions that are truly active. I also know for a fact that gcc is setup and configured on my windows machine, and while I have clang and msvc, I dont use them and dont know that they work- so it could be why gcc works better for me.
You can experiment with this setting, but I am fairly certain the resolution resides in this option.
I do not know the equivalent VS option, I am sorry.
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.
When dynamically referencing assemblies in .fsx using #I and #r, VS highlights the following usages of imported types and writes "The namespace or module 'XXX' is not defined". Is it ok?
For example, in the following code
#I #".\Tools\FAKE"
#r "FakeLib.dll"
open Fake
Target "Hello" (fun _ -> trace "hello!")
Run "Hello"
VS highlights Fake and says "The namespace or module 'Fake' is not defined", it also highlights Target and Run. I have this problem in VS 2010 SP1 and in VS 11 CTP. This issue makes writing F# scripts a bit harder task than it could be.
By the way, IntelliSence for "common" types works well. FakeLib.dll and FakeLib.xml are present in the .\Tools\FAKE directory. The code runs well.
Update 1
Here's the screenshot of the situation. You can see that VS resolves assembly FakeLib correctly (in a tooltip), and that at the same time Intellisense "see" standard types (tooltip over Console) class.
Update 2
I think there's something wrong with the IntelliSense on my work workstation, because it (IntelliSense) behaves itself quite strange. When I start VS and open .fsx file, IntelliSense refuses to resolve even standard types/classes, and it doesn't underlines FAKE classes, it does nothing. But after some period of time and some manipulation over code IntelliSense starts working for standard types and underlines FAKE types.
Moreover, when I've created the similar code on my home workstation there were no problems, IntelliSense works as it should.
If you put the full path into the #r directive, you'll get full IntelliSense. The #I directive, while convenient, prevents IntelliSense from working properly though the code will run just fine. This is true for both loose scripts and those found in projects. Have a look at Tomas Petricek's [FSharp.AsyncExtensions](http://github.com/tpetricek/FSharp.AsyncExtensions] project.
No, that's not how it works. Does your code run? Intellisense is provided for assemblies referenced using #r.
At the moment CUDA already recognizes a key CUDA C/C++ function such as cudaMalloc, cudaFree, cudaEventCreate, etc.
It also recognizes certain types like dim3 and cudaEvent_t.
However, it doesn't recognize other functions and types such as the texture template, the __syncthreads functions, or the atomicCAS function.
Everything compiles just fine, but I'm tired of seeing red underlinings all over the place and I want to the see the example parameters displayed when you type in any recognizable function.
How do I get VS to catch these functions?
You could create a dummy #include file of the following form:
#pragma once
#ifdef __INTELLISENSE__
void __syncthreads();
...
#endif
This should hide the fake prototypes from the CUDA and Visual C++ compilers, but still make them visible to IntelliSense.
Source for __INTELLISENSE__ macro: http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx
You need to add CUDA-specific keywords like __syncthreads to the usertype.dat file for visual studio. An example usertype.dat file is included with the NVIDIA CUDA SDK. You also need to make sure that visual studio recognizes .cu files as c/c++ files as described in this post:
Note however that where that post uses $(CUDA_INC_PATH), with recent versions of CUDA you should use $(CUDA_PATH)/include.
Also, I would recommend Visual Assist X -- not free, but worth the money -- to improve intellisense. It works well with CUDA if you follow these instructions:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=5481
http://forums.nvidia.com/index.php?showtopic=53690