An interview with Microsoft's new Visual C++ .NET community liaison

Herb Sutter has just joined Microsoft as their new Visual C++ .NET community guy. Read about who he is, what he does, and what is happening with our beloved Visual C++.

Herb Sutter is secretary of the ISO/ANSI C++ standards committee, is an
accomplished author and C++ expert, and has just joined Microsoft in the
Developer and Platform Evangelism Division. Herb will be primarily engaged in
liaising with the C++ developer community, and will also be working in product
planning and design of Visual C++ .NET.

Since Herb is new to the Microsoft fold I grabbed a few minutes (well, hours)
of his time so we could get aquainted with who he is, what he does, and what,
exactly, is happening with our beloved Visual C++.

So Herb - can you give us a quick rundown of your background and what you
were doing before signing on with Microsoft.

Well, I've been doing mainly a lot
of C++ writing, teaching, and consulting, and the C++ community is very
important to me. By the way, I'm going to continue doing those things; that
community contact is why Microsoft saw a good fit to hire me, and they want me
to keep doing it.

So what is that today? Well, right now I'm secretary of the
ISO/ANSI C++ standards committee, and I've participated actively in that
committee since 1997. I'm also writing four columns about C++, mostly in C/C++
Users Journal where I'm also half of the magazine's editorial board, reviewing
and editing other authors' articles and recommending what should be published
and what needs work. I've got two C++ books out with Addison Wesley, Exceptional
C++ and More Exceptional C++, and I'm working on two more, one with Andrei
Alexandrescu. Everything I write, except for the final versions of material in
the books, gets posted free for public reading on my website, www.gotw.ca. I've
also been a moderator of the primary Internet newsgroup for the C++ language,
comp.lang.c++.moderated, since its inception in 1995.

Again, all of that's going
to continue. What's new is that I'm now also going to be Microsoft's liaison
with the C++ community on all platforms, not just Windows, to keep the Visual
Studio .NET team in touch with the community and make sure that what the
community needs gets into the product.

What made you decide to join Microsoft? Did they have to convince you or did
you pursue Microsoft?

I'll admit that it would have been a lot less tempting two
years ago, back when Microsoft didn't seem all that interested in Standard C++.
But in the past 12 to 18 months I've noticed a real change in priorities at
Microsoft, as they've resumed joining us at the committee meetings and as
they've started contributing to the community and started making noticeable
progress with their product's standards conformance. I discovered, to our mutual
pleasure, that now not only is conformance to the existing 1998 C++ standard as
important to them as it is to me, but that they want to keep tracking the
next-generation C++ standard whose development is just underway.

What will be your role at Microsoft?

My job is to be Microsoft's liaison with
the C++ community. "The community" includes the standards committee,
C++ conferences, and developers on all platforms. After all, Microsoft is
naturally interested in making their tools appealing to everyone, even those who
aren't using them yet, and conformance is an important part of making migration
possible. There are many reasons, plus my own pre-existing personal ones, to be
committed to fulfilling today's C++ standard and assisting the future
development of the standard. A rising tide floats all boats, and standards
conformance is good for everyone.

I hope to make a noticeable mark in the
product. So now I need to give you a heads-up about something that I want to be
very clear about, and namely "why" and "when" I will be
pushing for language extensions in Microsoft's C++ even before the product is
fully compliant to today's standard. Let me put it in perspective and then lay
out my personal agenda:

Microsoft intends to conform 100% to Standard C++ as
soon as possible. Period, no question. It won't all be in the next release,
although many conformance improvements will be. Admittedly there's some catching
up to do and it can't all happen in a week or a month or a dot release. But it
will happen, and as soon as possible.

Having said that, let me tell you the two
groups of conformance-related features that are the most important to me,
because they're what the C++ community consistently tell me they need: My one
"must-have" feature group consists of everything needed to conform
100% to current Standard C++ (a.ka. C++98). My other "must-have"
feature group is key extensions that we as a community know perfectly well we
need, but which are missing in C++98, usually due to just oversights or mistakes
- yes, we standards guys are just humans, and we sometimes miss stuff too. Some
of these are just obvious omissions that will certainly appear in some form in
the next version of the standard (a.k.a. C++0x).

Here's the punchline: To me,
those are not two lists, where you do everything on the first list (C++98
conformance) before you start working on the second (key necessary extensions).
To me, those things all make up one list, that then gets prioritized so we can
put as many of the most important things as possible into each release. That
means that you can bet I will be pushing hard to get some key extensions beyond
C++98 into the product even before we finish all the things to conform to C++98,
because frankly some of the extensions are more important to the Standard C++
community than some missing C++98 features. We're definitely going to do all of
C++98, no question. But if I have my way we're going to do it in the order that
will benefit the global C++ community the most quickly - that's my assigned
vested interest to promote within Microsoft, that we deliver what the global
community needs as quickly as we can.

