i'm trying to solve the following issue with VS Code and the C/C++ Extension from Microsoft.
The mentioned Extension adds a reference count above every function/object definition in the source code. That's a helpful feature so far, but for me it doesn't work as intended I think.
In my example I started implementing a thread-safe linked list to practice (please ignore the code, thats not what this topic is about). The whole class is greyed out although I import the header-file and instantiate an object of that class in the main.cpp file in the main-function. Also, the whole main function is greyed out because no references to the main-function are found. That makes no sense to me, why would I ever reference the main-function in my code? It's the entry point to the program and shouldn't be referenced in my project source code afaik.
When I disable the C/C++ Extension, the reference counts are gone and the source code is highlighted again. But I would really like to keep the reference count and only get rid of the greyed out code (or make it work properly so that main function and definitions I reference in my code are not greyed out).
Also by disabling the extension, code auto completion is gone. So that's not a good trade.
I spent hours of reading the configuration and searching the web for solutions, but I couldn't find anything helpful.
The only thing slightly realted to the greying out of code I found is the option "Dim inactive regions" found in the C/C++ Extension's setting. But it didn' solve my problem.
Thank you in advance for reading/trying to help!
Example of greyed out code and reference count:
greyed out main function because of 0 references to main:
Dim inactive code option:
Update:
So it turned out that the reference counter not only disappears when I disable the C/C++ extension but also when I disable the TypeLens extension. That does not solve my problem but at least I can get rid of the greyed out code by disabling TypeLens and still use the auto completion the C++ extension provides.
Possibly you should declare your main function with
int main(void)
or
int main(int argc, char * argv [])
As I mentioned in the updated question, the problem isn't realted to the C/C++ Extension. It is acutally the TypeLens extension that causes problems here.
The best solution I have found is to configure TypeLens to not grey out unreferenced code. This way I can keep the reference counter and the code completion feature from the C/C++ extension but prevent the source code from being greyed out by TypeLens.
To achieve this, you have to set the Typelens:Unusedcolor value from #999 to nothing (just delete the value).
Related
I'm using Rcpp to run C++ code using RGui (version 3.4.1) as a user interface. Quite often I make changes to the C++ code which compile correctly but cause errors (e.g. searching beyond the end of an array) when I run the relevant program in RGui, causing RGui to crash. This is aggravating because I have to re-open RGui, re-open my R script (sometimes with unsaved changes lost), set the working directory again, etc. before I can re-compile the C++ code and run the program in such a way as to find the problem or test amendments. Sometimes it promptly crashes again because I haven't fixed or bypassed the problem.
Is there some way to change the way Rcpp runs such that RGui returns an error message instead of crashing in these sorts of situations?
Briefly:
It is spelled Rcpp. Capital R, lowercase cpp.
Yes, don't have bugs :)
In general, 2. is the only viable answer. If you need a managed language, use R.
If the code takes your environment down, test outside the environment. Seriously. That is for example why I (co-)wrote littler and test "raw code" on the command-line: it can only take the command-line app down.
We do have a feature in eg RcppArmadillo to test for "out of bounds" vector access: use x.at(i,j) which will warn. See http://arma.sourceforge.net/docs.html#element_access
I don't actually know of a way to prevent this apart from more careful programming, and saving before execution. But having done this a few times I have discovered a way to get back at unsaved changes, (at least in windows).
When you get the pop-up that tells you to restart R, you don't do it. You open up task manager and right-click on the process and select 'Create Dump File'. Find this file in explorer and open it with some text editor.
They are very big, and full of all sorts of stuff, but if you use find function to search for some string you know to be in your script, then you can find all the unsaved work. You can then copy and paste this into another file to save.
If you use R-studio instead of R-GUI, it usually manages to look after your unsaved work better.
I am using Dev-C++ version 5.11. It has feature of code completion, but it is not turned on. I don't know how to do that because I am using Dev-C++ for the first time. Any help will be appreciated!
You need to go to Tools->Editor Options->Completion->The tab code completion and then click "Enable code completion" box
you can also change the delay with which the prediction will be made
Note: Its not going to predict variables names or function names. By the time i write this, it only predict things you put after the -> operator
It's not gonna show you the member functions inside your header file if you're calling the class member functions from another file. works if you use the class and main in the same file.
My man I have the answer
--DevC++ is an awesome IDE and I don't have any plans to move to any other IDE. So I found Intellisense in DevC++ and the best part YOU DON'T NEED ANY ADDONS OR PLUGINS it's just hidden in the DevC++ shortcuts. (I have been using Dev C++ NEWER VERSION so I dont know about the old version and I do recommend the new version found on sourceforge) so when you need Intellisense simply press Ctrl+Space. Yup That's it . Just try .U Can thank me later...................
I'm currently using Visual Studio Express 2013 for Windows Desktop. When debugging my program, I'm running into an odd issue. When mousing over a class variable, instead of showing the value of it, nothing pops up. I then tried creating a watch for the variable. Instead of finding the variable, the value displayed in the Watch window simply says: "class "class" has no member "variable name". Here is a screenshot to demonstrate what I'm describing:
http://i.imgur.com/6cAOb8S.png
As shown here, the variable m_lineProgramID's value is unable to be displayed in the watch screen. None of the variables that start with m_line are found in the local variables list, yet the line "m_lineProgramID = 0;" doesn't cause an issue. In addition, I tried adding the variable to the constructor's initialization list and initialize it to 0, which also does not cause an issue.
Edit: Just to add a little extra info. I am compiling my program in Debug mode as a 64-bit executable. I've made sure to get 64-bit versions of the libraries I use and have not had an issue running my program until now. Additionally, I renamed both the class and the header & implementation files. I now get a new error: http://i.imgur.com/TozmJZJ.png
Edit 2: I figured out the error that was causing the "Internal Error". I was storing my class in a std::map, and forgot to change the name when using std::make_pair to add an entry (although the class name was correct when I defined the map). This fixed the C1001 error I got and renaming the class and files seems to have fixed the original issue. If anyone could shed some light on why I had the issue in the first place, I would be extremely grateful.
When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )
alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg
Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking.
The simpler types of data (e.g. ints) (usually?) get their correct values shown.
Did this ever happen to you too?
This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?
Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).
Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.
Yes, i see this problem in my debuger, in my case its connected to Unicode vs NonUnicode.
Looks like your debugging symbols are incorrect.
Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.
If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.
A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?
It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.
One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.
I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.
This is a bug that has been in the Visual Studio debugger since forever and still occurs in Visual Studio 2019.
It is random.
Sometimes making a code change and recompiling resolves the problem, and sometimes it doesn't.
I want to set a breakpoint in unmanaged C++, in Visual Studio 2005, but I would like to ignore this breakpoint if the call stack is in a specific function. Is there a way to do this?
If you have a commercial edition of Visual Studio, you should be able to set a breakpoint early in the calling routine, then change its "When Hit..." behaviour to "Run a macro". You'll need to write a macro that programmatically disables the breakpoint in the called function -- use this as the macro to run. (Hopefully someone else can describe how such a macro can be written.) Then set other breakpoints on all exit points of the calling function, and change their behaviour to reenable the breakpoint in the called function.
If you have an Express Edition, you'll find that the "Run a macro" checkbox is greyed out unfortunately. In this case, if you have access to the source code for the calling function, I suggest the following:
Make a global int variable, bp_enabled, initially set to 1.
--bp_enabled on the first line of calling_function().
++bp_enabled at all exit points of calling_function().
Change the "Condition..." properties of the breakpoint in the called function to break only when bp_enabled == 1. (Go to Debug | Windows | Breakpoints, then right-click the breakpoint.)
A bit of a hack, but it gets the job done.
[EDIT: Fixed to work properly even if calling_function() happens to call itself recursively (either directly or indirectly)...]
You could put a DebuggerStepThrough attribute on the calling method, altho this will stop all breakpoints being hit on the calling method, rather than just the specific method
You could put breaks on all the lines that call your method in question (except in that one caller routine you don't want to stop). I can see this being difficult if the routine is called from a lot of places, or invoked in non-obvious ways.
Changing the code just for debugging seems like the easiest - if possible.
Update: OP initially didn't make it clear at the beginning unmanaged C++ was being used. So this answer is pretty useless now because it'll only work with managed code. That said I'll leave it be in case someone stumbles over it and finds it usefulor didn't know about JMC:
Whilst DebuggerStepThrough is still a valid method to prevent stepping into code there are times when you do want to step in. This means having to locate and comment out the DebuggerStepThrough attribute.
.NET 2.0 introduced a new attribute: DebuggerNonUserCode. This works in conjunction with the Debug Just My Code setting in Tools->Options->Debugging->General->Enable Just My Code.
If Enable Just My Code is checked then any method decorated with the DebuggerNonUserCode attribute won't be stepped into. If you do want to re-enable debugging of code marked with DebuggerNonUserCode periodically then just uncheck this setting. This saves some time having to locate and comment out code you'd normally not be interested in stepping through.
To use either attribute just decorate the methods of your choosing like this:
// The .NET 1.1 way
[DebuggerStepThrough]
public static void IgnoreMeAlways()
{
Console.WriteLine("Hello...where is everybody!");
}
//The .NET2.0/VS2005/2008 way. Use in conjunction with Debug Just My Code
[DebuggerNonUserCode]
public static void NonUserCodeSomeTimes()
{
Console.WriteLine("Longtime no see");
}