VC++ product strategy: the next level of detail

re: VC++ product strategy: the next level of detail

me — Wed, 04 Oct 2006 05:11:03 GMT

I can understand your desire to extend support for C++/CLI to XAML etc. However, is this really benefiting your customers? All of the managed code that I write is done in C#. All of the unmanaged code is done in C++. The same is generally true with my colleagues. I am asked to either maintain an unmanaged project, or to _rewrite_ it in C#. They do not want a mixture of unmanaged and managed.

_C++ exists in my world for native code only._

"what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing?"

It is neither good or bad. However, I seriously doubt that I would ever have a chance to use it as I do all managed development in C#, not C++.

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.

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.

I'm not too excited about refactoring yet.

The little bit that it can do, I can basically do manually almost as fast. I would like to see automatic externalization of strings to aid in globalization.

"integration with MS online services (Connect, Windows Error Reporting, etc.): no thanks.

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

"native/managed interop": I will not use it.

C++/CLI Mobile support: no thanks; C# suits my needs just fine.

Optimizations: absolutely.

Performance-critical code is one of the main reasons that I use (native) C++.

re: VC++ product strategy: the next level of detail

Dave — Wed, 04 Oct 2006 18:18:04 GMT

I like the concept of integration with MS online services. Once a product is out of the door, knowing that problems exist (crashes) and identifying them is a major issue.

I'd love a built in capability in the development environment to say 'build and release', and have the relevant PDB files etc uploaded to a secure portal (note private portal too - MS run but not MS owned - code etc is customer proprietary) and for any product crash reports to automatically be visible there, showing stack traces etc.

Basically automate what I do today which is take a mini-dump file and throw it into windows debugger to view what was going on.

That would be a big time saver.

I also think adding more static analysis tools to help identify problems and validate code quality would help.

I would like the concept of 'formatting templates' to be added, so you can standardize on a style of code and then apply it to a project/file etc.

Performance optimizations - definitely a favorite - making best use of processor capabilities automatically is best done by you guys working with Intel/AMD.

VC++ is a very neat tool already though. Keep up the good work!

re: VC++ product strategy: the next level of detail

Wil — Wed, 04 Oct 2006 23:18:44 GMT

You ask, "what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing?" It might be a good thing from MS's standpoint but a bad thing for VC++ 6.0 (and C++ under UNIX) programmers who are debating whether to start using .NET once Vista comes out. These folks aren't full-time programmers but instead are office workers who have to write programs to get their work done. The less new material they have to learn to get started on .NET the better, and they don't want to have to learn C# first. Granted, that really isn't hard, but why should they not be able just to migrate from VC 6.0 to VC 8.0 (learn what handles and delegates do) and then still be able to build user interfaces, now using WinForms and (with Orcas) XAML, just as they have been able to do with MFC all these years? If C++/CLI is relegated to a tiny .NET/native interopability niche, it seems hardly worth MS's time and resources to maintain it. It would make more sense simply to make the C#/native interoperability seemless and then eliminate the C++/CLI middleman entirely. 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).

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#.

re: VC++ product strategy: the next level of detail

Andre — Thu, 05 Oct 2006 00:11:44 GMT

VC++ is used to develop applications that target the Windows platform, so you have to follow the Windows division, VC++ can't

evolve differently.

That was also the reason for my exaggerated question regarding Win32/Win64. 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.

If we look at the Windows API, I personally love the base services, but everything regarding the common controls and user

interface is at best ancient.

So let's split an application into its parts, view (presentation), controller and model. So when Hawaii (Orcas+1) is released

to manufacture we should have WPF v2 or v3 and the HWND based controls should rest in peace.

With the arrival of Vienna it would then also be ok to drop support for Win9x/NT/2000, maybe even XP. WPF is currently not an

option because of missing controls/MDI and it would lock out too many users.

So around 2010 user interfaces should really be created from markup and with a designer and controls that expose properties