Let me give you a concrete example: Visual
Studio .NET (Visual C++ version 7.0) doesn't yet have support for the
"export" keyword which is in the C++98 standard, nor does it have
typedef templates which are not in the C++98 standard. (As I'll point out in a
second, nobody else has either of those features yet, either.) I will be
pounding on the table during every design meeting you'll find me in to put
typedef templates into the product before support for "export" simply
because typedef templates are a lot more important. Even though typedef
templates aren't in C++98, that's just a bad oversight; I don't know of an
expert in the world who doesn't agree that typedef templates are obviously
needed, and needed more than "export". On the other hand, as of our
interview today, there's not a single released C++ compiler in the world that
supports "export" (Microsoft is not alone here!) and the community is
hardly clamoring for it. Edison Design Group and their licensee Comeau have an
"export"-capable compiler in beta and will be shipping sometime soon,
which I think is great, but if you sit me down at a table and put
"export" beside typedef templates in front of me, I'll choose typedef
templates every time, even though they're not officially in C++98, because key
community libraries like Boost and Loki would really benefit from them; hey, the
standard itself had to do that funky alloator::rebind hack just because we
didn't have typedef templates, and the standard even says so! Here's a direct
quote: "The template class member rebind … is effectively a template
typedef"! That's just way more important. We'll do "export" too,
of course, but first things first.

Don't get me wrong, I'm certainly not pushing
for a lot of extensions, and certainly not anything where there isn't already a
clear need and some community agreement. And when I propose those features
within Microsoft, it will be after I've already talked with the world's top
experts about how important they are and how they should be specified; I hate
half-baked homebrew misfeatures and that's certainly not what I'm after here.
I'm pushing for a handful of carefully chosen and carefully implemented
extensions that the community is clamoring for, and which are not proprietary
but rather the opposite: things we already know are certain or likely to come in
C++0x and which we hope all compiler vendors will provide too. A standards
committee can sometimes be inventive, but mostly it's supposed to standardize
existing practice; I want to help Microsoft help the standard by providing just
that "existing practice in the field" for these key upcoming features.
Indeed, by trying to carefully wield Microsoft's product as a leader in this way
I personally hope to help move the whole community forward on all compilers and
platforms, as other products are encouraged to implement them too, which will
benefit everybody no matter whose tools they're using.

Bluntly, if I have my
way, then people are going to ask, "how come Microsoft put Extension X into
the next version of VS.NET, when they haven't even finished conforming to C++98
yet?", and I hope they ask that because if they do then I've done my job.
No worries, full C++98 compliance with "export" and the kitchen sink
is coming on apace, and will get done, no question. But if I have my way we'll
do that whole unified wish-list of C++98 and pre-C++0x standard features in the
order that best serves the community, because that community priority is what
I'm being paid to push inside the company.

As 'Community Program Manager' will you be involved directly with the
community? In what way? Will you be providing more of a direct link for the
community and Microsoft itself? Can I pass all the 'how do I do X in C++'
questions I get from readers on to you? Please?

Yes, lots, yes, no oh please no,
and not even if you say pretty please, respectively. Ahem. Seriously, though
some questions are okay, but at least get people to read the C++ FAQ (www.parashift.com/c++-faq-lite)
and my website (www.gotw.ca) first to see if there's already a well-known
answer.

It's my job to know what the community wants. That's why I'm going to
continue speaking and listening to attendees at conferences, in my private
independent consulting, on the public newsgroups, in email conversations with
readers of my columns and books, over coffees and dinners at standards meetings
with the top gurus and with the other vendors, and everything else I'm already
doing.

C++ developers are still not getting as much love from Microsoft as VB.NET or
C# developers. Is this something you hope to change? How?

That may have been
more true until recently. I've seen some changes already in the past six months,
and I'm looking forward to seeing more. There's no question that Microsoft is
investing in C++, internally and externally. Look for further Microsoft
community participation by contributing to platform-neutral community libraries
and in other ways.

What do you see as C++'s role in a .NET world?

C++ is still by far the most
powerful language in the .NET universe, and the one that more commercial Windows
apps are written in. That's not likely to change anytime soon.

What do you see as the future of C++ overall?

C++ continues to be relevant,
dominant, and in widespread and still-growing use. The C++ standard and
standardization process also continues to be relevant - committee membership and
participation has increased since the first standard was published in 1998, and
lately we've had more countries represented at our ISO meetings than ever
before. Usually the opposite happens when a standard is completed and the
committee goes into maintenance mode for a while - companies stop sending
people, because they all have their own work to do after all. But not here: even
while we were in maintenance mode for several years, ISO/ANSI membership has
pretty much never been stronger, and all the vendors, including Microsoft, are
there together actively working on the next-generation C++0x standard whose work
is now getting underway.

Managed extensions for C++ have received a lukewarm reception from many
developers. What do you feel Microsoft can do to make MC++ more approachable for
the typical C++ developer?

For one thing, MC++ has to support more of Standard
C++. There is (how can I say this politely) room for more overlap. There, I
think that was subtle enough. The team is hard at work on these kinds of issues.
I think that .NET is good for C++.

