When I recently upgraded to Visual Studio 2010 Ultimate, I was pleased to discover the Architecture menu. I immediately jumped to the incorrect conclusion that I'd be able to ditch my less than satisfactory manual-creation UML software, and thus not have to keep wasting time keeping my code and UML in synch. I happily went away, starting on a new project, safe in the knowledge that I could put off the UML until later. I was disappointed therefore (as per this answer) to discover that whilst you CAN reverse engineer code to UML in VS2010, you can't do it with C++.
I'm wondering therefore if anyone can tell me whether Visual Studio 2012 adds this feature, as I cannot find any information on this topic - although I have read that VS2012 improves code generation from UML (i.e. the other way around).
I've installed Visual Studio 2012 Ultimate with Update 1, and can confirm that it does not provide C++ support for UML reverse engineering.
This thread, although it does not strictly answer your question, might help you.
Related
We recently migrated quite a large piece of software written mainly in C (some parts are C++) from Visual Studio 2008 to Visual Studio 2017. Most of the software originates from the 80s / early 90s.
While testing the new binaries we keep running into bugs caused by memory overflows. These memory overflows seem to have been in there forever but apparently never exposed themselves under older versions of the MSVC compiler. While it is good that they are found and fixed, it would be nice to know what causes these to be exposed now.
Did the memory management of Visual C change a lot between 2008 and 2017? Can anyone point me towards documentation on this subject?
The most relevant compiler option would be /GS, which is a buffer security check. This intentionally tries to detect the sort of problem you're describing, because these class of problems often end up as exploitable security issues. Crashing early is a better alternative.
So, I started programming in C++ moving from Java, Eclipse IDE. I use VS 2010 proffessional, I have it for free from DreamSpark.
However, I am very unhappy with its Intellisense, beeing far far worse than Eclipse (its C++ version) has. But almost everywhere on the internet I read that VS has great, superior Intellisense for native C++. So I want to ask, is there any way, some settings to change to make VS intellisense behave simmiliar to Eclipse? Or is there any other functionality in VS intellisense that compensate that?
To be exact, Eclipse intellisense does much better job guessing what object I want to create, suggests includes, generate keywords, generate few common for cycles etc...
I would not even as this question, but I found somuch possitive feedback on native C++ VS 2010 intellisense, so I have feeling I am doing something wrong... Thanks.
If you are writing managed C++ (C++/CLI) there is a post explaining that intellisense is not currently implemented here
As for alternatives you may like visual assist X.
This question has also been answered before on Stackoverflow. Please see below for some alternative answers and suggestions:
No IntelliSense for C++/CLI in Visual Studio 2010?
To get the dump file (for crashes) I am using the userModeProcessorDumper.exe. Now the question is how to read this file (to see the stack information). Regarding this I have couple of questions
Yes I know I can use WinDbg (related tools) to analyze the .dmp file. My question is - Can this be analyzed in Visual Studio? To be more specific - I am having Visual Studio Enterprise Edition 6 - In this particular pack - can the .dmp file be opened for analysis.
If Yes, Please help me with steps.
I see in web advice to use Visual Studio 2XXX version. So I am feeling that the same cannot be done using VS Enterprise Edition.
The application is built on MinGW, even these application - can we analyze in Visual Studio (what ever is the edition - i.e Visual Studio 2XXX or VS Enterprise Edition X.Y)? Should I take care of any additional setting for this.
Any material link on this topic would be very helpful to me.
Thanks a lot in advance for your advice.
PS : My application is a C++ based application.
From what I remembered, VS6 cannot be used to debug dumps. It's been a while since I last used it, and trying to verify me memory I came across a workaround that might allow you to debug those dumps after all: Visual C++ 6, and post-mortem (crash dump) debugging.
I don't have VC6 at hand, and have no idea if this really works. Other than that, I feel for you... There are IDEs so much better than VC6. Hope this inability gives you the push towards an upgrade. Debugging dumps is really easy with VC7 and above.
I would like to enable the IntelliSense 'auto' feature (like the Visual Studio C# 2008 Express) but I am using Visual Studio C++ 2008 Express Edition and in the Tools > Options > Text Editor > C/C++ (there is no option 'IntelliSense' (like Visual C#). How do I get this feature enabled? I know I can get a shortcut in place (CTRL-space etc...)? But how do I get it automatically (the drop down menu)?
In C++, IntelliSense is turned on by default (and AFAIK there isn't even an official way to turn it off). However, when you're coming from C#, you might think it's turned off, because it's so much less powerful in C++. (The reason for this is that C++ is much, much harder to parse. You can find more information on the subject here and here.)
Visual Assist improves C++ considerably (although it might not be all that considerably when you're used to C#), but I don't think you can install plugins in the express edition.
This should be enabled by default. But sometimes for C++ projects it stops working.
Is there a .NCB file in your project folder? If so, close your solution, delete that file, and then re-open your solution and do a rebuild.
I use VC++ 2008 Express Edition as my primary environment. All I can say is that sometimes Intellisense works wonderfully, sometimes it doesn't work at all. The Intellisense parser seems to be slow as can be and stumbles over a lot of cases, especially when templates are involved. Sadly, I just don't think you can count on it being consistently available.
One thing that sometimes helps when intellisense doesn't do what it should, is to delete the .ncb file in the project folder in order to force VS to rebuild the internal database (close VS before deleting the file).
We are considering switching from MS Visual Studio 2003 to MS Visual Studio 2005 for our C++ development. I think jumping to 2008 might be better.
In what ways are VS2008 better than VS2005 for C++ development?
Are there any disadvantages of VS2008 over VS2005?
There are very little difference between 2005 and 2008 from native C++ developer point of view. However, if coming from 2003, it makes sense to upgrade directly to 2008 - the conversion process should be almost the same, and you will end up with a slightly better platform. Some new features which are available for 2008 only:
/MP option for multicore compilation (a huge timesaver if you have a mutlicore computer)
some improved debugging options for multithreaded applications
There are also some additional downloadable feature packs for 2008 only:
TR1 libraries
new MFC
To be honest, as far as pure C++ development goes, I don't think there is much between the two, other than VS2008 is the 'latest' release. I didn't notice any significant changes.
However, the latest release of MFC has been given a new lease of life with the addition of the Feature Pack (giving you an MSOffice 2007 look and feel) which might be worth knowing.
The biggest improvement in 2008 for us was in reliability of Intellisense on large solutions. Our project has several million lines of code and Intellisense was unusable in 2003. In 2008 it is improved and works more often than not.
For me the biggest improvement was simply that VS2008 was quite noticeably snappier.
VS2008 contains loads of bugfixes, and is definitely worth the upgrade IMO. Aside from improvements in the UI and related tools, it is much better at dealing with template classes, which didn't always work so well with the VS2005 compiler unless you were using the most basic syntaxes. There are also many other areas which have been improved, but I can't be bothered to find a MS document at the moment detailing these changes. So trust me when I say that there are many. :)
I'd say unless you have some compelling reason to stick with 2005 (ie, backwards compatibility of your code which doesn't build correctly with VS2008), you should definitely push for an upgrade. You can, fortunately, work with multiple versions of VS on a single workstation. You just need to install them sequentiall; ie, VS2005 first, and then VS2008 afterwards.
Then you could test your codebase under VS2008 and see how painful (if at all) a migration to VS2008 would be.
Visual Studio 2008 is an integrated environment that allows you to develop for both Windows CE and Windows. (Previously we had to work on eVC++ 4.0, which was not as nice...)
A disadvantage that I encountered is that the latest installment of the Dinkum STL containers make an assumption that pointers are used, rather than the using allocator::pointer policy. This is a problem for us, because we wrote our own "pointer" class for shared memory use (storing memory offsets instead of absolute addresses). So, we had to use an older STL library. On the upside, the debugger is able display the contents of STL container much more informatively.
I currently use VS 2005. I tried the last beta of VS 2008, and the compiler consistently crashed on my projects, so I stuck with VS 2005. I haven't looked at the release version.
One big reason to choose VS 2008 over VS 2005 is that VS 2005 has a bug with intellisense that causes it to use too much memory. This isn't normally a problem, but when I try using both Visual Assist and Refactor! C++ in VS 2005, intellisense churning brings my system to its knees. This is supposedly fixed in VS 2008. (I have a license for VS 2008, and as soon as my next product release I'm going to give migration a try, mainly for this reason.)
Visual C++ 2008 have dropped support for single threaded runtime library. I don't think it really matters though.