TexBlog

Steve Teixeira's Blog -- Thoughts on parallel computing, Microsoft, the industry, and life

More VC++ strategery

More VC++ strategery

  • Comments 8

I appreciate all of the participation on this topic.  Your comments are very helpful to the VC++ team in our long term thinking.  I'd like to continue the discussion on a few of your comments...

"Fully implement the 1998 standard. It's now 2006. When is export coming? It may not be popular with many, but that is beside the point: it is part of the standard and I expect to be able to use it. The 1998 standard should be fully implemented before starting on TR1."

I'm sorry, I just can't agree fully with this.  Yes, standards conformance is important.  This is why we invested so heavily in being among the industry's most standards conforming compilers.  However, let's not forget that VC++ is a business.  Every feature we implement means there is another feature just below some imaginary line on a list that won't be implemented.  Export is certainly on the list of stuff we'd like to do long-term, but so far it hasn't been high enough priority to make it into a release.  If it makes business sense to implement all or parts of TR1 before being 100% compliant with the last standard, we'll definitely do that.

At the IDE level, I would love for Intellisense to just work. It dies far too often and too fast. I get tired of exiting VS, deleting the Intellisense DB, and restarting. So I often work without it. This makes the IDE little more than a glorified text editor.

Heard loud and clear.  We did make some significant quality improvements to Intellisense in the upcoming service pack (learn about the beta here), but you're absolutely right: it still needs some work, especially on XXL-size projects.  Intellisense and other IDE tooling are major areas of investment for us going forward.

"concurrency": If there is a new standard concurrency library, fine. But no thanks on proprietary stuff.

I'm curious whether this is a common opinion or whether others are open to Microsoft innovation in this space.  Personally, I believe it is a space of potentially very high value to the industry (see Herb's paper if you remain unconvinced), and Microsoft is all but obligated to innovate here.

If, however, MS wants to keep using "language neutrality" as a selling point for .NET, they should make VC 8 be a genuine first-class language instead of a second-class one that is useful only as communications tool to a first-class language (C# or VB).

The language neutrality of the CLR and the features we choose to put into VC++ are two totally separate things.  Whether or not VC++ is a "first class" .NET language (for some definition of "first class") doesn't make the CLR any more or less language neutral -- the CLR is language neutral no matter what we do.  On the VC++ team, we're more interested in enabling development scenarios that are important to our customers than trying to meet some arbitrary bar for being a "first class" .NET language.

If MS decides it would be the best use of resources to make VC++ the best possible tool for native coding and drop the .NET aspects entirely, that domain-specific approach would make sense too.  What doesn't make sense is the half-hearted approach of making C++/CLI a poor stepsister to C#.

Again, this isn't about "keeping up with the Joneses" with respect to C# on .NET.  I don't believe it's necessary to take an "all or nothing" view of .NET either.  To me it makes perfect sense for VC++ to be the industry's best native Windows tool and to play in .NET scenarios that are important to our customers (e.g., interop with native code).

If Vienna exposes new stuff as C APIs or COM objects, then I would like to have C++/MFC wrappers for it. If the native APIs get a feature freeze and new APIs are only available through managed code, then it doesn't make sense to urge for new MFC classes.

I agree in principle that job #1 for VC++ is to provide a great experience for native development.  Regarding Windows Vienna, I have no idea to what degree Vienna will include managed APIs, but my view is that Visual C++ needs to provide developers access to the platform, regardless of whether the functionality is native or managed.  For example, if we still have a large part of our customer base depending on MFC when Vienna is released, then we need to expose Vienna functionality in MFC -- whether that functionality is native or managed is less of an issue.

If a g++ user wishes to make g++ more conformant to the standard, they can (in the sense that no one stops them, no one hides the tools).

I agree, and that's certainly the value prop of open source.  Users that have the time and skill can add any functionality they want on top of an open source project.  But that isn't a conformance argument, it's an open source argument.  To compete with open source, the strategy is relatively simple: offer value and TCO so compelling that people are willing to pay money for it.

Consider laws that say which side of the road drivers should drive on.  The level of conformance in rich countries is higher than the level of conformance in poor countries.  Does this mean you shouldn't try to conform when you're driving?  On the other hand there are a lot of bad laws too, just as there are defects in standards which I wish would be corrected.

You lost me on that one <g>.  I don't see programming language standards conformance and public safety law conformance as remotely related except in that both phrases use the word "conformance."  :)

I don't like the idea of interop, I'd say separation and componentization is a better way. Interop is ok for the meantime of migration, but not as a programming model.

I think there is some semantic confusion here.  Even if you separate and componentize, the separated components still need to talk to each other.  Interop enables that conversation.  Since Microsoft continues to innovate in both the native and managed code spaces, I'm afraid the need for outstanding interop technology will only grow in importance over time.  It takes a bit of a mental shift, but it's important that folks realize that the native and managed platforms are complementary, not competitive.  It's not a matter of replacing one with the other, it's a matter of using each where it makes sense.

So for Orcas+1 I would like to see a new framework / programming model that promotes separation and componentization.

Really? I ask this in all seriousness: do you honestly want to see yet another GUI framework come out of Microsoft?

  • I'd REALLY REALLY like to see a next-generation inline assembly support, including the kinds of optimizer hints that GCC has, for both x86 and x64. The omission of inline assembly in x64 is really annoying.

    Actually, a reasonable alternative would be better MASM or NASM support in the IDE, with syntax coloring and stuff, and just being able to add .asm files to the project without having to set up a custom build step. This would likely be a lot easier for you MS guys to do, too, and would provide a lot of the benefit, since the major reason people use inline assembly is the convenience of not having to do these steps of custom build setup etc.

  • Anon,

    I, too, am a fan of inline assembly.  I should mention, though, that one of the things we've tried to do in VC++ is improve our intrinsics support such that there is less of a need for inline assembly.  Are you trying to accomplish something not possible with intrinsics?

    Thanks,

        -steve

  • The team needs your help debugging the new Visual Studio 2005 Service Pack 1 Beta . I've written about

  • The team needs your help debugging the new Visual Studio 2005 Service Pack 1 Beta . I've written about

  • Steve Teixeira (Current Group Program Manager for VC++) has a nice series of posts ( here , here , and

  • Regarding concurrency, I'm very much in favor of language innovation. As a convinced user of OpenMP, I would like to see much more coming in this area (e.g. active classes), especially in native code.

    These features may be easier to implement using managed code (thus in C++/CLI), but in native code is where we need them most.

Page 1 of 1 (8 items)