Do you really believe that .NET is good for C++? Why?

I do. I'm hopeful that
it can contribute something valuable, perhaps even beyond Windows-based
platforms.

Here's a for-instance: Within the standards committee and the
standards process, I've seen several key recurring questions and wishes since
C++98 was passed. Three of them are: a) "what about standardizing thread
support?"; b) "what about compiling C++ to the JVM?"; and c)
"what about a portable GUI library, something basic that will help with
teaching?" I think it's very interesting that .NET provides all three, and
more, and that it makes those things available to C++ programs. In particular,
well before I had any idea I would come to Microsoft, I'd thought that .NET was
"a better JVM" (plus a lot more of course). If we could get better
convergence between "Managed C++" and "Standard C++," which
is something that the team as a whole and Stan Lippman in particular are working
on right now, this whole thing could get really interesting and there might be
some useful standard technology to offer here someday if the C++ committee wants
any parts of it. I'm saying that with my "committee-member" hat on,
not my "Microsoftie" hat on. After all, this very possibility is one
of the cool ideas that hooked me into wanting to participate with Microsoft and
see what I could be part of contributing to the committee and the community,
because like everyone else I've been looking for answers to those same three
questions, and here's a technology that's already being standardized (in ECMA
and soon ISO), and look, it works with C++! Well, with a lot of C++, anyway.
We'll have to see how it goes, though. I don't think it's any shape yet to
submit it; we'd pretty much have to be able to run nearly all of Standard C++ on
.NET just to have a proof-of-concept starting point that the committee would be
interested in. It's a goal. We want to contribute where we can.

But C++
developers on all platforms wants these kinds of things - threads, running on a
VM, a managed GUI library. Windows-based developers have a lot of it today, and
I know that the Visual Studio .NET team are working hard to make it better so
that you don't have to give up so much of Standard C++ to get those benefits.

Why should C++ developers be excited about what Microsoft is doing for C++?

Besides the .NET stuff I just talked about, which I think has potential to help
C++ as a language, Microsoft is also interested in contributing more, and more
often, to the C++ community. Part of my job is to make sure that stuff that
Microsoft has been developing in Research can start more regularly getting
submitted openly to community libraries like Boost, so that developers on all
platforms can benefit from them. We're working hard on that. Pardon me, I've got
to go beat on some lawyers' heads about that; back in a sec.

How large is the C++ community?

Depends how you count, but the best numbers I
keep seeing put the global developer community at something like 9.5 million
people, and those using C++ at about 3 million of that. That's well ahead of
Java in nearly all studies I've seen, by the way, usually by a factor of
1.5-to-1 or 2-to-1. And showing C++ still modestly growing, also by the way. All
without aggressive marketing, yet again by the way. The reports of C++'s demise
have been, well, "exaggerated."

What sets the C++ community apart from other types of developers?

C++
developers need power and know how to use it. I've always said you should use
the best language for the job, and I've used dozens of languages professionally.
Depending on how you count languages, I've probably used a dozen professionally
in the past year. People who want to write efficient, tight, fast code often
tend to choose C++ because it lets you get the job done with powerful code but
without sacrificing efficiency.

People who want mature, stable compilers and
tools often tend to use C++ because it's been around a while and the tools and
libraries are plentiful and solid. Commercial client-side application
development with more than a few screens, most kinds of server-based software,
and most kinds of libraries are all done more often with C++ than with other
languages, according to the best numbers I've seen and according to my own
experience as a developer and as a consultant who shows up at other developers'
shops.

How will C++ evolve going forward? What is Microsoft's role in determining
this?

The coming C++0x standard will heavily emphasize additions to the library,
not to the core language. Expect to see a few well-chosen core language
extensions, such as typedef templates, but not any huge fundamental changes like
templates and exceptions were in their day. In the standard library, on the
other hand, do expect many extensions, from obvious low-hanging fruit like
hash-based containers and threading support to possibly things as big as a VM
model or a basic GUI library, and lots of useful stuff in between. To get some
idea of what kinds of things you might see, check out Boost (www.boost.org),
although I hasten to add that we on the committee are looking for input from the
whole community, don't think Boost has some inside slam-dunk track.

Along with
the other C++ vendors and experts, Microsoft will continue as an active
participant in the ISO/ANSI C++ committee, contributing its people's expertise
to help formulate and refine proposals that will improve the coming C++0x
standard. It also wants to contribute technologies or research of its own, if
the committee thinks that those facilities will help the C++ language's
evolution. Microsoft is now committed to supporting the community and being an
active participant and contributor.

What's currently happening with C++? What's the latest gossip?

