GoingNative is a new, monthly show on Channel 9 dedicated to native development and native developers, with an emphasis on modern C++. In our inaugural episode, we keep things light and easy as we introduce you to what we're doing, why we're doing it, and how it will go down.
The main goal of episode 0 is to introduce the cast of characters, including your hosts Charles Torre and Diego Dagum, and to present some ideas of how we think this show will be organized and executed. For example, Diego and Charles will typically construct the show, iterate through some code demos of varying complexity, converse with native developers from Microsoft and across the industry, and then destruct the show. In this first episode we do talk about and demo a few new C++ features (shared_ptr, lambdas, auto) and have a conversation with Ale Contenti - development manager of VC's front-end compiler, libraries, and IDE.
[You can play around with the demos in this episode by downloading the free VC++ Express IDE]
Table of Contents (click time code links to navigate player accordingly)
[00:09] Charles and Diego construct the show and talk about modern C++ (how 'bout that set, eh?) [07:27] Diego demos shared_ptr [10:01] Charles and Diego chat briefly about C++ lambdas [10:32] Diego demos lambdas [12:13] Charles and Diego chat briefly about C++ auto keyword (seen in the lambdas demo) [13:30] Charles and Diego talk about the audience and how you can help us fly this plane [15:32] Charles interviews Ale Contenti [26:35] Charles and Diego destruct the show ( it won't usually take this long )
Stephan T. Lavavej - MSFT> C was a very good language for its time, but it is very old and very limited now.
Assembler and cross-platform assembler (which is the second name of C language) can't be "old" or "limited". Mathematics can't be "old". This is a misleading shortcut.
Stephan T. Lavavej - MSFT> immune to memory leaks with only a basic level of care
No problems! For example, light MEMWATCH header is a pure ANSI C free cross-platform memory leaks detection solution. Valgrind is also useful. Every detected leak is written directly into log file (with exact line number inside the source code where memory was allocated initially). Very convenient and quick approach.
Stephan T. Lavavej - MSFT> map<Key, Value> is a zillion times more readable than anything in C
IMHO, there are many lightweight C algorithms libraries on the web. Trivial void* pointer (with some macros) for any complex data structures is more universal, convenient and readable than what bloated STL offers.
Stephan T. Lavavej - MSFT> I spent a year and a half of my life struggling to learn C from scratch.
So what is so complex? Pointers arithmetics? I like to use pointers. And C is easier that C++, because C is a subset of C++.
Genericity along type safety, memory safety while preserving full performance and more important brilliant STANDARD library is vantage of C++ over C.
Okay Reza, it's your choice! And I respect your choice. I also created software in C++ for some time. But there are still pure C programmers around. I code in C, and I like it more than C++. I want to use more conservative pointer-based approach instead of templates. I just came here to tell you that you guys must remember about us. We also want to be treated with respect. And some minimal support, documentation and demos of pure C software development will be greatly appreciated.
Agree with C Programmer, after all we all belong to the same family.
Both languages have their own strengths and serve a different purpose, not sure a C vs C++ debate is what we need ...
Lordkain> We all belong to the same family. Not sure a C vs C++ debate is what we need ...
I agree with you.
"For example, today one of my teammate called me and opened an existing cpp and typed a function name in the editor and it took about 2 seconds for the code to appear in the editor after the typing done. Sometimes opening files take about 5 seconds. It is totally unacceptable as my boss said to me. ... If there is any way to resolve IDE performance problem please let me know."
I know this is not what you were hoping for, but the answer to the above question is: *no*.
There are some tricks which can help the performance apart from those you have already mentioned you use, namely: be sure to run VS2010 SP1, try turning off all three of 'Automatically adjust visual experience based on client performance' / 'Enable rich client visual experience' / 'Use hardware graphics acceleration if available' options in Tools - Options / Environment / General (this sometimes helped with certain video card / driver combinations, prior to VS2010 SP1, could try it now as well), be sure to use precompiled header files, unload projects you don't use, store source code locally, not on network drives, and maybe a couple of other basic 'don't be stupid' things which everyone who was coding for at least 6 months knows in and out already. Unfortunately, after these basic things are sorted out, VS2010 still performs very poorly, much worse than VS2005 or VS2008.
There is *nothing* you can do about this, apart from refactoring your code. Yes, this is highly annoying. If this helps, you are not alone who is feeling that the performance of VS2010 is highly inadequate. Welcome to the club.
What my team ended up doing is use VS2008 as an IDE, and compile using the compilers from VS2010. This is relatively easy to do, so try it out when you run out of options.
Thank you for answering my question.
Yes we are using VS2010 Ultimate SP1 on Windows XP. I turned off the options you mentioned and the result was just a little bit perf boost only when VAX syntax highlighting is on, but nothing considerable and the editor still lags. Now I'm going to start tweaking project settings and refactor the code.
Falling back to VS2008 isn't seems to be an option for us because it will make things more complicated and I'm not in a situation to offer such an option for now, but I noticed that some of my colleagues already started using VC6 for editing code. The problem is that a huge amount of work is already done and we can't fallback to VC6 anymore.
The question is, does MS plan to release a service pack or hotfix to resolve IDE performance issue or we have to suffer til the next version of VS to see if these issues are being handled?
@Reza I wouldn't really hope for any significant performance improvement in Very Slow.next. As long as it is going to be written in MJ it will not perform. As simple as that. And next release will prove it. You'll remember my words.
What 'Knowing me knowing you, a-ha' said.
A lot of people have been nagging Microsoft to fix the performance problems in VS2010, to no avail. We did have SP1 which was of very limited help wrt performance (I wonder if I am being too polite here), and it looks like that's it, there will be no major updates to VS2010 prior to vNext. Worse, it is not at all clear if vNext will be significantly faster. Microsoft people on the blogs of course say they are "hearing" us on the performance issues "loud and clear" and are "taking these issues seriously", but they always say that, eg, they did say the exact same things when VS2010 was in the beta stage, yet we are where we are now. Things may still improve, but, frankly, I wouldn't bet on it.
"The .NET framework should definitely be avoided when speed is critical." Those are not my words, those are words of Agner Fog. Copenhagen University College of Engineering.
I also do understand that critical has different meaning in what he's saying but non-the-less, I think that it does indicates that .NET should be avoided if we want to have well performing apps.
By the way, the question is, Is Speed Critical at the stage where Very Slow is now? Judging by votes from "
, I'd say yes, speed issue is critical for Very Slow.
As I've said in one of my comments regarding Connect and their approach (do you remember the scene I've described with "pleasant manager"?) here I've just got reply, in which after some quarel I was told that indeed this is a bug, but unfortunately it won't be fixed in next release (marked as "Won't fix") and will MAYBE (which should be read as "Deffered for God knows how long just to keep you shut") be fixed in release after the next one. Isn't my prediction ALREADY fulfilling itself?
@PleaseFixYourBugs, In my last comment I forgot to paste this link, and as there seems to be no edit facility I'm doing it here. Sorry for the inconvinience.
"I also do understand that critical has different meaning in what he's saying but non-the-less, I think that it does indicates that .NET should be avoided if we want to have well performing apps."
Oh please. "I know this isn't what he meant, but it serves my agenda, so I'm going to pretend he meant something different".
What he is saying is completely different. He isn't talking about "well performing apps", but about getting maximum performance out of a snippet of code. The two are *very* different, and even the best peforming apps has a *huge* amount of inefficiency and "wasted" time. Abstraction layers, unoptimized code, priorities other than performance, everything adds up. There's a reason you need a gigahertz computer to run a modern web browser, *even though it is written in C++*.
Twisting the words of Agner Fog isn't constructive, and namedropping impresses no one. What he said has nothing to do with the situation that Visual Studio is in, and cheap tricks like taking other people's quotes out of context doesn't help your argument.
And of course, this isn't to say that performance of VS10 isn't awful (it is, to a large extent). But unlike you, I'd much prefer if the VS team could focus on the real issues (it is slow), rather than your imaginary ".NET plague", contracted by having *any* .NET code in your application, and which immediately makes the entire application unusable.
@Reza: I'm not sure (I haven't tried running VS10 on XP), but I've seen several reports that it's a bad idea to run VS10 on Windows XP. Upgrading to a modern OS might improve matters significantly.
and as much as I wish the entire C++0x standard was supported, it is just amazingly childish to:
1: file a *bug report* on a feature they haven't implemented, never pretended to have implemented, and never promised to implement.
2: name the bug "You got it wrong, again..."
3: whine about it here.
Seriously. GCC and Clang are missing tons of C+0x support as well. Do you act the same way towards them?
Have you ever, in your entire life, just considered *growing up*?
Wish I didn't know you, and you don't know me, a-ha: They provided header initializer_list so it would indicate that initializer list would be supported, wouldn't it?