Inside Visual Studio 2008

mlimber writes "Dr Dobb's Journal has a peek at what is new in Microsoft's Visual Studio 2008. Most of the features discussed in the article are related to .NET, web development, and the IDE itself. However, Herb Sutter, Microsoft software architect and chair of the ISO C++ Standards committee, blogged about some developments on the C++ front. This includes a significantly enhanced MFC for GUI building, and the inclusion of TR1 (library extensions published by the C++ standards committee, most of which have also been incorporated into the next C++ standard)."

Comments

Kudos to the Visual Studio Team

[RuBLed]

All I could say is that the best tool for windows development just got better. The new feature that could impact my work most is LINQ. I dunno but the VS Team of M$ had been doing some good things...

C99 yet?

[hpa]

Do they actually have C99 support yet?

Re:C99 yet?

[ireallylovelinux]

Uh, GCC doesn't even support C99 why would you expect MS to be?
http://gcc.gnu.org/c99status.html

Re:C99 yet?

[Anonymous Coward]

Kernel developers, system programmers and embedded developers do a lot of C, so does a lot of scientists who write in C instead of Fortran (as the restrict keyword in C99 solves the main issues with writing numerical code in C). Language runtimes tend to be written in C as well (e.g. the standard python distribution). So yes, people still write in C. Some developers (application developers for example), should naturally not write in pure C for most part (there are obviously some performance critical parts that are suitable for C).

Re:C99 yet?

[forkazoo]

Better question is: Do people still code in c?

Sure, lots of people write new stuff in C all the time. But, even if nobody did that, there are still a ton of people with existing C codebases that they are still working with. IIRC, Win32, Carbon, and GTK+ are all C API's, even if they have bindings to other languages. Lots of video and multimedia stuff is done in C, like the Dirac reference implimentation, gstreamer, ffmpeg, etc. When people talk about how C is dead, and nobody writes anything in C, they generally mean that higher level languages are used to glue together a bunch of C.

Thanks for asking

[Tony]

Fuck, yes.

C++ sucks. It's a half-assed attempt at an object-oriented language, combining the easy memory model of C with the simple OO model of Simula. I used to think the only good thing about C++ was templates. Then I figured out that templates suck, too, because they're damned near impossible to debug, for most non-trivial bugs.

I fuckin' *hate* C++. I'd much rather have to code straight C while being punched repeatedly by a baboon.