C++0x, man!
It's a whole new standard out there! Or, at least, it will be once we're done.
Give us a few years, it's just getting underway now. At the most recent
standards meeting, held in October 2001, we already started considering the
first batch of potential additions to the C++ standard library. There were seven
proposals, from threading support to hash-based containers, all of them fairly
self-contained and smallish ones to start with (well, okay, the threading one
isn't that small). There's a lot more exciting stuff on the way; that's just the
beginning. I've recently started writing a new column for C/C++ Users Journal
called "The New C++" that will cover these topics, and in fact already
has detailed many of the above - see the links on my Publications page,
www.gotw.ca/publications, that are tagged "TNC++" (the acronymized
column name).

No matter how many statements are made about C++'s rosy future, pessimists
continually use these same statements to conclude that C++ is dead. How would
you respond to the pessimists?

I recently read an interview with some C++ guy,
and when he was asked about the size of the C++ community, he said something
like: 'Depends how you count, but the best numbers I keep seeing put the global
developer community at something like 8.5 million people, and those using C++ at
about 3 million of that. That's well ahead of Java in nearly all studies I've
seen, by the way, usually by a factor of 1.5-to-1 or 2-to-1. And showing C++
still modestly growing, also by the way. All without aggressive marketing, yet
again by the way. The reports of C++'s demise have been, well,
"exaggerated." '

Share

About the Author

Chris is the Co-founder, Administrator, Architect, Chief Editor and Shameless Hack who wrote and runs The Code Project. He's been programming since 1988 while pretending to be, in various guises, an astrophysicist, mathematician, physicist, hydrologist, geomorphologist, defence intelligence researcher and then, when all that got a bit rough on the nerves, a web developer. He is a Microsoft Visual C++ MVP both globally and for Canada locally.

His programming experience includes C/C++, C#, SQL, MFC, ASP, ASP.NET, and far, far too much FORTRAN. He has worked on PocketPCs, AIX mainframes, Sun workstations, and a CRAY YMP C90 behemoth but finds notebooks take up less desk space.

He dodges, he weaves, and he never gets enough sleep. He is kind to small animals.

Chris was born and bred in Australia but splits his time between Toronto and Melbourne, depending on the weather. For relaxation he is into road cycling, snowboarding, rock climbing, and storm chasing.

Comments and Discussions

Actually, a good portion of what he said wasn't true. VC 6 predated the standard, so claiming it wasn't standards conforming is a bit off. In point of fact, when released it came closer to the then draft standard then any other C++ compiler on the Windows platform. Even starting with VC 5 they had hired Mr. Plauger, an industry recognized C++ expert and member of the standards committee, to develop their standard library. These facts don't fit with the claims made by the OP.

In more recent years I've felt like MS had given up on C++, and in general in the past standards were only good so far as MS could find a way to make them help their bottom line (in other words, I believe VC++ became as standards conforming as it did with VC 5 and 6 in order to gain market share over Borland, and once that was accomplished we saw the diminishing interest in the standard).

As for Mr. Sutter selling out... not a chance. Again, many on the standards committee are sensing a change in MS, and this, I'm sure, is what compelled him to join. I suppose it's possible that MS is snowing us (I don't think so... I've talked to enough key people to believe otherwise), but if that's the case it just means Mr. Sutter was fooled, not that he sold out. I think you should be more careful with accusations like this... it's one thing to level it at a company and quite another to do so at an individual in a public forum.

BTW, the scuttlebut is that 7.1 compiles a lot of the Boost libraries with out the need for the current VC hacks, and if this is true there's no reason to question if they are striving for compliance.

I did C++ for about 7-8 years and a really love it. But now, in the company I work for, there was a shift to C#. Personaly I didn't like COM and I don't like MC++, because that it's not c++, it's pure garbage. But as I must do a living I must work in C#...

I don't think that Microsoft has plans for c++, as they keep throwing to us all this .Net thing...

Heh, the article would be 50 pages long if Chris tried to ask about ever user's gripe.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

It's already been stated that PTS is working, and Loki compiling at Microsoft internally. Herb may have thought it was old news - we are guarenteed PTS in the first service pack which is due mid year AFAIK.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002

While working on a MSVC port of Loki, me and a few others before me, stumbled upon a (perhaps accidental) M$ extention of C++ templates. The M$ compilers allow you to specialize nested template classes, which can be used a work-around for the lack of PTS in many (though not all) cases.

You can implement any PTS of the 'partially-specified template paremeters' flavor; but you cannot implement the 'special behavior with this combination of parameters'. With that you turn to aggregation, MI, and overloaded functions. Very messy compared to the straight-forward PTS implementations... but it can be done.

What Herb and, in another interview, Stan are telling the C++ community about the new MS direction sounds (perhaps too) good, but how can we see if they - MS - stay on track? My evaluation criteria are mostly a consequence of my reasons for using C++ in the first place.

I like to use C++ because it is "The Language of Choice" (pun intended):

I) C++ allows us to "write efficient, tight, fast code" without having to choose >between< performance and other design qualities, but >among< all of them, e.g. better performance against runtime flexibility, w/o loss of abstraction (like using templates instead of inheritance in some places).

