Related
I recently downloaded the Visual Studio 11 Developer Preview, and it looks awesome. I read the fine print on the download page, and it says:
Visual Studio 11 Developer Preview is prerelease software and should not be used in production scenarios.
I would be using only the C++ compiler/IDE of VS11, so does anyone know what bugs there are that would prevent me for using VS11 in a production scenario? I really want to start using it and I don't know if it's the C++ part that's not finished, or if it's just some Team Foundation Somethingorother that has nothing to do with me that's not fit for the field.
The licence prohibits it. The WinDP and the associated vNext tools are free- Microsoft would obviously want you to pay. When you download the tools, you agree to the licence terms, which includes not using it in production.
Another obvious thing is that the C++ Intellisense is more than a tad buggy.
There is still work to be done before I would want to use the preview tools all day. The Metro stuff (C++/CX) especially is riddled with red-wigglies that claim something is wrong, but when you press F7 the solution builds without errors and runs fine. If you're using the Ultimate version, you may not find that as often, but I think you will find it. As for whether the compiler currently generates code that is incorrect, everyone hopes that it emits correct code, but of course the WHOLE POINT of the dev preview is to find out whether it does or not. So nobody can answer you. Spending some time on Connect looking at bugs others have submitted might give you a feel for whether your areas have a lot of bug reports against them. An absence of reports is ambiguous, of course -- maybe your areas are rock solid, maybe no-one on Connect is exercising them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As we are (me and people I work with) more and more frustrated while working with C++ projects 250 000+ LOC in VS2010 sp1 (the slowness of this IDE is just unbelievable), in my company we were talking about migrating our code to some different IDE. We did some research, and a strong candidate seems to be Embarcadero C++ builder 2011 XE. Any thoughts on it? Is it any good? How does it compares to VS2010 ultimate?
I've been using C++ Builder since 1.0 and I hate it with a passion. You would think after all these years, simple little annoyances would be fixed by now but they are not. Here is a list of issues I have with C++ Builder IDE.
Your layout or personality never is maintained. You create one, save it and it only applies to certain things. For example the debugger window will not maintain its position nor will the message window. If you detach the project explorer it will sometimes dissappear. Most of the time reloading your personality doesn't fix this either. You are stuck dragging your windows back into place.
The debugger will sometimes work and sometimes not work. In a debug build if you set a break point and begin stepping through code, you can hover over a variable to inspect it. Sometimes this works and sometimes it doesn't work on the exact same variable. Crazy!
Eclipse looks for code mistakes like if you forget to put a semi-colon at the end of your statement, it puts a little ? mark in the margin. C++ Builder doesn't do anything like this. It gives you a cryptic compile time error message.
Recent versions of C++ Builder use a makefile similar to VS; it's an XML mess. Eclipse works with CMake and Makefiles. I've read in places that the CMake maintainers are looking for a C++Builder generator but last I checked this doesn't exist. I do embedded and cross compiling so sometimes my C++ Builder code is copied to my embedded development environment or shared with it and I wind up maintaining two build environments.
Not really an IDE but C++Builder does not take advantage of multiple CPUs to compile code. There is, however, a 3rd party tool you can spend more money on to get this. It's called TwineCompile (http://www.jomitech.com/twine.php). With Eclipse, they call out to whatever compiler you're using (gcc, etc...) and those compilers and make support -j option.
C++Builder comes with a limited version of AQTime which is a dynamic code profiler. Spend more and you get the more advanced version. Eclipse supports many dynamic and static code analysis (which also cost $$) but at least the plugins are there. We use Klockworx.
C++ Builder has no support, that I'm aware of, for external source control like GIT. Eclipse does. C++ Builder comes with subversion, I think, built-in. If it supports GIT, I could never get it to work. It tells me it doesn't understand the URL scheme when I give it a git path.
Certain template code I write causes the compiler to segfault and have to completely restart the IDE. This is nuts to me. You have a compiler that is 10+ years old and it's still segfaulting. I have a piece of C++ template code that when I take it to my work computer running exact same version of C++ Builder, it compiles OK, but on my home machine it segfaults. I'm absolutely sure there are no adverse factors at play like viruses, etc...
While compiling a large project that may take a long time, you are unable to browse code with the IDE. Sometimes you may see a compiler warning scroll by and you have to either wait for the compile job to complete to inspect the mentioned line or use an alternate means to open the file.
C++ Builder IDE has a concept of a Project Group with sub projects that are more/less self contained. The Project Group has no concept of a project group include/link path like the sub-projects have. Sub-projects have a base, debug, release paths where debug and release can inherit or block from the base but you don't have this at the project group level. The IDE has global settings which can be inherited but it's for everything you do in the IDE. So there is no way to modify for a given project group, just the include/linker paths for a set of sub-projects. I just think they could have done a better job with this.
C++ Builder's Build output is not color coded to, for example, show errors in red and warnings in some other color. Everything is black and white. VC and Eclipse color code and give option to change colors for various warnings and errors. The output tab in C++ Builder is same way. On big projects, it's very difficult to investigate compiler warnings with the other noise. In C++ Builder's IDE you can select level of warnings but this only affects output in the Output tab and you still get other stupid noise like letting me know its deleting linker state files "CleanLinkerStateFiles."
Unless you're doing Windows desktop GUI development, stay away from Embarcadero/C++ Builder. I started using C++ Builder version 1 back in the Borland days and have a few large projects that are heavily invested in the VCL so I'm stuck with it for those projects but all my new projects, I've been using Eclipse.
On a positive note about C++ Builder, the VCL is quite nice. It's not multi-threaded but it's nice for creating a desktop GUI app really quick. I think it's much faster to get a C++ based GUI app up in CBuilder than it is in VS. And there appears to be a ton of free and paid GUI components for CBuilder; again with a C++ focus. I know C# + VS has a wealth of GUI controls.
UPDATE:
I just ran into a problem today that is same as the one mentioned in this forum:
http://qc.embarcadero.com/wc/qcmain.aspx?d=57631
[ILINK32 Warning] Warning: Error detected (ILI4536)
Make up your mind. Is it a warning or a god dam error?
Scroll all the way to the end where you find individuals modifying ILINK32.EXE to get it working again. As of this morning, our builds stop working. We're dead in the water as we scramble to understand and find out what to do about this.
Is this the kind of compiler/IDE you want to depend on? Again, this product has been around for more than a decade and it still has issues like this. I find this completely unacceptable. Crap product from a company that doesn't give a shit.
Not actually an answer, but I'll just leave it here:
It costs money (yes, VS too, but you already own that, don't you?)
It will be not too easy to migrate a big enough project to new IDE (and compiler), not to say about the people you work with and their habits (I would just quit probably).
There's a new compiler too, with its brand bugs and caveats to learn about. And it's much less widely used than VC++. However, it's based on Clang, which should support standards better than VC++, and be easier to port existing C++ code to.
The difficulty of migrating hugely depends on the nature of your project (is it GUI based, how deeply does it rely on MS VC++ being the compiler?)
There is nothing positive about Embarcadero XE, neither their aging IDE neither their aging compiler. Only use it if you're bound to it (legacy software) or if you want to do Delphi.
For C++, do yourself a favor and join 21st century : stick with something more powerful, versatile and modern such as VC++ or Qt.
This question is really a matter of personal opinion.
I personally HATE Visual Studio with a passion, I avoid it like the plague. My exposure to Eclipse has been limited to Java, but even then I've had a hard time working with it.
I have been using C++Builder for 15 years, since v3.0 all the way up to the latest XE6. Yes, it has quirks and limitations, but I still find it the easiest IDE for me to work with and be productive with, once you know how to work with (or around) them. Maybe my experience with it is hindering my ability to work with other IDEs, but so be it. I still prefer C++Builder over any other. But I only use it for Windows development (the VCL is very mature and robust), I don't do cross-platform development with it yet (FireMonkey still has a ways to go to evolve and mature). And I do use plenty of open-source projects with it. Yes, sometimes I have to tweak their projects and/or code to make them compile, but that it usually a one-time deal and then they work fine.
I'd suggest Eclipse.
As an IDE, it takes a little while to get used too, but it is well
worth the effort.
It's available for Mac OS, Linux and Windows.
You need to have Java installed on your computer, but that's
really a non - issue.
It supports Cygwin, MinGW, and the MicrosoftVisual C++ toolchains. The build in CDT Builder is pretty good too.
You can use it to develop for languages other than C++ (Java , JavaScript, PHP ..)
You can extend it's functionality by installing plugins
IT'S FREE!
Did I mention that it has a built in Web Browser ? Really useful for referring to online documentation, while coding.
1.
We have a solution over 1M LOC and VS2010 handles it ok. We especially like /MP switch for compiling on all available CPU cores.
You did not specify your hardware. If you don't yet run on at least i7-2600 + fast SSD, I suggest trying hardware upgrade first.
2.
I used to use Borland tools a lot in the past. Delphi was rather stable; C++ Builder was much more buggy. Couple of years ago I helped to upgrade old Delphi projects to newer Delphi IDE with some service packs installed. And it had bugs even in the basic File IO APIs which have worked since Turbo Pascal. We had to downgrade to a previous version. I expect that quality of C++ Builder won't be much better than of VS2010.
3.
You did not specify what exactly is slow. You may want to convert some projects into components compiled separately. Also make sure you use PCH.
Also it worth investigating if you abuse C++ inclusion model by including a lot of unneeded header files in each and every unit. If, after preprocessing, Intellisense and compiler have to deal with huge amount of code, no IDE can help.
I have not used Visual Studio 2010 Ultimate for C++, rather C# and C# web services development. That being said, as a test between VS 2010 Ultimate and C++Builder XE, I have created a simple VS C++ Windows Forms application to click a button and show "Hello World" through an event handler. Getting the button onto the VS Window Designer is okay, as long as you remember to access View | Toolbox. If not, it will take some time to track down where the visual components are hanging out.
For reasons that do not make any language sense, the button click event handler has a signature that looks like:
System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
}
and it goes to the header file as one would expect. The ^ symbol makes little sense. Does using it tie into the CLI/CLR better? I expected a * to indicate a pointer.
After using the default Form1 (only header file created) and subsequently adding a new windows form, I finally obtained the respective cpp file. Maybe the C++ Windows Form Wizard has a bug. Who knows? Anyhow, when adding the button click event by double clicking the button in the designer, the cpp does not obtain the method in either cpp form I tested. Maybe this is normal, I do not know. The end result of this is that after trying to use the MessageBox function within the cpp, it only caused compilation errors. I am sure there is yet another header file that has to be in the include path. I spent no time tracking this down. Trying to set a label component text property caused compilation errors too. About 20 minutes later, I went to C++Builder XE3 in frustration.
In C++Builder, I have tested VCL Forms, FireMonkey Desktop, and FireMonkey Metropolis application creation from the project wizard. Sure enough, I have three different applications saying, "Hello World," in about three minutes total, all calling C++Builder's built in global shortcut function called ShowMessage("insert message here"). The timing could have been slightly different as I did not time it with a stop watch. It took longer to save files with meaningful names than the code itself: one line of typing in the respective click event body in each cpp (not the header).
The other main daily use gotcha with VS, for those of us who love the Brief key map, is that VS is highly challenging to configure into Brief. When doing heavy development in C#, I use C++Builder's editor in Brief mode, saving files as often as I want. VS does correctly detect file updates as you click back to the VS IDE.
On the slowness mentioned by the OP above, I suggest also looking very closely at the hardware platform relative to running Visual Studio. I have noticed that if the .Net framework is out of date, VS will be slow within the IDE. It does not seem to matter which language the project is in either. I use Visual Studio 2010 Ultimate on Parallels with Windows XP Pro, with 2 virtual cores. Generally, VS responds normally within the IDE. While using it, I am NOT thinking, "VS is soooo slow."
Regarding migrating a quarter million lines to C++Builder from VS, I am not sure whether VS event handlers will convert by some wizard or other migration tool. The ^ symbol, if consistently used in all event handlers, may not be a big deal for a regular expression conversion that is custom written. If the project is very thin on the user interface layer and heavy in business rules and data, converting to C++Builder should be relatively easy. I would expect some new coding for the new user interface click events passing the user interaction into the other layers. For prototyping, using data aware components are likely your best bet. In normal application running, expect to have the business rules layer use the STL and built in C++Builder data structures (even the AnsiString c_str() method) to interact with non data aware components. The performance and user experience will likely improve.
Start Edit
A big knock on C++Builder XE3 (note this is two releases behind the current one of five) is that the 64-bit Windows support is only for console applications. The knock is more from not being frequently broadcast on how to use the Add Platform sub-menu that appears when right clicking the mouse over the Target Platforms choice in the Project tree view. This quick method to add more platforms to a project after it may first be targeting 32-bit Windows is virtually painless. A new sub-dialog appears after clicking the sole sub-menu choice and a drop down box appears to select the new operating system and respective 32-bit or 64-bit versions. In my opinion, Embarcadero is not demonstrating often enough how simple it is to add other target platforms. So, to ease all developer's pain if this is not known in advance, I have found three web pages on the Embarcadero site. The first one has pretty pictures of creating a FireMonkey desktop application. Step 5 has the screen capture of the Target Platforms | Add Platform sub-menu choice for adding the Mac OS X platform. It is here titled Creating Your First FireMonkey Application for Desktop Platforms (C++): http://docwiki.embarcadero.com/RADStudio/XE2/en/Creating_Your_First_FireMonkey_Application_for_Desktop_Platforms_%28C%2B%2B%29
The more terse and no picture procedure is here titled Steps in Creating Cross-Platform Applications:
http://docwiki.embarcadero.com/RADStudio/XE2/en/Steps_in_Creating_Cross-Platform_Applications
The Windows centric procedure and a small screen capture is here titled 64-bit Cross-Platform Application Development for Windows:
http://docwiki.embarcadero.com/RADStudio/XE3/en/64-bit_Cross-Platform_Application_Development_for_Windows
I have found on an Embarcadero forum post that an upgrade to the Update 1 XE3 release from the original XE3 release has a Target Platform selection issue. There can be an internal path setting or two that is incorrect, and possibly having to change an original XE3 project file (.cbproj) to enable Win64. Apparently the original release project file has this set to false.
XE5 (note version five as of December 2013) is supposed to have 64-bit Windows support for both console and forms applications (e.g. VCL, FireMonkey Desktop, FireMonkey Metropolis), OS X, iOS (Android coming sometime soon). For the complete list, review the C++Builder feature matrix pdf for all of the XE5 details:
http://www.embarcadero.com/products/cbuilder/cbuilder-feature-matrix.pdf
Since the XE3 Update 1 has been shown to resolve Target Platform selection issues, when compared to the original XE3, there should not be any weird behaviors. I have also come across an Embarcadero post that states from a TeamB member that for mobile applications, the Target Platform choices are filtered such that mixing a desktop platform project with a mobile one is not allowed. So, if one wanted to try creating a desktop application and then with a mouse click force it into an iPhone, some other development tool will have to be used. C++Builder and/or Delphi will not attempt to squeeze desktop components onto a mobile device. You have to start with a mobile application project. Here is the forum link:
https://forums.embarcadero.com/thread.jspa?threadID=96371
(End Edit)
If curious about my overall background, I have used C++Builder since version one, Visual Studio .NET (C# 1.0) and Visual Studio 2010 Ultimate. It seems like Visual Studio concentrates on C# more than any other language. There are eighteen C# projects and fifteen C++ projects when selecting File | New Project. To reach the Visual Studio C++ project area, make sure to reach it by opening the "Other Languages" sub-tree.
In recent Internet posts between Visual Studio latest and greatest and C++Builder latest and greatest, purchase prices vary in the thousands of dollars. Even if never ever having an installation to upgrade either tool, C++Builder remains a bargain compared to Visual Studio. Please conduct thorough research before spending your hard earned cash. Hopefully both tools have 30-day trial installations to compare side by side, as your mileage may vary.
I developed app in mFC using vs2008 and MFC Feature pack 2008. its look and feel is like 2007 office style. Now i want app look and feel like office 2010.
Will you explain me how to do it?
The easiest way is to upgrade to Visual Studio 2010, which provides a "Windows 7" style for the ribbon control. This style is supposed to simulate that native ribbon control that is used in Windows 7 applications like Paint and Wordpad. (Note that a slight modification to the wizard-generated code is currently necessary, as described here on Microsoft Connect.) Presumably, this style also looks like the one used in Office 2010, although I can't say for sure as I haven't given Microsoft all of my money yet.
Decide for yourself:
Alternatively, you could just use the native ribbon control yourself. There's a sample project here:
Windows 7 Ribbon: The Time Has Come, Your Win32 Application Will Change. But if you've already done a lot of work laying out the ribbon in VS 2008, this probably isn't a very compelling option.
Lesson: There's a hefty price to be paid for being on the bleeding edge. If this isn't exactly the same look that you're hoping to emulate, you may very well be out of luck. If your design goals amount to copying what the Office team does, you're going to be quite a busy little bee: toolbars are their absolute favorite thing to reinvent.
EDIT: Looks like you might not be completely out of luck after all. BCGSoft (the company that Microsoft bought the ribbon control from in the first place for the MFC Feature Pack) has released a library that attempts to simulate the Office 2010 experience in several different ways. Throw money at them here.
For those who are using vim/emacs/terminals,etc (ie, not an IDE proper) what sort of projects are you working on? Are they big? Production? Are these the tools you use at work? Or mostly for smaller things...or big things broken into small things? Sorry...enough questions.
I ask because I'm studying computer science right now, and am super excited about it. I had an internship programming J2ME for a government agency recently and it was Netbeans and eclipse all the way. So I've only had a few "minor-league" years in the business.
In short, what is practical for the CL type tools, versus an IDE such as 'beans and VS. I've got a lot to learn, and the CL tools will probably teach me, versus shielding me like an full on IDE might.
What sort of projects are you working on?
All kind... vim is my main "IDE" anywhere
Are they big?
Yes... My FOSS project CppCMS written almost 100% in vim
Production?
Yes, most of production code (Not FOSS) I write today I use vim.
Are these the tools you use at work?
Yes.
I would explain severak simple things:
vim provides almost all tools IDE does, highlighting, spellcheck, autocomplition, working with multiple buffers, build, context "jumps" (decl, def) and much more
It is extreamly portable, I work with it on Windows, Linux, OpenVMS, Solaris, FreeBSD.
It is very light in comparison to bloated IDE.
There is only one thing I do use IDE today: debugging hard bugs.
Emacs/Vim can be used for any sized projects.
Generally, you won't get to choose the environment, the job you find will have one already picked out for you (unless it's non-Java programming in Unix, in which case use what you want).
I wouldn't sweat the choice, just learn to use which ever editor/IDE is available to its utmost extent.
I use (and have used) Emacs for personal projects, and in two different companies on software projects exceeding 10M lines of production code each.
I use emacs. I would recommend emacs. I have used emacs since before it was emacs: TECO, TV, and the e macro package on the Decsystem-20.
I can use vim if I need to but what you learn is largely what is at hand and you get into.
Yes, learn one or both. And I would say, if the IDE fits, wear it too.
I use vim for everything, I hate IDEs, they're too bloated for me.
I haven't used it for any massive projects (because I haven't written any massive projects), but if I were going to, I would still use vim.
When learning I new language, I believe it's best to not use IDEs at all, and to learn the "proper" way of doing it (like for c++, learning the command line switches and using makefiles).
Twenty years ago all my programming was done in plain text editors, mostly emacs, but technology has improved over the years.
I still do use plain text editors to write code occasionally, but only when it is inconvenient to install an IDE on the machine where I'm writing code. For example, a few times I've stopped by a client site without my laptop and wanted to write a quick program.
This is also an issue with certain embedded systems, where you may want to update the code interactively through a RS232 or USB based command line interface.
Most modern IDEs provide enough acceleration to the code editing process that I will install one whenever I expect to use the computer for development for more than two or three hours.
I use vim for everything from small one-off scripts to 1000+ line production code. It is so versatile that working in any other environment seems constricting. If I'm part of a project that necessitates a standard environment (IDE) then I'll do as much coding as I can in vim and then import into the ide.
I believe everyone should be able to operate effectively in a command-line environment. You can't always be sure that anything except the basic tools will be available on the target machines, you can't be sure that you'll have enough system to pull up a full IDE, and you might actually find the system you're building is too complicated for an IDE.
I've built systems that have consisted of multiple interoperating clients and servers distributed across multiple physical machines. In these efforts, I have used command line tools almost exclusively in the server side. I will use DDD when I can, but I also know the underlying gdb. If the clients are Windows, I'll use the Visual Studio IDE, but if they're UNIX, I'll go with the command line.
Figure out how to work effectively using minimal tools. You'll be a better developer and you'll actually appreciate the integrated tools more, if they're done better.
BTW, I put Emacs in the IDE class. I've got a friend who comes in and fires it up first thing and doesn't leave the environment all day. It's more than an IDE, in fact, since he does mail, surfing, etc. in the thing, or so he tells me.
For large projects with 100+ files, using an IDE is very important. But there are lots of small small things which you need to keep doing all the time while working on even large projects. Firing up the IDE for all of these may not be worthwhile. Having a good command on a powerful editor like Vim or Emacs is something I would consider as an essential skill for any programmer. But an appropriate IDE should also be used to accelerate regular development work as per project needs.
Hmm... Well, look at it this way:
I open code in emacs. I edit it. I use code completion (and I've even played with intellisense emacs)... When I'm ready to compile, I hit CTRL+F7... A key I've bound... It builds in a small popup window... If there are any errors, I can jump to them in the code by hitting f8 (another bound key)... Once it's all building, I hit f5... (this runs a little program I wrote that parses the Makefile and determines the path the executable)... This starts the debugger in a small popup window... I can click on code lines to set break points... etc... I debug... I can "next" through the code with F10... I can "step" through the code with F11 (more key bindings)... When it's all done I hit Shift-F7 to package (.rpm) the project.
So, do I have an IDE? Or am I just using a plain text editor?
1. Yes. 2. Any kind of project.
There is no limit to the size of a system that can be developed in Vim/Emacs/Unix, in fact, there are fewer limits than there are in IDE's. Let's look at a few things I use...
SYSTEM LINES OF CODE
Linux kernel 10,000,000
NetBSD 4,000,000
Ruby 200,000
Those are pretty big systems.
I don't believe any of them were developed with IDE software.
I tend to agree that for learning it is a good idea to understand the basics: the fact that you edit the code, you compile it with a compiler, link it with a linker, debug it with a debugger.
It makes it easier to grasp the concepts. And it makes easier to move from platform to platform.
So, learn vi, make, gdb, some version control system (git, svn).
But for production I would say that getting familiar with the "standard IDE" of the environment is a must (Visual Studio for Windows, XCode for Mac OS, Eclipse for Java, etc.)
No mater what other say, mastering an IDE will increase your productivity.
If you used vi/emacs for 10 years and try Eclipse or Visual Studio for few days, you will say that they are bloated and don't offer anything in exchange. That's BS. The more open minded you are, the better you will be.
I use Emacs to develop commercial software with size of several millions LoC, and massive use of templates, etc. I use CEDET + gnu global as auxiliary packages + yasnippet, etc.
well...I have to say that I'm a vimmer. Using a IDE, I don't to care so many things like when you use editor like vim/emacs. But when you do a bit more, you will find the IDE you use is more hindering than helping in your program developping process. alas...if you insist in using vim/emacs as your editor, you will encounter "a deep learning curve", you will waste so many time even to acchieve so trivial a function in your editor,you will be desperate when you are busy catching up with your timetable if you just pick them up......you have to settle down and start leaning and also playing with editors and a couple of days, you will find you've already achieve more than you can ever expect!
My standard IDE is a flock of xterms running some mix of vim editors, man page documentation, debuggers, log tails, and command lines to execute things, plus an instance of Firefox for pulling up additional docs or (where applicable) testing web-based code. This is what I use for all projects these days, regardless of size, whether personal or professional.
Pretty much the only time I've seen real benefit to using an IDE has been when I've been working on platform-native GUI apps, where they make it so much easier to build forms and wire up their controls. But I haven't done that sort of work in over a decade - the last one I did was in Deplhi, back when Borland still owned it; I think version 4 had just come out, although it might have been 3.
Emacs is a great tool (so is Vim) for programming, and I use them to develop my code for physics research. As added benefit (for me) Emacs handles remote files nicely via Tramp, so that's big boom for me since I very often have to visit remote servers.
With that said, every time I need to write an application with a GUI and within a large framework (like c# with .NET or the android framework) I always find it hard to development with just emacs. The IDEs (Visual Studio, Eclipse) simply have everything including autocomplete and lookup with appropriate content from the framework, and debugging, even though code writing part is always unsatisfactory (I always end up installing some sort of emacs plugin for the IDE, which always fall short of Emacs proper!).
Sometimes it just takes too long to setup an environment in Emacs for those kinds of projects since that is not the default way envisioned by the designers, and having an environment that works out of box is so much easier than banging my head against the wall to find usually obscure information on how to compile/debug those app without using the designated IDE.
We could sum things up by saying that editors like emacs / vi implements some of the functionnalities of IDEs by using CL tools (or the libs behind the CL tools).
Your main issue in using an editor as an IDE would be :
configuring it to have exactly the functionnalities you are happy with in an IDE is not necessarily straigh-forward (I ask for sympathy from anyone who ever tried to configure CEDET ;) ), as opposed to working out-of-the-box with IDEs
the way such functionnalities work in editors is very tied to CL, so you need at least a vague understanding of the CL beforehand.
The advantages are the fact that CL tools are sometimes more ubiquitous than IDEs. Also mastering CL opens the door to scripting your build ("make a build in one command" as opposed to "make a build in one click"), which opens the door to automated nighly builds, continuous integration, etc... all of which are harder to setup if your understanding of the build stops at hitting F6 or whatever.
I have decided that I really need to get some flowcharts for reverse engineering some code I have inherited. I do not have the Team edition of VS so I cannot use Team's built-in capabilities with Visio. So I thought I would parse the .ncb (Parser Information) files and make charts with dot (from graphviz.org). How hard could that be? But I cannot find any documentation for the innards of that file.
I really don't want to use a commercial application to do the flowcharts. And the free addins I've seen all assume that I am using C# or VB. However, I am using C and C++.
I did try the Microsoft "Visual Studio Learning Pack" which has the "Visual Programming Flow Chart" tool. But it doesn't appear to work with C++. So close!
So, does anybody have pointers to the file format or other suggestions (keep it polite!)?
I don't think you have much chance to be able to parse the NCB files. They are in a proprietary binary format that changes and is likely to change between every single version of visual studio. From what I read somewhere, it's possible that in VS2010 the NCB is going to be discarded and the intellisense information is going to be kept in normal database using SQL Server Express.
Another option you might consider is using some other tool that analyzes your code and builds diagrams and UML charts. Doxygen does this to some extent and there is a plethora of commercial tools that do as well. I have some personal experience with Rational Rose (which might be defunct by now..) and a tool called Together. This list might be of some help
For a structural analysis in the sense of "who calls what", "who inherits/overloads where" and "who reads/writes globals" I once used DeHydra (a mozilla project) for analysis and yed (www.yworks.com) for graph display. Both are free.
Dehydra runs under linux and requires your code to pass gcc compilation. This is not a too serious obstacle, as VC can generate makefiles, which can be hand-modified for gnu make.
In my case, some patching of include files was required, but i could finally get the desired information out.
It took me 3 days to get DeHydra working, another 2 days to tweak makefile and includes and
3 more days to adapt javascript code, which inside DeHydra extracts the required information.
DeHydra + Javascript now delivers in one compiler run a graphml file containing the code structure, which can directly displayed and interactively manipulated in yed.