to the designer and not ancient window messages. Layout/resizing/DPI aware user interfaces and localization should then be a

must have like an undo feature today. So how does the VC++ developer creates the user interface with Hawaii? I would prefer

C++/CLI support for XAML, because otherwise the controller and model would have to expose everything as managed code.

And then I expect an application framework that brings the different parts of the application together. Design decisions that

were made for the MFC have been made when we had what computers, 386?

As for the language I don't see native C++ on the way out. C and C++ will remain import in many aspects, and not only for

legacy code. VC++ is the application where this C code meets WPF. So VC++ really has a unique position.

I hope that we will see changes to C++/CLI, const correctness, unions etc. (See codeguru slow chat) as well as C++0X. And

C++/CLI support for mobile devices is important, otherwise I don't see how C++ code meets .NET

re: VC++ product strategy: the next level of detail

Andre — Thu, 05 Oct 2006 00:14:20 GMT

(Repost with corrected formatting)

VC++ is used to develop applications that target the Windows platform, so you have to follow the Windows division, VC++ can't evolve differently.

That was also the reason for my exaggerated question regarding Win32/Win64. 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.

If we look at the Windows API, I personally love the base services, but everything regarding the common controls and user interface is at best ancient.

So let's split an application into its parts, view (presentation), controller and model. So when Hawaii (Orcas+1) is released to manufacture we should have WPF v2 or v3 and the HWND based controls should rest in peace.

With the arrival of Vienna it would then also be ok to drop support for Win9x/NT/2000, maybe even XP. WPF is currently not an option because of missing controls/MDI and it would lock out too many users.

So around 2010 user interfaces should really be created from markup and with a designer and controls that expose properties to the designer and not ancient window messages. Layout/resizing/DPI aware user interfaces and localization should then be a must have like an undo feature today. So how does the VC++ developer creates the user interface with Hawaii? I would prefer C++/CLI support for XAML, because otherwise the controller and model would have to expose everything as managed code.

And then I expect an application framework that brings the different parts of the application together. Design decisions that were made for the MFC have been made when we had what computers, 386?

As for the language I don't see native C++ on the way out. C and C++ will remain import in many aspects, and not only for legacy code. VC++ is the application where this C code meets WPF. So VC++ really has a unique position.

I hope that we will see changes to C++/CLI, const correctness, unions etc. (See codeguru slow chat) as well as C++0X. And C++/CLI support for mobile devices is important, otherwise I don't see how C++ code meets .NET

re: VC++ product strategy: the next level of detail

Norman Diamond — Thu, 05 Oct 2006 09:35:02 GMT

> Given that Visual C++ 2005's level of standards

> conformance is among the best -- in the upper 90's

> percentage-wise -- it's difficult for me to see how a

> continuous and massive investment in this area could be

> justified.

Maybe two comparisons can make it a bit easier to see.

When a g++ user isn't satisfied with g++'s level of standards conformance, the g++ user gets a refund of what they paid for it (except if they paid for it). 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).

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.

> why is it important to many of you to support C++/CLI

> for .NET Compact Framework?

I used to have two reasons, but now only one. Libraries such as MFC and the Compact Framework have lots of users because they are useful, and the Compact Framework is built into the device's ROM but MFC isn't. I also used to think that it was easier to do development using WinForms instead of WinCE (more or less Win32) APIs, but maybe it isn't after all, because it still seems necessary to recompute the sizes and locations of controls at run time anyway in order to keep them all visible.

> Visual C++, being the one Microsoft programming

> language that enables developers to target the native

> platform

Bingo. If anyone wants to use the Compact Framework then moving to C# isn't the answer. Moving to a mix of C# and C++ might be the answer but surely C++/CLI would be an easier answer.

> Connect is not the best place to have a conversation

> about the various elements of product strategy.

True. In fact it doesn't work well for bug reports either, whether in Visual Studio or Vista. Though that's not entirely Connect's fault.

Wednesday, October 04, 2006 4:18 PM by Wil