II) C++ serves us well if we have to create modules/components wich can be used in totally different contexts even if they have to be closely integrated. (This is what Loki etc. is all about.)

III) C++ will allow us to combine many different generic components which can closely interact without loss of performance or type safety.

Now, what do I want to see in the "ultimate VC++ system":

1) I want to be able to cleanly separate code which directly uses .Net from code which doesn't. It should also be possible to port libraries like ACE and QT to .Net so some code can even use .Net functionality without knowing of it. (And, of course, without performance penalty.) Some .Net functionality must be available with standard library bindings, e.g. special IOStreams, standard conforming i18n, Iterators for data access etc.

2) I want to be able to use all this funky, cool new template metaprogramming stuff, eg. in the Loki, Blitz, MTL, FACT or FC++ libraries, so:

a) VC++ must compile them flawlessly b) it must create fast code, eliminating the abstraction penalty of e.g. maybe dozens of layers of inline functions c) it must compile and link any template jungle blazingly fast d) debugger and profiler must give us easy and flexible access to template specific information, e.g profiles of >all< instantiations of a template function vs. profiles of >specific< instantiations e) error messages from template code need to became legible, IMHO we need some kind of expandable/navigable/configurable hypertext system

3) I want to use true multi-paradigm design and programming techniques productivly, so code (class) browsers, wizards etc. need to became template aware and have to support generic programming as effectively as OO

4) I want to design and program more agile, so i would need tools which allow better restructuring of project/modules/configurations and fast refactoring of source code (a refactoring browser for C++ is long overdue, and maybe integrating unit test could be made easier)

These points definitly comprise a tough order, an I am aware of some of the reasons why they have not been realized yet, or may even be seen as totally unrealistic, but this is what C++ is all about: If you don't like it, write tools for "easier" languages.

If you - or someone else - manages to achieve all this, we could paraphrase Winston Churchill: "Never in the field of" ... C++ programming ... "was so much owed by so many to so few."

An interin compiler release at MS$ already compiles fully this libraries, expect this on sp1.

Uwe Schnitker wrote:ACE and QT to .Net

What ! QT sucks! Any library that uses a proprietary sistem of Event Dispatching que must pass for their custom (moc) compiler is totally idiot,c++ is the most powerfull language, and they're much more cleaner solutions to this kind of GUI dispatch. AFAIK Delphi 6 and Kylix uses QT, but Borland replaced this evil Event dispatching for a their own,so it doesn't need to be compiled every time we add a Event/Signal Slot to the class

I'm currently studying ACE, it's a very powerfull framework, also a complex one, and will be interesting if the C++ and pattern gurus that designed it, ported it to .NET .

IMHO, it has a nice architecture and a sound OO design. It is powerfull, versatile, flexible and yet very easy to use. Quite a feat.

>Any library that uses a proprietary sistem of Event Dispatching que must pass for their custom (moc) compiler is totally idiot,

No! It's a pain in the neck, and it's definitely a wrong idea according to the principles and philosophy of modern C++. But it was/is a viable way to support broken compilers, and it was a quite sensible design solution in the context of "classic" (pre-modern) C++, which is where most C++ programming is done today, whether we like it or not.

>c++ is the most powerfull language,

You're so right ...

> and they're much more cleaner solutions to this kind of GUI dispatch.

Definitely!

The "signal/slot" approach should be integrated into a generic, policy-based callback system, working with generic functors, both of them also supporting non-intrusive use. ("Andrei ...")

