visual c: [quoted text, click to view]

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

[quoted text, click to view]

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.

[quoted text, click to view]

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

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?

[quoted text, click to view]


Ah - that is such welcome news!

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

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

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!

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/

[quoted text, click to view]




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



--

[quoted text, click to view]

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.

[quoted text, click to view]

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

[quoted text, click to view]


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



--

[quoted text, click to view]

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.

[quoted text, click to view]

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, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/

[quoted text, click to view]

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.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/