> It might be a good thing from MS's standpoint but a bad

> thing for VC++ 6.0 (and C++ under UNIX) programmers

> who are debating whether to start using .NET once Vista

> comes out. These folks aren't full-time programmers but

> instead are office workers who have to write programs to

> get their work done.

Um, uh, well, OK. People who used VC++ 6.0 to make COM objects, people who used the VC++ 6.0 IDE with other toolchains to make drivers, people who used C++ under Unix to make compilers, and people who used C++ under Unix to make drivers, we aren't full-time programmers but instead are office workers who have to write programs to get our work done. Well yeah, I do work in an office more than in a lab or factory floor or old-fashioned computer room, and I do have to write programs to get my work done.

re: VC++ product strategy: the next level of detail

Andre — Thu, 05 Oct 2006 15:34:13 GMT

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.

It is ok to write different components of an application in different languages, but not one component and absolutely not one tier of a component.

Microsoft has released a lot of interesting and promising bits in the recent history, but they don't fit together as an overall programming model yet.

Also in some areas I see a step forward but also a step backwards. XAML/WPF is a (not new but) great idea, but it only does UI/logic separation to some extend and is a step backwards compared to the command driven UI in Win32.

In my MFC application the user can choose at runtime between the new Ribbon UI and the classic menubar/toolbar UI. Both are loaded from XML markup. For the logic part of the view nothing changes, the command and update handlers still work. It doesn't even matter wheter it's a toggle button or a checkbox. So for that part of the UI command routing is more powerful than objects/delegates, because it does a better separation.

An other question is how can you bring RAD and maintainability and long term investions together. I haven't used the MFC ClassWizard for quite some time, although I am writing MFC code about 60 hours a week. I reorder my message maps and group the entries and put comments between the groups. The wizard can't do that for me.

Therefore the WinForms designer is a nightmare for me. I don't want to go into the details, I've mentioned them in the Codeguru slow chat.

Unfortunately I see this to continue with the WPF designer. The IComponentConnector is a nightmare too.

So if we ever get a C++/CLI designer for XAML, please, please make it better than it's C#/VB.NET counterpart. And of course use macros. Macros are really valuable for verbosity and maintainability. A message map is declarative programming while the IComponentConnector is imperative.

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

re: VC++ product strategy: the next level of detail

Vyacheslav Lanovets — Fri, 06 Oct 2006 23:11:19 GMT

We have tons of tested and debugged C++ code.

Only the project I'm working for has >50MB of source code and we have a large URD to implement. And other products in our company have rather interesting C++ libraries we would like to reuse. Moreover, we reuse some source code which is _being_ developed for very limited OSes. We don't want to rewrite it to C# each time it's updated.

The problem is that one-way interop is not enough for us.

We need all that magic of /clr switch in Windows CE!

Windows CE 6.0 won't have that terrible 32MB virtual memory limitation. It will be fully functional OS - with no C++/CLI support. It's silly.

Another thing is that there are ~50 C++ devs for mobile devices in our company of which only several people know C#.

From my personal point of view C++ is superior to C#.

My dream is to be able to use Boost libraries and /CLR switch in VS for Devices.

SteveTei on VC++ Strategy

ronpih's weblog — Mon, 16 Oct 2006 18:45:53 GMT

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

re: VC++ product strategy: the next level of detail

Bal — Thu, 02 Nov 2006 02:43:49 GMT

I am very surprised that the Compact Framework does not support CLI/C++. We use it heavily for a number of reasons and not having it for devices seems a serious limitation.

Is there any plan to add this immensely useful feature to VS05/Compact Framework?

re: VC++ product strategy: the next level of detail

Colin Desmond — Tue, 07 Nov 2006 20:46:46 GMT

As a C++/CLI developer working with a legacy MFC application and doing all new work in C++/CLI (using WinForms instead of MFC windows), I would be keen to see full XAML support in the C++/CLI designer, but failing that, why can't we have mixed projects, some classes C# and some C++/CLI? That way we can choose the right language for the right job.