I'd suggest - and I'll try it in my own, future work - to encapsulate all this unholy QT stuff in a small part of the application, just like other legacy stuff. (Definition: Legacy code is code written in a way you don't happen to like.) And I'll wait and hope for the future - unfortunately, working on a full-blown portable GUI framework isn't something I'll get into in the near future.

Uwe schnitker wrote:The "signal/slot" approach should be integrated into a generic, policy-based callback system, working with generic functors, both of them also supporting non-intrusive use. ("Andrei ...")

Quite a nice idea, it the trolltech guys listen to you ... Perhaps in QT4 ?

Uwe schnitker wrote:full-blown portable GUI framework isn't something I'll get into in the near future.

I don't want to have anything with that ! Portable Gui frameworks means too much work ...

Uwe schnitker wrote:yet very easy to use

QT it's not a modern frawework , it's not templatized , but also it's not bad either, it's the pain in the neck that I refuse to take.

When they change the design of it, perhaps I'll the first to use it, if not ... well perhaps wxwindows or gtk--(templatized framework) using gtk+

ps: Herb,I hope you will have time to keep working on www.gotw.ca, the conversations column and "Even More Exceptional C++", "Yet Some more Exceptional C++" and "I do still have some Exceptional C++ so you mere mortals realize those subtle details about C++ and say 'I though I was proficient with C++ sigh'"

Of course, the fact that MS actually felt in necessary to hire an Evangalist for the language in the first place says a little something about the current place of VC++ in the overall food chain.

I suspect that as time goes on, VC++ will be used less and less for application development and more for rocket science under the hood when people truly need the power of a language that doesn't say "no". Sadly. I've got around 9 or 10 years of VC++ under my belt. It'll be a while before I get that kind of road behind me in the latest trendy language du juor.

Christopher Duncan wrote:I suspect that as time goes on, VC++ will be used less and less for application development and more for rocket science under the hood

I sincerely hope that you are wrong on this , it will be a tragedy , if such a thing would happen Also, the VC++ team are building for VC++ 8 a MC++ Visual Buider, so I hope that the MFC VC++ users, hold up and not completely dissert to c# Note, I don't dislike the C#, and probally will like more with the inclusion of generics on the next VS .NET version.

In the end, I'll learn whatever languages I must in order to keep working and making the money to which I've grown accustomed, but I really like a language that doesn't say "no".

I haven't been an early adopter of the .NET stuff because I have a "wait & see" attitude regarding how much work will be out there, what it will pay, and whether the investment in time is worth it. As an example of my reasoning, I spent a couple of years writing ActiveX controls. Career wise, a complete waste of time.

If .NET takes off and looks like a profitable use of my tecnical time, I'll be all over it. I'm a mercenary. Absolute loyalty to the highest bidder.

Joao Vaz wrote:I tented to buy your book, but since is about Corporate America, I have my doubts about the applicability of your ideias to a small country like Portugal on which I live.

I get asked a lot about my use of "Corporate America". I used that phrase primarily for two reasons. First, to be honest, it was catchier than "The Corporate World". However, the other part of it was that I've only worked in America, and so I thought it would be inappropriate and presumptious to talk about countries where I had never worked. However...

As it turns out, I've got a ton of email from all over the world with programmers reporting the same kind of corporate insantity in their country as I've encountered here. Apparantly, management is not too bright no matter what part of the world you're in.

Is it the same in Portugal? Beats me, haven't been there (yet, anyway!). However, Chris M. will have a sample chapter posted shortly (as soon as the rabbit gets clear of the headlights, right, Chris?) and you can see if it applies to your environment. In any event, it's kind of you to consider it, and I appreciate the thought!

Calm down Paul, I'm sure MC++ will not be dropped, I still not used MC++ but I'm planning to use it at home, since it have some good uses.For instance, for COM programming it's cool since the attributes generates automatically the idl, one less headache for COM programmers, and I think the _gc attribute for garbage collection it's not bad either if you want to use it. Atribute Based Programming isn't going to die, and it's more like a new feature to OOP world, just like templates are.

All these lines, just to say that MC++ have <<his>> own space like in COM/ATL programming(and more of course), and I'm not seeing in a near future MS dropping suport for all COM programmers out there like you Paul

So, with the hiring of this <<C++ gurus>>, I think that Microsoft is on his way to increase standard compliance, and I see this as definitely a good thing like adding full PTS(partial template specialization) will increase the design and flexiblility of your classes and the frameworks like WTL

Standard C++ and MC++ have to coexist peacefully and this I think will be one of the tasks for Herb, and I cannot see Herb, to simply discard COM support on MC++ !

Regards Paul,

note: I'm know that you are a bit more nervous, because you can't wait for April to use WTL 7

Joao Vaz wrote:I'm know that you are a bit more nervous, because you can't wait for April to use WTL 7

Hello Joao, come again. Do you have any word on this? We are raising a big ATL/COM project (of course wrapped in WTL ), so yes I am nervous

On the other stuff, you see MS has its own way of killing products. To use Visual Fox Pro now you have to pay extra $500, since it is no longer included in the VS. MC++ is really cool, mixing managed and unmanaged C++ in the same file is something no other .NET language is offering, so lets defend it. They have deprieved us of the visual tools to be productive and I am not happy at all!

Well, listening to you guys talk about MC++ makes me wonder which of two things is going on. If they didn't include all the visual tools with MC++ that the darling new languages get, I can see it as one of two possible scenarios.

Either your assertion that they're out to kill MC++ is correct (MS is known for heavy handed tactics), or this is just another, normal instance of what's all too common in our industry - all of us, not just MS. Is it a possibility that they plan on adding all the visual tools to MC++, but haven't thus far because they were in a hurry to get a release out the door?

I can see it either way. Clearly, it looks like MS wants us to write .NET apps in either C# or VB. Historically, trying to swim upstream against the current of where MS wants you to go only makes you tired. Ultimately, my priorities regarding which approach I embrace are very simple - where will the jobs and the money be - C# or MC++?

Quick correction: I'm NOT an evangelist. (shudder at the thought) That "e" word just happens to be part of the formal name of the overall umbrella division, which includes everyone on the development team too as well as QA and marketing etc. I am a Program Manager, which is a technical and architectural role.

While I certainly didn't mean to ruffle any techie feathers with the "e" word (I guess that would be the same as accusing a programmer of collusion with the evil brotherhood of Marketing), I guess my main point was that if everything was warm & fuzzy in the VC++ world, Microsoft would never have seen the need to create this position in the first place. While I'm sure it's only a part of what your position will address, "liason" is often the term applied to a person sent to the other camp to smooth things over.

As I've mentioned, I see a future in which my net worth (er, no pun intended) as a seasoned VC++ guy, in terms of the hourly rates & can get and number of jobs on the market, will diminish as the .NET initiative continues. That not only affects the language I've grown to love, but also my bank account (at which point it begins to become a serious issue). I'm sure I'm not the only MFC guy to feel this way.

Having said that, I find it at least somewhat reassuring that Microsoft has created such a position. It still doesn't alter the overall future as I see it (i.e., it's either become a "trendy technology of the week" programmer or kiss those high hourly rates goodbye), but it's nice to see that we're not completely abandoned.

