Future of C++ and .NET/WinFX

[Jason Vene]

I've looked at recent posts and not found material, but I'm new to the
board, so please forgive if this thread has come up before.

I'm facing a conundrum about development of business applications which have
robust user interface requirements (sorry, details must be kept private).
The UI will be required to present images, graphs (more akin to signals than
charts, like a wave file editor), various custom controls (some are full
scale windows that allow users to move 'objects' around - something like
what vector graphic editors do, but not for drawing pictures - for editing
data from SQL), and lots of other fun stuff.



I'm an old C++ die hard, so I'd rather use C++ than anything else. Besides,
I need to leverage a set of class libraries I've collected and developed
over 15 years (yep - I'm a graybeard). What worse, and my apologies for
bring this into the mix on a MS board, is that I need cross platform
development strategies. I have them when building in C++.



Now we face .NET, and MS is pushing hard for the development of .NET
applications. It would seem that C++ is the odd man out of that loop. I know
we can generate both mixed and fully managed code targets, but as I
understand it they will not (or ever) be "verifiable" code. I'm not really
sure I understand what that means, but I think it means that many of the
future benefits of .NET will be limited to the other .NET languages.



I'm guessing, despite the reading I've done on the subject, that among the
many potential business benefits will be the ability to "rent" software
through the 'net, deploy sample applications through the 'net, and create
applications that take the position Java was supposed to occupy. I
understand many of the technical reasons C++ might be "untrusted" in a .NET
target, compared to C# (I've created some mixed target applications during
my investigation of VS.NET2k3).



I also know there are means of doing that without .NET, but my concern is
that if MS pulls .NET off as expected, consumers will begin to expect .NET
features that may require a non-C++ .NET language. I'd rather that not be
the case.



Have I missed something here? Will it be possible for C++ targets to take
advantage of every benefit of the .NET future? Should I consider a roadmap
that migrates my code toward C# rather than managed or mixed C++?



While I'm not targeting applications the likes of Photoshop, Maya or some
non-linear video editing package, I'm far above the lesser requirements of
standard "bag-of-fields" type business applications, and would benefit
greatly from mixed C++ (or all unmanaged C++). How would this play out for
WinFX targets? Must I be forced into mixed mode programming to take
advantage of Avalon?



I don't believe the C# languages currently in open source for Linux (the
mono project) will be "allowed" to survive, nor do I think they'll do any
better than Java under Unix or Mac (compared to Java under Windows). This
makes cross-platform targets more work if C# becomes a requirement, so I
really hope to avoid the language without loosing access to features users
may come to expect in, say, 2006 through 2008.



Where are you going, in say, two years?

 

[Carl Daniel [VC++ MVP]]

Have I missed something here? Will it be possible for C++ targets to
take advantage of every benefit of the .NET future? Should I consider
a roadmap that migrates my code toward C# rather than managed or
mixed C++?

With Visual C++ 2005 (aka Whidbey), C++ will be the implementation language
of choice for .NET, IMO. It will be possible to do everything in C++ that
you can do in C#, including produce verifiable images. And you'll still
have C++ templates, separate compilation, and all the other things you've
come to expect from C++.

While I'm not targeting applications the likes of Photoshop, Maya or
some non-linear video editing package, I'm far above the lesser
requirements of standard "bag-of-fields" type business applications,
and would benefit greatly from mixed C++ (or all unmanaged C++). How
would this play out for WinFX targets? Must I be forced into mixed
mode programming to take advantage of Avalon?

You're only forced to do mixed-mode programming if you can't find (or write)
what you need in managed code. Note that it's quite possible to take an
existing "native" C++ app and compile it as managed code. For example, this
has been done internally at MS with some significant apps that have far more
than the "bag of fields" UI requirements that you allude to.

I don't believe the C# languages currently in open source for Linux
(the mono project) will be "allowed" to survive, nor do I think
they'll do any better than Java under Unix or Mac (compared to Java
under Windows). This makes cross-platform targets more work if C#
becomes a requirement, so I really hope to avoid the language without
loosing access to features users may come to expect in, say, 2006
through 2008.

I think they'll survive or fail on their own merits. MS certainly isn't
doing anything to stifle the development of Mono or other implementations of
the CLI/CLS and C# language.

-cd

 

[Jason Vene]

With Visual C++ 2005 (aka Whidbey), C++ will be the implementation language
of choice for .NET, IMO. It will be possible to do everything in C++ that
you can do in C#, including produce verifiable images. And you'll still
have C++ templates, separate compilation, and all the other things you've
come to expect from C++.

Ah - that is such welcome news!

 

[Brandon Bray [MSFT]]

I definitely concur with Carl. I can say a few things about several issues
you brought up.

What worse, and my apologies for bring this into the mix on a MS board,
is that I need cross platform development strategies. I have them when
building in C++.

Many of Visual C++'s best customers write code for multiple platforms.
Typically, the practice is to write most of the application in C++ so that
it can be compiled on multiple platforms. The other parts of the application
that have to interact with WinFx or platform specific libraries can be
written using tools, compiler extensions, or languages specific to those
platforms. For Windows, that will be .NET language such as C++, C#, or
Visual Basic. For other platforms, it might be Objective C. Certainly, this
is already the manner in which graphics libraries are abstracted for
multiple platforms.