re: VC++ product strategy: the next level of detail

DanMeech — Sat, 02 Dec 2006 08:42:21 GMT

First, I am all for componentization. No C++/CLI.

If I want to do .Net I will use C#, and if I want to go native then it will be C++. I do not forsee myself using C++/CLI neither in the short or medium term.

I think time should be spent on the native platform.

But what I would like the most is REFACTORING!

On a daily basis, doing heavy OOP refactoring is a nightmare for me. Be it a simple rename of a variable or a bit more complex polymporphic rename or moving code to superclass, refactoring is a real nightmare in Visual Studio simply because it has NO refactoring at all.

Second, I would like more and better wizards to automate code generations such as Class/Methods/Members, etc...

The *Ultimate* C++ IDE for me would be very similar to the Eclipse platform for java. It is the best IDE I have ever used.

Be it the refactoring abilties, the browsing abilities, quick class overview, etc... this IDE is the platform to beat. Now I know that Java is a total different beast than C++, but for inspiration it might be worthwhile to take a look at Eclipse.

Who knows, since it is opensource, maybe you guys can use Eclipse for Hawai? ;)

Anyways here are my dollar spendings:

Productivity Enhancements: 50$

Compiler Throughoutput: 30$

Concurrent Programming: 20$

REFACTORING: .....................Priceless

re: VC++ product strategy: the next level of detail

Carlo — Wed, 13 Dec 2006 02:07:32 GMT

As a lover of C++ and a former member of Microsoft's C++ Language team it just seems to be an injustice that XAML related technologies are only available in a managed environment. It is not important for C++ to keep up with C# because they are two different animals, but it is important that C++ offer comparably acceptable solutions so C++ developers no longer need to move over to C#.

The fact is that Windows Presentation Foundation is built on top of an unmanaged layer called the Media Integration Layer (MIL). Why not just create a completely native XAML compatible group of classes for MFC and/or ATL. You could then easily create project wizards and VS extensions for C++ XAML. This would be very valueable to me and the C++ community. Really, this solution does not have to be fully XAML compatible, it would just need to offer features compareable to the managed world which is certainly possible.

The new managed .NET 3.0 features promote a Service Oriented Architecture (SOA). How can C++ services be made part of that new direction? Also, I once needed to create a high performance website for realtime financial stock news streaming. It was so difficult in ATL that I finally did part in ATL and the rest in C#. How can web development and web services be made easier in C++. A standards conformant, stable, simple regular expression class would be nice too.

I have done extensive Pocket PC and Smartphone development in C++ so I feel can speak for the C++ community with confidence on this subject. Managed developers are fine with C#. Native C++ developers would really just like better features for use in the native world.

Database classes comparable to .NET are essential to C++'s future at Microsoft in my oppinion.

Some serious C++ related problems I have had recently are:

1. C++ Project conversions from previous versions of VS to VS2005 are broken because of manifests. Will this get fixed? Why are manifests so essential?

2. VC library deployment (mfc, vcrt, atl) is nearly impossible now with VS2005. I previously could just copy the dependent DLLs, but now even the VC8 redistributable package does not work consistently to install and set up the libraries in thier Side-by-Side (SxS) directories.

3. WTL has features that were implemented very simply but outclass MFC. WTL's Message Map tricks, COM & ATL compatibility, and use of templates allow polymorphism and hence productivity. C++ programmers need those types of things in a supported library.

4. Out of the box, MS C++ interfaces with any framework look like Windows 95 interfaces. It's almost too late for this but why not automatically enable XP themes for MFC applications?

5. One of the "breaking changes" that were made for C++ conformance purposes caused an intolerable problem. You can no longer get a pointer to a member function of a class from an instance of that class. I was able to work around all the other "breaking changes".

The situations above create problems for C++ developers that are just scary. It would be nice to have those types of problems resoved and to have additional cool features engineered like any other product that has a future.