Nonetheless, it does appear that the days of the VC++ programmer commanding top rates and a limitless supply of jobs will soon be over.

Christopher Duncan wrote:Nonetheless, it does appear that the days of the VC++ programmer commanding top rates and a limitless supply of jobs will soon be over.

I think you're right, and I think that C# is going to take over a lot of C++'s role in the Windows world. But I am very encouraged to see that Microsoft seems to be recognising that there will remain a place for C++ in this .NET centric world. I also would suggest that you chose the wrong career path if you wanted to learn a skill and use it 'til you died. This is not the first time this has happened - I believe Windows programs used to be written in C. From the perspective of a person who came onboard with C++, when I need to write in C, (when I've written articles for WDJ), it has seemed primitive and ugly to me. I don't doubt that people who learn starting with C# will see C++ the same way, regardless of how we old timers talk about how powerful life was with C++. I'm sure you can still find people who wish they still used C and optimised the assembler to improve speed.

I will always love C++, and I hope it remains relevant in the future, but I consider managed C++ to be a joke. If I want to write for the CLR I will write in C#. I know that managed C++ creates optimised CLR code, but if I want speed, I'll go direct to C++. I recently started a new job, and I am having a ball precisely because I have had to throw away all my MFC knowledge and learn how to do things differently. My approach is I will continue to try to be the best C++ programer I can be, but I'll also learn C#, and anything else that crosses my path. Then I can pick my jobs because I'll have a wide range of experience, and my life will always be interesting.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002

Christian Graus wrote:I also would suggest that you chose the wrong career path if you wanted to learn a skill and use it 'til you died. This is not the first time this has happened - I believe Windows programs used to be written in C.

Oh, I definately agree with you there. And actually, it's always fun learning new stuff. However, what I want to avoid is spending a lot of time learning something new only to find that the market ignores it, like my example of time wasted learning to write ActiveX controls.

I started out in C, and I was not an early adopter of C++. I only picked it up around 1992/93 whenever VC++ 1.0 came out. At that point in time, C++ had been around for a while and it was by then clear that it was going places. I don't have the same confidence with C#, or the .NET technologies in general just yet. It may turn out that a huge demand for .NET apps written in C# arises. When I see the writing on the wall for that, I'll embrace the language myself. However, it's not the no brainer choice that many Microsoft technologies have been in the past.