I don't see this practice changing anywhere in the near future.
Understanding that, Visual C++ is aware and doing what we can do to make
cross-platform development and usage of .NET as productive as possible.

I think it means that many of the future benefits of .NET will be limited
to the other .NET languages.

Without a doubt, we're doing everything possible to make sure every part of
..NET is available to C++. Some features may take more time than others to
appear in C++, but in the long run we're giving access to everything.

How would this play out for WinFX targets? Must I be forced into mixed
mode programming to take advantage of Avalon?

The current display libraries in Win32 (GDI, etc.) are not going away. They
will always be around. Of course, the new "look and feel" libraries are
likely to be managed only (Avalon). So, you should only be compelled to use
Avalon if you really want the new look and feel, or you're inspired by the
programming model. For cross-platform code, using this library can still be
isolated to certain parts of the application that are platform specific.

I really hope to avoid the language without losing access to features
users may come to expect in, say, 2006 through 2008.

Where are you going, in say, two years?

It's not just because I am on the Visual C++ team that I say this, but C++
is definitely alive and thriving. You should feel confident that we are
supporting your scenario.

Cheerio!

 

[Ioannis Vranos]

Now we face .NET, and MS is pushing hard for the development of .NET
applications. It would seem that C++ is the odd man out of that loop. I know
we can generate both mixed and fully managed code targets, but as I
understand it they will not (or ever) be "verifiable" code. I'm not really
sure I understand what that means, but I think it means that many of the
future benefits of .NET will be limited to the other .NET languages.

No, /clr:safe in Whidbey produces 100% verifiable code.

 

[Edward Diener]

Without a doubt, we're doing everything possible to make sure every
part of .NET is available to C++. Some features may take more time
than others to appear in C++, but in the long run we're giving access
to everything.

This is not the case with ASP .NET. Visual Studio does not support ASP .NET
development using C++. Yes, one can dive into .NET itself and do ASP .NET
development without using Visual Studio, but that is not putting C++ on par
with the other .NET languages.

 

[Mark]

The current display libraries in Win32 (GDI, etc.) are not going away. They
will always be around. Of course, the new "look and feel" libraries are
likely to be managed only (Avalon). So, you should only be compelled to use
Avalon if you really want the new look and feel, or you're inspired by the
programming model. For cross-platform code, using this library can still be
isolated to certain parts of the application that are platform specific.

So if I understand you correctly, here are the options
for GUI development:-

1. Win32 GDI
2. GDI+
3. .Net forms
4. Avalon

Items 1-3 are going to be obsoleted in the next version of
windows (ie no improvements will be made).

So what are we supposed to do in the mean time?????

This is a bad situation for developers. Why should we have
to rewrite our GUI's every 2 years on the whim of a microsoft
fad?

What I would like to happen is for the GDI+ library
to be finished properly, and that the Win32 API calls
for menus etc be updated to the new look/feel automatically
(as the file open dialogs are).


Mark.

 

[Ioannis Vranos]

So if I understand you correctly, here are the options
for GUI development:-

1. Win32 GDI
2. GDI+
3. .Net forms
4. Avalon

Items 1-3 are going to be obsoleted in the next version of
windows (ie no improvements will be made).

So what are we supposed to do in the mean time?????

This is a bad situation for developers. Why should we have
to rewrite our GUI's every 2 years on the whim of a microsoft
fad?

What I would like to happen is for the GDI+ library
to be finished properly, and that the Win32 API calls
for menus etc be updated to the new look/feel automatically
(as the file open dialogs are).

No WinFX will be .NET (.NET becomes WinFX including Avalon). For past
versions of Windows, new versions of .NET will keep coming out.

 

[Brandon Bray [MSFT]]

Items 1-3 are going to be obsoleted in the next version of
windows (ie no improvements will be made).

I would not say that no further development is the same as obseleting a
library. These libraries can never be made obsolete -- they are too widely
used.

What I would like to happen is for the GDI+ library
to be finished properly, and that the Win32 API calls
for menus etc be updated to the new look/feel automatically
(as the file open dialogs are).

Just like Windows XP updated the look and feel for these libraries, I'm sure
that will continue for a long time. There will be some features, like taking
advantage of GPU capabilities, that will be available only in new libraries.
That would have been true even with existing libraries though -- new APIs
would be the only ones with new features, and you'd have to revise your code
to use those APIs.

 

[Brandon Bray [MSFT]]

This is not the case with ASP .NET. Visual Studio does not support ASP
.NET development using C++. Yes, one can dive into .NET itself and do ASP
.NET development without using Visual Studio, but that is not putting C++
on par with the other .NET languages.

As I said, we intend to support every feature of .NET over the long run.
While ASP.NET is not strictly a CLR feature, it's programming model is one
that we could support when we spend resources on it. Thus far, customers
have been very clear that writing ASP.NET web pages with embedded C++ is not
a high priority. Nevertheless, programming models similar to ASP.NET are
becoming more common, and we are taking notice.

Like every engineering project, we have to balance resources and features to
produce the most benefit for the largest set of customers.