Objective-C is much less ugly. But then, so is LISP. (Actually, LISP is a damned good language. It's just not *pretty*, in a strictly aesthetic sense.)

So, to not be snide, there are *many* people who still code in C. There are many objective reasons to avoid C++. (This *was* about C++, wasn't it?)

Re:Thanks for asking

[iangoldby]

[C++ is] a half-assed attempt at an object-oriented language, combining the easy memory model of C with ...

Took me a moment to realise you were being sarcastic.

Seriously though, what's so difficult about the memory management model of C? I find it hard to think of anything much simpler. The great thing about C (IMHO) is that if you didn't write it, it won't happen.

Re:Thanks for asking

[epine]

The strangest possible criticism of C++ is the superiority of C. Unlike most languages, if you don't like a C++ feature (one that C doesn't have) you don't have to use it, and there is little or no runtime penalty imposed.

The strangest possible criticism of C++0x templates is that they are impossible to debug. It is, after all, the primary focus of changes to the C++ template system to drive diagnostics to the appropriate surface (at long last).

This is the fundamental advantage of a hammer over a pneumatic nail gun. The nail gun might be perfectly safe is used wisely, but human nature decrees that ultimately many people are going to file off the safety, leading to predictably gory anecdotes.

Standardize instead on the hammer, this can never happen. Which is the principle virtue of C.

C++ is probably the worst language ever devised to throw into a room full of monkeys. Many of the people who hate C++ most strongly have an underlying distrustful view of their peers as unwashed monkeys completely lacking in prudence, judgment, or impulse control.

There are situations where C++ simply should not be used, in much the same way that surgery in an African aid hospital lacking electricity and hot water is not your preferred medical option. Under sterile conditions, with doctors you trust, the pros and cons of C++ balance out quite differently.

I've been trying to put this sentiment into words for a long time. In development teams where dog-eat-dog survivalism holds sway (us against the world, me against my teammates, managers against the staff) C++ can only play out in the worst possible way.

Armed with hammers instead (the C language), the tragedy of the commons can't degenerate nearly so far. The virtue of C is that you don't have to like or respect everyone else you work with, which is no small virtue given human is what it is.

Re:Thanks for asking

[master_p]

Buddy, only God (or Stroustrup) can write good c++ code. If you have the guts, read this. There are humongous flaws with the language (and I say this with 10 years of c++ experience).

The concept of c++ is good: a language close to the bare metal that has the capability to abstract details so as that it reaches higher level language status. But in practice, it has incredible flaws; the implementation is *bad*. It could have been so much better...

wake me up in 1998

[epine]

Back in 1998 I would have welcomed a standard compliant C++ compiler from Microsoft. What Microsoft did support, it supported one level deep (e.g. namespaces, many template features) with unbridled hypocrisy.

Fast forward to 2008, if Microsoft can't be bothered, others can, so now they bother. Kind of like arriving at a New Year's party at half past twelve. The champagne is gone, and when you make your grand entrance into the room full of glassy expressions, everyone slaps you on the back and says "hey, glad you could make it". Almost like being there.

Re:wake me up in 1998

[Jugalator]

So you mean this means nothing to the millions of C++ programmers out there? Standard compliance on the by far most prominent OS tend to be a big deal, even if it's coming late. I very much agree with the "better late than never" saying here. If I wouldn't, that would mean I'd be pleased with an old non-compliant Visual C++ 6 compiler, which I would definitely not be.

Re:Is it any better than Visual Studio 6?

[ThaReetLad]

Well, we're just completing the porting of approx 1 million lines of VC++6 to VS 2008, and I have to say it's been so worth it. The new compiler picks up on and warns about many more potential problems, and there's also the issue of whole program optimisation. Also the debugger in VS2008 is much better than the VC6.0 one. I have to say, I think VS2008 is pretty great. A lot of the niggly little problems in VS2005 have now been dealt with, and speaking as someone who is just now starting to write some C# after 9 years writing C++ the LINQ stuff and lambda expressions are just great.

Re:Is it any better than Visual Studio 6?

[TheThiefMaster]

Have you tried MSVC++ 2005?

The debugger is leaps and bounds ahead of the VC6 one.
It supports parallel building of multiple projects on multicore cpus / multiple cpus (massively reducing build time).
Built in x86-64 compiling / debugging (local machine and network) support.
It supports link-time code generation (a major optimization improvement). The Pro version also supports profile-guided optimization.
It supports OpenMP multithreading extensions for C++.
Many many other improvements.

The C++ .net extensions are optional. And, in my opinion, crap. If you want to use .net, you're better off with C#.
Note: VC++ 2005 Express Edition (the free version) doesn't come with the Windows Platform SDK, and if you don't install it is only good for developing C++.net apps.

The ONLY advantages to VC6 are: that it links programs against the VC6 runtime dll, which comes with most versions of Windows, right back to some 9x editions, where with VC2005 it links against the VC8 runtime dll, which most people need to install / you need to distribute it with your program / you need to static link with it, resulting in a larger .exe; and that it supports building .exes that run on Windows 95.
Basically VC6's only advantage is that it's old.

Upgrades to MFC? what upgrades?

[master_p]

MFC - we are working on a huge update to MFC that should knock your socks off. I can't tell you too much right now, but this is closer than you might [think]

What do they mean?

Do they mean, perhaps, that widgets are now normal objects? no double-creation (first new Object, then object->CreateWindow).

Could they mean that all widgets are destroyed in the same way? no object->DestroyWindow for some widgets, delete object for some other widgets?

How about some serious memory management using shared pointers? no temp CBrush objects etc.

How about layout management? all serious widget toolkits have that. It's 2008, we should not have to position widgets manually.

What about the tab widget? in MFC, the tab widget is not a real widget: you have to manually hide and show controls upon tab click.

What about the model-view-controller pattern? this is 2008, should I still manually copy edited data from widgets to the data model of my application? most other toolkits support the MVC pattern. Dialog Data eXchange is a joke, of course.

How about the issue of message maps? Qt proves you don't need stinkin' message maps, which are hard to maintain, difficult to understand, and dangerous because casting is untyped and done through macros.

How about MIME type support?

These, and a lot more, are the issues that have driven developers away from MFC to Qt or WxWidgets. I have been maintaining a line of products based on MFC for the last 10 years, but this year I've decided I had enough: all the products are to be rewritten with Qt/WxWidgets. I will only approach MFC if it will approach Qt/WxWidgets quality.

Re:CL

[plague3106]

Why, righ here, of course.

LINQ is over-hyped

[Anonymous Brave Guy]

Just for the record, I think LINQ is a neat idea, and as a general principle I'm all in favour of strong abstractions and useful syntactic sugar in programming languages if these make code easier to understand and quicker to develop.

However, I'm worried by a lot of the hype about LINQ that's been flying around in recent months. Earlier this week, I found a code sample in a blog post showing how to use LINQ to find all the items less than 10 in a list. It went something like this:

from n in mylist
where (n => n < 10)
select (n => n)

For reference, here's the equivalent expression in Haskell:

filter (<10) mylist

That's obviously a much more elegant representation of the idea, and while it's not as generic, you also have things like map and reduce available, and a lot more if you need it.

If you don't like the functional syntax, Python's list comprehensions also provide a bit of flexibility, with less redundant clutter than the LINQ:

[n for n in mylist if n < 10]

Even using the standard library algorithms in C++98 — where, let's face it, the use of iterators and of algorithms with predicates is pretty unwieldy in the absence of good syntactic sugar — the code is about the same size as the LINQ version:

find_if(mylist.begin(), mylist.end(), bind2nd(less<int>(), 10))

This isn't intended to be a criticism of LINQ, because LINQ can do far more than just a simple filter operation on a single list. Rather, I am criticising those who over-hype a new technology as if it is the One True Way to solve all remotely related programming problems, and then apply a powerful, generic approach to a simple problem giving a ludicrously over-engineered result. See also: design patterns, template metaprogramming in C++, dynamically typed languages and web frameworks, monads for trivial I/O in Haskell, etc. Like all these other things, LINQ has a lot of potential to improve development when used in the right context, but I fear it will be overused just because it's new and heavily hyped.