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)."
how can he not have been here yet? i'm not waiting forever.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
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...
Do they actually have C99 support yet?
Real time error highlighting is the MOST important thing to me when it comes to an IDE. If I forget a semi-colon the IDE should tell me as soon as I go to the next line that I'm missing a semi-colon. It shouldn't wait to compile or run my code, it should tell me as soon as possible. The last version of VS didn't do this (without a plugin), does this version?
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?)
Microsoft is to software what Budweiser is to beer.
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.
I still develop in Visual Studio 6. Yes, the language support is somewhat lacking (scope rules for 'for' get me regularly), but to me it just feels so much nicer to work in than the later versions of VS. As if this was the last version that was still for C++ developers: I neither want nor need to develop web pages, C# applications, .NET stuff, or whatever crap they added later, and I sure don't want it to be the focus of the package I'm working in, with C++ thrown in as an afterthought.
Have they brought back the keyboard macro's? They were there in VS6 but I could never find them in later versions.
installs Visual Asisst http://www.wholetomato.com/
Yep. Works great now.
(No, I don't work there. Just been a long-time customer.)
Save the Music; Save the World at http://www.TuneTriever.com (Our latest Android game)
As long as I've known that MS makes an IDE, I've always wondered why they charge for (some versions) of it. The majority of apps compiled on it get compiled to MS Windows binaries. People will need to buy Windows to use these apps. That means more money for MS as more people make useful/necessary apps. Where does MS benefit by charging for the development tools? It seems to me that there would be much bigger benefit to giving away the tools for free. Perhaps I'm greatly underestimating the chunk of change MS makes by selling their development tools. Is that it? Otherwise, please explain it to me.
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.
Plus they committed, in my opinion, the unforgivable sin of trying to push their _s* functions that they said were "safe" instead of ones like strncat, strncpy, etc. The first time I compiled some code in VS2005 I freaked...what are all these warnings? Then I discover it's Microsoft being "helpful" and I was annoyed. Then I realized they wanted to make my code entirely Windows-dependent (functions that start with _ are not standard) and I was enraged. What *really* enraged me was that you have to turn these stupid warnings off per project
I will give VS2008 a chance, but VS2005 with all its "standards compliant goodness" was not enough to sway me from VS6. The bloated IDE + improper warnings has utterly soured me on developing for windows; I don't want to do
Why, righ here, of course.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.