Microsoft has done such an uncharacteristically poor job of marketing .NET in general (there are huge groups of people out there who still don't know just exactly what the heck .NET is suppose to be) that it's just not a sure bet that .NET will be a gold mine for developers. I pay the rent with this stuff. I care about where the jobs are, and how much they pay. This is my passion, but it's also my livlihood.

.NET is Microsoft's attempt to dominate the Internet, and for the first time in recorded history, they ain't doing so well. Whine about monopolies all you want, I liked it much better when being a Microsoft Windows programmer was a no brainer because there was nothing else out there with the market share that they had. That's no longer true with the popularity of the Internet. It's way too fragmented, and no development platform dominates the scene. What do I develop in, where will the jobs and money be? ASP, C#/.NET? ActiveX? (er, probably not.) Java? Perl? Cold Fusion? DreamWeaver? Cgi coding on a UNIX back end? Etc., etc. Lots of choices. Too many choices. I wish Microsoft would just figure out how to dominate the Internet and get on with it so we could just go back to coding and not wondering about the future.

Christopher Duncan wrote:However, what I want to avoid is spending a lot of time learning something new only to find that the market ignores it, like my example of time wasted learning to write ActiveX controls.

That is fair enough - I adopted a wait & see on .NET initially both for that reason and because of possible changes during the beta phase.

Christopher Duncan wrote:I don't have the same confidence with C#, or the .NET technologies in general just yet. It may turn out that a huge demand for .NET apps written in C# arises. When I see the writing on the wall for that, I'll embrace the language myself. However, it's not the no brainer choice that many Microsoft technologies have been in the past.

I tend to agree for traditional windows apps, although I still think that the chances are good enough that it's worthwhile to make a start on C#, even if we don't invest in it heaviliy just yet.

Christopher Duncan wrote:Microsoft has done such an uncharacteristically poor job of marketing .NET in general (there are huge groups of people out there who still don't know just exactly what the heck .NET is suppose to be) that it's just not a sure bet that .NET will be a gold mine for developers. I pay the rent with this stuff. I care about where the jobs are, and how much they pay. This is my passion, but it's also my livlihood.

That's fair enough, but I think the problem has not been M$, so much as the misrepresentation in the media, fuelled by M$'s legal hassles. .NET means you have to rent software, .NET means that Microsoft can see your computer, .NET means you need to call Microsoft every time your computer changes, .NET means that Microsoft will shut down your OS when they want you to buy a new one, etc. I reckon Microsoft's legal hassles have been an impediment on their being able to fight through all that smokescreen.

Christopher Duncan wrote:.NET is Microsoft's attempt to dominate the Internet, and for the first time in recorded history, they ain't doing so well.

Moving into browser based development, I am starting to think the one area where .NET will not fail is the sort of work we do, where our deployment is to a specific customer, so we can make sure they have the CLR, and where ASP.NET is a very attractive alternative to asp. In fact, I've heard it said that ASP.NET is the killer app of .NET, and I tend to agree.

I'm in the middle of installing my spanking new copy of VS.NET as we speak.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002

Christian Graus wrote:In fact, I've heard it said that ASP.NET is the killer app of .NET

Well I'm all for the next Killer App. In fact, I've been hearing good rumblings about ASP.NET. I've been working on an online record store using regular ASP, and it's my first non trivial web development effort. I've gotta say, after years with C++ and a real debugger, I find ASP development akin to trying to build a skyscraper with TinkerToys (er, children's building blocks for those of you unfamiliar with them). I miss the raw power of the language, and the robust debugger I get in C++. I hope this isn't the future of development & debugging! I'm used to power tools. Not power toys.

Christopher Duncan wrote:I liked it much better when being a Microsoft Windows programmer was a no brainer because there was nothing else out there with the market share that they had. That's no longer true with the popularity of the Internet. It's way too fragmented, and no development platform dominates the scene. What do I develop in, where will the jobs and money be? ASP, C#/.NET? ActiveX? (er, probably not.) Java? Perl? Cold Fusion? DreamWeaver? Cgi coding on a UNIX back end? Etc., etc. Lots of choices. Too many choices. I wish Microsoft would just figure out how to dominate the Internet and get on with it so we could just go back to coding and not wondering about the future.

Christian Graus wrote:I will always love C++, and I hope it remains relevant in the future, but I consider managed C++ to be a joke.

MC++ is not a joke, it is the best option for the C++ programmer in the .NET. If you can do it in C++, why worry about C#?

There is, however, an attempt to kill it and this is what I think Duncan is aiming at in a gentle manner. How can we have "visual" C++ but being forced to do form design manually and with the claim that it will be supported in VC++ 8, whose release date only God can tell?Will C# have being released without support for the form designer and the ASP.NET.

Compile the ff. (long time friend) with the /clr option and you have a .NET:

No, please take a close look at MC++. I am currently designing a new product line for my company (we build GIS components). My boss will not to completely .NET, but for customer who might require it we need to support them.

The only thing I have prayed for in MC++ is use of "delete", which should have being mapped to activate the gc.

C# and VB.NET require a double work to get my native codes to work, besides all must be either C functions or COM component. With MC++, which I am heavily investing in, I get the change to mix and use my C++ classes.

IMHO, MC++ may serve as a "glue" between native apps and .NET, but I don't think it is a first-class .NET language. For instance, in "real" C++ we use std::string, or char*, and with MC++, the preferred string class is System::String.

I think that MC++ should be considered a separate programming language than C++. Just like VB.NET and VB6 are de facto two different languages, although somewhat similar.

Well, I haven't jumped into the .NET thing yet, although it's obviously in my future. I'm just a little annoyed that I have to learn a new, more limited language to code for this environment. I learned C & C++ because I didn't like limitations. Managed C++, from all that I've heard, is not terribly attractive to develop in.

Of course, I learned C++ because I didn't want to be managed in the first place...

The good thing about MC++ is that you can mix both the managed and the unmanaged, which means you can do all the normal stuff in the managed and the .NET specific interfaces in managed.In fact, I am studying MC++. Simply marking your old C++ classes by __gc makes them managed and .NET ready.

There are many cool thing about MC++ and its power will not help the growth of the C# and MS will *delegate* it to the background, and hence the cold shoulder.

Christopher Duncan wrote:I suspect that as time goes on, VC++ will be used less and less for application development and more for rocket science under the hood when people truly need the power of a language that doesn't say "no".

IMO, MFC is still the best all around application development tool available. (I'm not saying it is great, I'm just saying in terms of full blown app design it is the best) Until VB/C#/Java evolve past the "Look mommy I created a form with a data bound control on it!" VC++ with MFC are going to dominate *real* app development. If those environments gave me a complete, grown up, application development tool set to use I would be happy to use them.