Slashdot Mirror
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?
Yes, but where's the Lisp module? :(
It's already out....
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.
All I really want to know is: will Intellisense actually WORK this time?
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.
Visual Studio has to be the best piece of software to have ever come from Microsoft. IMHO it would be even better if they would support elastic tabstops, and I know I'm not the only one.
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
Sure, they promised multicore compile in VS 2005. Now they promise it in 2008.
Why can I just not type "make -j8" like I can under MSYS and make my quad core system scream?
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.
I left Visual Studio when I found Eclipse, back when VS just went .NET 200X.
Did they finally manage to integrate with a version control system that didn't suck and/or cost a fortune?
- https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=319580
- https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=316513
- https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101842
- https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98871
- https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=316513
Note that this bug actually results in some perfectly reasonable, standard-compliant code to crash or behave incorrectly at runtime (see the first link for details on this particular aspect of it); what's worse is that the same code ran just fine under VS2003 (and, of course, under any version of g++ from 3.x up). Also, the compiler won't give any warnings - you'll just get non-working code, which will segfault at best, and quite possibly just silently produce incorrect results.TR1 is not in VS2008. It will be available as a "Feature Pack" at a later date ("first half of 2008"); only a beta is available at the moment. Also, see the FAQ on the beta for more details on the TR1 implementation, such as a list of what's not supported and why.
I installed Visual Studio 2008 and noticed that hardly anything is different from Visual Studio 2005. Oh wait, that's because I'm only using native code. It's very obvious that the mandate from above is to focus only on .NET. Almost all the fancy new features are for .NET only. I think it's only a matter of time before Microsoft declares Visual C++ dead for anything but service packs. (They still need it to build Windows, so it'll just remain this way.) The C++0x support and MFC are probably just throwing a bone to their users.
Sadly, it doesn't look like C++0x copies C99's variable-sized stack array feature, and VS2008 doesn't implement C99, so we are *still* stuck with alloca on VS2008. Why didn't C++0x copy variable-sized stack arrays? And why won't Microsoft add this obvious extension?
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
My point was, you get all the bad things with C (the anal-retentive nature of memory management), but none of the good things of OO programming (the ability to almost ignore memory management, plus the well-defined and easily-implemented interfaces to the objects).
That's all I was saying.
I love C. The C memory model is dead simple, and I like that. If you make it, you clean it up. Or, part of the interface contract is that the library makes it, but the client cleans it up. Either way, the clean-up duties are clear. But they're also hard to manage. That's fine with me. But I can't say that it's *easy*. Sure, when it's simple, it's easy. But there are always the edge cases that screw things up.
Anyway. I love C. It's probably my favorite language.
Microsoft is to software what Budweiser is to beer.
> I fuckin' *hate* C++. I'd much rather have to code straight C while being punched
> repeatedly by a baboon.
You hate having to cast malloc that much? That is the only significant thing you would have to do differently when writing C++.
Now if you were talking about reading someone else's C++ code, you might have a point.
Static analysis tools aren't very good for memory leaks. Dynamic tools can do a better job, but the low level nature of the C memory model makes even those less than perfect.
I've been using Visual C++ since 1998, and have tried all 4 compilers since then:
I have to largely agree with many comments.
VC++6, VS 2003, VS 2005, VS 2008.
VC++ 6 was fast and responsive, a pain at times (eg COM and ATL support was still half baked, debugging programs that used COM objects was a pain) but worked well most of the time with excellent help (for it's time anyway).
VC++ 2003 was noticeably slower but not unusably slow but in every other way (except the help system) was greatly better than VC++6 (eg the merged ATL/MFC CStrings etc were a big help!). We had some minor porting issues but nothing big.
VC++ 2005 was a wreck. How on earth they had the nerve to release this I don't know. Even on my quad CPU 2GB RAM system it's unusably slow. The high end features like the static analyser that cost big £'s were a poor shadow of 3rd party tools (eg Gimpel's PC Lint). Just dreadful. Even SP1 has barely helped. The warnings over deprecated unsafe functions were annoying but worthwhile.
VC++ 2008 looks and feels like VC++ 2005 SP2 - many of the original features promised for it have slipped again (just as Vista's killer features did) into the next coming version. It's a bit quicker than VC++ 2005, but nowhere near enough and feels like yet another stop gap.
In short if you've read between the lines, you'll figure I've stopped and use VC++ 2003 still, it seems to be the best compromise of all 4 versions, it's now quick enough on modern hardware to be emminently usable (tho VC++6 still flies) and by checking out many of the options you can turn on some of the compliance stuff (eg for scope, exception behaviour etc), combine that with the rather great WTL library and a great value static analyser (PC Lint) that is state of the art, and I reckon you've got the best MS based environment for native Win32 (C/C++) Windows developing these days.
Plus if any of you have tried Visual Studio Team System for SCM, you'll know it's a nightmare. It's been around since 2005, and only now have they boasted that in the 2008 version can you actually lock a file out for changes to prevent multiple changes to a file concurrently.
When I saw that in the upcoming features in 2008, I couldn't help but laugh. Microsoft surely were having a joke... But no, I asked a workmate who uses the tool (against his better judgement) only to discover it's true - with the 2005 version multiple people can lock a checkout a file concurrently - predictably the source base he was working on, was a total mess at times..
Linux fan and Win32 developer