Is C++/CLI gaining any traction???

I can't help but agree. The unfortunate experiment with "Managed
Extensions for C++" is one more reason for the failure of C++/CLI.
Those of us who have invested time in learning MC++ and developed
applications and libraries with it will think twice before moving to
C++/CLI. Technically speaking, the new language is great - it simply
lacks the momentum.

Mar 3 '06 #7

Tim Roberts

Don Kim <in**@nospam.donkim.info> wrote:

I've been looking for a new IT position, and so far, the majority of
work with respect to the Windows platform is C#/.Net, with some vb.net
requests every so often. Even many of the C++/MFC/ATL position are ones
in which the companies are looking to migrate this to C# and .Net. I
have NOT even seen one position requesting C++/CLI, let alone any
recruiters who have even heard of it.
...
2) though, is what I think is nuts! Looks like some companies have
bought into the .net hype, and are under the notion that they need to
convert their native C++ apps completely to a C# one. Sadly, they don't
seem to know that they can use C++/CLI to extend and preserve their
existing native C++ code. C++/CLI is the perfect candidate for this
type of migration, yet no one seems to be aware of it!
I strongly question your assertion that C++/CLI allows someone to "preserve
their existing native C++ code". C++/CLI differs from C++ almost as much
as C# does.

Moving from C++ to C++/CLI requires you to mix new keywords and new
operators into a vaguely familiar language. The resulting mishmash of
familiar and unfamiliar is likely to cause errors just by itself. It makes
more sense to just invest the effort in learning C#, which has a large
collection of well-tested samples to draw from.
But I think C++/CLI may wither away, or comprise a very small niche. I
think the best thing to do is either stick with C#/.Net (or vb.net) if
your going to do Windows now and in the future, and for native C++,
either work as a maintence programmer if your on the Windows platform,
or move to a Unix/Linux environment where most of the new and cutting
edge stuff involving C++, as well as C is going on.

This is in interesting paragraph, from someone who three paragraphs ago
referred to buying "into the .NET hype". It sounds like you already
believe that all Windows programming from now on will be .NET.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

Mar 3 '06 #8

Igor Tandetnik

Tim Roberts <ti**@probo.com> wrote:

I strongly question your assertion that C++/CLI allows someone to
"preserve their existing native C++ code". C++/CLI differs from C++
almost as much as C# does.

The theory is that one can build a project that contains regular C++
sources freely mixed with C++/CLI sources, they can call into each
other, and it all just works with no interop tricks required. Thus one
can take legacy code and simply start using it in a managed program.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Mar 3 '06 #9

Don Kim

Igor Tandetnik wrote:

The theory is that one can build a project that contains regular C++
sources freely mixed with C++/CLI sources, they can call into each
other, and it all just works with no interop tricks required. Thus one
can take legacy code and simply start using it in a managed program.
Thank you, this is what I meant. Unfortunately, some of the companies I
interviewed with and others I have inquired from, seem to be unaware
of this feature of C++/CLI (let alone even know of its existence!) and
are seeking to REWRITE all their C++/Win32/MFC/ATL code to C#/.Net!
First of all, its nuts to rewrite working code just to keep up with some
trendy new framework, even as good as .Net is for certain class of
applications. But if your going to do so, might as well use the C++/CLI
extension that was expressedly created to allow such a migration path,
so you can save the time and wasted effort of re-writting code.

But therein lies my rant, in that it seems this feature and new language
extension has not been marketed well, or the first iteration of MC++ was
so bad, NO one wants to risk investing effort in it. I know I occupy
this position.

Its a pity, because it seem so much time and effort was put into
creating this extension, even going so far as submitting it to be an ISO
standard.

Tim Roberts wrote: This is in interesting paragraph, from someone who three paragraphs
ago referred to buying "into the .NET hype". It sounds like you
already believe that all Windows programming from now on will be
.NET.

No, I do not believe all windows programming will or should be .net.
Its just an observation I have of many IT companies that I have been
seeking work with, that THEY are under the impression that ALL windows
programming will/should be .net. Thus, my original rant that they are
1) crazy to re-write existing and working C++ code to C#, just because
of this fallocious belief, 2) unaware that there is a new and cleaner
language extension (if you notice, I refer to this as a language
extension, because for the most part I don't consider C++/CLI to be ISO
C++, but just an extension of it) to help with this migration if they
are so inclined, and 3) the reason for this was because of the
lackluster job of the first managed extension and continuous lackluster
job of marketing this feature.

Regards,

-Don Kim

Mar 3 '06 #10

William DePalo [MVP VC++]

"Don Kim" <in**@nospam.donkim.info> wrote in message
news:ev**************@TK2MSFTNGP15.phx.gbl...

Igor Tandetnik wrote:
But therein lies my rant, in that it seems this feature and new language
extension has not been marketed well, or the first iteration of MC++ was
so bad, NO one wants to risk investing effort in it. I know I occupy this
position.

It's important to quantify "bad".

MC++ was "bad" in my view because the code was so ugly with all its double
underscored keywords. (But then everyone has his own subjective esthetic
criteria for attractiveness.) With the exception of the "loader lock" issue
which was more of an issue in how the language and runtime interact than
anything else, the language was not "bad" in the sense that it was
unworkable.

I used it to good advantage so that a server application of mine can support
plug-ins written in managed languages. It rocks at that.

And I think that's where MC++ and C++/CLI shine. They make it easy to
interoperate between native and managed components.

Regards,
Will

Mar 4 '06 #11

John Carson

"Don Kim" <in**@nospam.donkim.info> wrote in message
news:ev**************@TK2MSFTNGP15.phx.gbl

Igor Tandetnik wrote:
The theory is that one can build a project that contains regular C++
sources freely mixed with C++/CLI sources, they can call into each
other, and it all just works with no interop tricks required. Thus
one can take legacy code and simply start using it in a managed
program.

Thank you, this is what I meant. Unfortunately, some of the
companies I interviewed with and others I have inquired from, seem
to be unaware of this feature of C++/CLI (let alone even know of its
existence!) and
are seeking to REWRITE all their C++/Win32/MFC/ATL code to C#/.Net!
First of all, its nuts to rewrite working code just to keep up with
some trendy new framework, even as good as .Net is for certain class
of applications. But if your going to do so, might as well use the
C++/CLI extension that was expressedly created to allow such a
migration path, so you can save the time and wasted effort of
re-writting code.
But therein lies my rant, in that it seems this feature and new
language extension has not been marketed well, or the first iteration
of MC++ was so bad, NO one wants to risk investing effort in it. I
know I occupy this position.
Its a pity, because it seem so much time and effort was put into
creating this extension, even going so far as submitting it to be an
ISO standard.

A lot of Microsoft initiatives don't work at the first attempt. Windows
itself never got real traction until version 3.0. If MS believes in
something and keeps working on it, it usually ends up a success. Present
indications are that there is a lot of support within MS for C++/CLI and it
has attracted some sympathy from the broader C++ community. Stroustrup's
most recent take on it is here:

http://public.research.att.com/~bs/bs_faq.html#CppCLI

That said, I think it is inevitable that in the future C# will be more
widely used for Windows programming than C++ or C++/CLI for the same reasons
that VB was so popular. C# is considered to be an easier language --- at
least for simple tasks --- in which you can get a lot of stuff done more
quickly. C++/CLI will tend to be popular for more demanding applications
written by programmers for whom language simplicity is not a priority.

--
John Carson

Mar 4 '06 #12

Stephen Howe wrote:

[...] Waste of time. I can see MS evangelists dancing,
writing whitepapers, articles, books all to herd managers
and programmers in companies to write new apps, rewrite
old apps as .NET applications.
And for what? They won't be any faster. Some will be a
lot slower.
There is nothing particularly wrong with Win32.
Given 10 years, MS will abandon it.
It is no more than the latest programmer fashion.
Any manager reading this - avoid it. Only consider if it
provides some easy functionality you need that is not
easy to code using Win32 APIs.

Why this fixation on speed? .NET was not invented to make
applications run faster. Who needs this speed anyway?
Overwhelming majority of desktop applications are fast
enough for any human user (unless scientists invented direct
connection between brain and computer). I don't need any
additional speed for my e-mail client or accounting
applicaton. However, I need additional interoperability,
modularity, ability to make extensions, ability to expose my
app to Web easily and other gazillion things that .NET
provides. To write all that in Win32 API is insane and
simply not realistic anymore. There are no Herb Sutters and
Stanley Lippmans enough out there to complete every
programming team with them.

..NET is not programming fashion. It is vital need of modern
software development. Applications are big and complex
nowadays. Time to market is shorter and more demanding. No
sane manager can afford himself the delusion that his
product can compete while using outdated technologies.
Almost any feature now is "some easy functionality you need
that is not easy to code using Win32 APIs". Can you imagine
today any decent desktop application without scriptability,
automation, possibility to make add-ons for it; without
highly customizable UI? Suppose, you have genius developers
and they managed to make it in Win32 API. Then what? How do
you think to convince your partners to make extensions for
your application? Where they should search for genuis
extension writers and support staff? Why they should invest
a lot of money to make additional training for existing
staff?

With .NET many of these questions are simply not exist.
That's why it is already (not in 10 years) .NET is primary
development platform for WIndows applications.

Mar 4 '06 #13

..NET is a preferred platform for *some* applications - roughly speaking
the same ones that were previously developed with tools such as Visual
Basic, Power Builder, Java and Delphi. There are many areas of software
development where .NET is not the best choice.

Anyway the point here is not whether or not to develop new applications
with .NET. If you have invested 10 years and millions of dollars into
building an application with, say, Win32 API - is there really a
business justification to rewrite it with .NET?

Mar 4 '06 #14

Tamas Demjen

Shawn B. wrote:

C++/CLI is much better... but I would have preferred if they left the syntax
alone. Instead of all this "ref" stuff and "^" pointers,
C++/CLI was designed to support mix-mode programming, where a
significant potion of your code is native C++, which you wrap and
interface to .NET. That being said, it would be extremely inconvenient
to use a * for a managed handle. That contributed to the failure of the
old MC++. How would you know that int* is an unmanaged or a managed
pointer? Yes, if you develop in entirely managed mode with completely
totally 0 line of unmanaged code, the new C++/CLI syntax may look like a
severe deviation from ISO C++. But knowing the significant paradigmatic
differences between native and managed software design, you can't reuse
existing C++ code unmodified anyway.
they should have just said
managed class MyClass

Or better yet

class MyClass : public System::Object

Yes, they could have created a language allowing us to use a single
source base to produce both native and managed output, without having to
use quirky syntax. However, that wouldn't have been anything but a
skin-deep solution, which wouldn't have solved any real-world problems.
Existing ISO C++ code creates objects on the stack, which you can't do
very well in .NET (except with limitations, and only in C++/CLI, not in
the other .NET languages). Anything but the most trivial code uses STL
containers, std::string, maybe even boost::shared_ptr. Those concepts
don't work well in .NET, at least not in a portable way. How would you
compile existing source code using std::string to managed code? Would
you substitute std::string with System::String? Of course you can
compile std::string to managed code as a value class, but you won't be
able to expose that interface to the public.

In reality, if you want to reuse existing C++ classes, you don't do that
by recompiling them to managed types, but by wrapping them, which leads
to the problem of mixing unmanaged and managed data in the same code.
It's a huge benefit that you can immediately differenciate between those
types just by looking at the code. Class^ is managed. Class* is native.
I think it was a good enough reason to introduce the new syntax.

Tom

Mar 4 '06 #15

Nemanja Trifunovic wrote:

.NET is a preferred platform for *some* applications -
roughly speaking the same ones that were previously
developed with tools such as Visual Basic, Power Builder,
Java and Delphi. There are many areas of software
development where .NET is not the best choice.
Of course, .NET is not an answer for all problems. There
will always be niches with specific needs. I'm talking about
mainstream development. Today mainstream steadily drifts
towards .NET/Java away from C/C++.
Anyway the point here is not whether or not to develop
new applications with .NET. If you have invested 10 years
and millions of dollars into building an application
with, say, Win32 API - is there really a business
justification to rewrite it with .NET?

It depends. At some point you will be forced to make some
modernizations, otherwise you will start to loose your
market share. To find the golden path between development
costs and competitiveness is the problem of every business.
Too many good application lost their markets because of
inability to adopt to changing environment.

The problem here that once complex feature you so cherished
(which costed you millions) can be easily implemented with
new technologies now. It gives significant competitive
advantage to your rivals. Now they need less developers to
implement the feature and those developers can be less
expensive than yours. Then competitor can concentrate on
more important things and make actually better product.

Currently, I can see that some big companies instead of
twisting old product's arms start to develop similar product
in parallel with new technologies.

Mar 5 '06 #16

> I'm talking about

mainstream development. Today mainstream steadily drifts
towards .NET/Java away from C/C++.
What do you mean by "mainstream development"? If it is in-house
business applications, they were developed mostly by languages like VB,
Java or Delphi (or COBOL is you go farther in the past). If you mean
web browsers, office aplications, image processing, multimedia,
games... I don't see .NET playing significant role in these areas ever.
The problem here that once complex feature you so cherished
(which costed you millions) can be easily implemented with
new technologies now.

Sometimes yes, but in general no. For instance, we have a machine
translation engine that has been developed since 1991 or so. I can
assure you there is absolutelly nothing in .NET that would help us
easily reimplement it. We would simply lose another 15 years to get the
same thing - only it woud be slower (and speed does matter in this
case) and spend more memory.

Mar 6 '06 #17

Don Kim

Alex Blekhman wrote:

I hope we will see something in near future. I can see that
job market requires C#/.NET much more frequently than C++.
All these coders are doing something, isn't it?

I don't know why discussions of programming languages and frameworks
always digress into which is better or more popular. *SIGH* Visual
Basic classic had far more programmers than Visual C++ ones, yet it does
not mean it was better (on the contrary, VB encouraged bad programming
habits, and was terrible at scaling above small applications).

Nevertheless, history seems to repeat itself, and this was the same kind
of thinking in the mid 90s when java hit the scene, and everyone
proclaimed c++ was obsolete. Well, foward 10 years and c++ seems as
strong as ever.

Consider though that C#/.Net seems to have been created because 1) it
was an answer to java and Sun's lawsuit; 2) VB was too easy and created
buggy, unscalable programs; and 3) C++ is hard and takes time to master,
and not everyone is inclined nor patient enough to use the language
properly. Thus, a mid level language was created that had the RAD
capabilities of VB, yet retained many of the system level capabilities
of C++. Great, from a business point of view, I can't blame MS for
doing this at all. Also, it raises the barrier to entry and promotes
better software engineering principles, since to use .Net effectively,
you have to really understand OO and compoent software design.

Again, and ad nauseum, 10 years from now .Net will be seen to not solve
everything (in fact, people already seem much smarter about this than
the java hype days, except for the younger programmers just out of
college weaned on java and thinking managed environments are superior to
everything else, and think all programs should be OO or worse,
shoehorned into design patterns because they took a class in OO/Design
Patterns and create these over elaborate OO hierachies, when a more
simple solution could have been created, yet they think they know it
all), and c++ will still run strong and solve what it is good at,
systems programming.

But again, and ad mauseum, ad nauseum... a good software developer will
carefully evaluate the problem at hand, and use the appropriate
programming language and framework, and much of this cannot be
determined solely on technical merits alone unfortunately, as the costs,
time to market, and skillset of the other developers will have to be
carefully evaluated and taken into consideration. That being said,
there are certain problems for which a language like c++ is best suited
for (sometimes the only solution), and it is incumbent on the developer
to know how to use it when necessary.

Besides, being this kind of developer will prevent you from having your
skillset become obsolete, and worse, become replaced by someone in
another country who can do the same work as you for a whole hell of a
lot cheaper. All this talk about how much easier it is to program in C#
and how fast you can create applications with it, is ironic, given that
this very same aspect of it, will make many millions of other programmer
in countries like India, China, and Eastern Europe adopt it and learn
it, and replace you.

This is not to say that C++ programmer will not get replaced either, but
the ones who know how to solve more complex problems, as well as have a
diverse skillset and knowledge base, have a much better chance of not
being replaced.

I've noticed the companies I interviewed with, are much more rigorous in
their hiring criteria and most positions are for senior level
developers, and I've noticed a surprising number of companies are asking
how you can handle many non-technical issues, such as being able and
willing to write technical specification documents, interact with
customers, and how well you can handle business concerns.

If all you can say is "C#/.Net is great and I know how to drag and drop
controls on a web/winform and wireup some bindings to an SQL database
and I have the MS certifications to prove it", you will either get the
most menial coding work and/or get replaced down the line by a coder in
Bangladore, or heck, someone in New Mexico because the company moved
their IT deptment there to save on rent and salary expenses.

Anyway, don't know how (or why it always does so) regress to a debate on
whether native or managed applications are better, but my original post
was not on whether the C++/CLI was good or bad on technical grounds (as
I actually think it is quite good), but more a slam on the lack of
marketing and promotion of it, in comparason to C#/VB.NET, especially
given all the work put into it. I do think, and if history is any
indicator of the tenaciousness of MS when the want companies to adobt
their technology (just look how good a job they did with .Net), that
they will with C++/CLI, its just that I'm getting impatient. C'mon lets
get moving!

Regards,

-Don Kim

Mar 6 '06 #18

Nemanja Trifunovic wrote:

I'm talking about
mainstream development. Today mainstream steadily drifts
towards .NET/Java away from C/C++.

What do you mean by "mainstream development"? If it is
in-house business applications, they were developed
mostly by languages like VB, Java or Delphi (or COBOL is
you go farther in the past). If you mean web browsers,
office aplications, image processing, multimedia,
games... I don't see .NET playing significant role in
these areas ever.

I mean applications like word processors, image editors,
CD/DVD burning software, etc.. Currently there is a lot of
legacy C/C++ code out there. But slowly it changes. Most of
applications average consumer uses don't have significant
technological breakthrough inside them. Majority of parts of
DVD burner, for example, are boilerplate GUI, which is glued
together; there's no reason to invest in Win32 API to
implement it nowadays.

The problem here that once complex feature you so
cherished (which costed you millions) can be easily
implemented with new technologies now.

Sometimes yes, but in general no. For instance, we have a
machine translation engine that has been developed since
1991 or so. I can assure you there is absolutelly nothing
in .NET that would help us easily reimplement it. We
would simply lose another 15 years to get the same thing
- only it woud be slower (and speed does matter in this
case) and spend more memory.

This is the case when porting to .NET is not justifiable.
However, I reckon your application is some CAD and/or
scientific software. Regular e-mail client or accounting
application does not require such engineering effort.

Mar 6 '06 #19

Herby

Im currently migrating our application from C/C++/MFC to C++\CLI. We
are experienced C\C++ programmers and it would seem the natural path.
I am also quite impressed with the IJW technology. I can easily
convert my MFC serialization to .NET serialization within the same
mixed mode method and its completely intuitive.
IJW is a sound technology. It is easy to compile a single module to
managed mode and begin to introduce .NET features into your old
application, the rest stays unchanged and unmanaged. Its this fact
that needs to be appreciated by the hardcore C/C++ development teams.
Here we have evolution and not revolution.

Anyway our specific problem now is, we need to employ a junior
programmer to do some of the more mundane time-consuming tasks, but the
C++ developers out there are all senior. So the problem is you cannot
fill junior positions with old technologies. They all want to use C#.

Mar 6 '06 #20

>Im currently migrating our application from C/C++/MFC to C++\CLI.

Why?

Dave

Mar 6 '06 #21

Herby

Good question

#1 They are paying me to do it :-)

#2 Its a calculator engine working with very sensitive data that is to
be made available on the web.
There is now a demand to run it in 'safe' mode. So its for
security reasons.

Although performance is also very important to us. This is hard to
gauge without actually having a .NET version to do some benchmarks.
But im not seeing anything unduly slow at the moment.

Another reason is using the MONO platform for UNIX it should easily
port to UNIX. so opening up new potential customers there.
After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

Mar 6 '06 #22

>#1 They are paying me to do it :-)

Always a very good reason :)

#2 Its a calculator engine working with very sensitive data that is to
be made available on the web.
There is now a demand to run it in 'safe' mode. So its for
security reasons.
OK, so you probably do have a reasonable technical argument for going
this way.
Another reason is using the MONO platform for UNIX it should easily
port to UNIX.
...
After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

Dave

Mar 6 '06 #23

Don Kim wrote:

Alex Blekhman wrote:
I hope we will see something in near future. I can see
that job market requires C#/.NET much more frequently
than C++. All these coders are doing something, isn't it?

I don't know why discussions of programming languages and
frameworks always digress into which is better or more
popular. *SIGH* Visual Basic classic had far more
programmers than Visual C++ ones, yet it does not mean it
was better (on the contrary, VB encouraged bad
programming habits, and was terrible at scaling above
small applications).

I'm sorry if I contributed a little bit of flame here. What
I'm trying to say is that besides technical reasons (which
are discussed most by developers) there are economical ones,
too. Quite often developers argue about merits of
language/technology and forget to consider economical
implications. Technologies like former VB and .NET/Java are
not there because of trendiness or fashion. Software
industry grows; it requires more developer, faster
development cycle and more complex software. At some point
it's impossible (or not worthwhile) to gain new qualities
with older/expensive tools.

Take as example textile industry. Hundreds years ago textile
was one of leading product of western world. Then industry
advanced and textile production became much cheaper. At the
same time it required more people, however their tasks were
much less advanced and required less training. At some day
it moved to Asia and Latin America; otherwise it wasn't
worthwhile. However, textile machines are still developed
and produced mostly in western countries.

The same process happens in software industry now. All
spadework goes to India, China and other countries where
coders are cheaper. However, as you already noticed, in
western countries, criteria for developers become more
demanding. This is natural process for any industry.
Software is not exception. Carefully handcrafted C++ code
can be as piece of art as finest French lace. However, there
are no skilled developers enough to make hand crafted C++
code for mass production. We can delude ourselves that C++
coders are "elite" while VB/.NET are "grunts" and all
"genuine quality" software should be developed by elite. The
industry needs more software and faster. It's not
economically viable to develop all of it with expensive
means.

Mar 6 '06 #24

> I mean applications like word processors, image editors,

CD/DVD burning software, etc.
Sorry, but I dissagree ;) There were good reasons these applications
were never written in VB or Java, and the same reasons hold today for
..NET
However, I reckon your application is some CAD and/or
scientific software. Regular e-mail client or accounting
application does not require such engineering effort.

Machine translation has nothing to do with CAD, it simply means
"automatic translation" or "computer translation" - try to google for
it if you are interested. As for e-mail clients, sure .NET would be
fine, except that there are so many existing e-mail clients already.
For accounting, I have seen the trend to move from general purpose
programming languages to specialized environments like Axapta or SAP.

Mar 6 '06 #25

Herby

>>The same process happens in software industry now. All

spadework goes to India, China and other countries where
coders are cheaper.

So is this the fate for all coding in the western world,
it is to be farmed out much cheaper to third world countries?
What are we to do?

Why do some companies take this route and others not?

I was recently talking to someone on the 'Essential C++\CLI" course
recently run in London of which there was only 10 people.
Anyhow, his company employ some indian programmers to maintain the old
MFC code, as they cannot get them cheap enough here.
But the indian programmers do not want to work on MFC either, they want
also to exclusively use the latest and greatest... The staff there keep
leaving and wage inflation is approx 15% pa.

Mar 6 '06 #26

> I mean applications like word processors, image editors,

CD/DVD burning software, etc..

Well, we will agree to dissagree on this :) I just don't see .NET
*ever* gaining any significant role in these areas.

Mar 6 '06 #27

Herby

>After all its is a VM, designed to compete with Java, ultimately they

must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

No not yet. Sounds good in theory though.

So is the VM part of .NET only virtual on top of Windows?

Mar 6 '06 #28

Tom Serface

Hi David,

I moved away from using VC6 for a couple of reasons probably #1 is my
"feeling" was that MSFT would stop supporting it. It still is what it is,
of course, so that doesn't change, but I'd like my resume to be more up to
data :o)

I've found that once I got used to the new interface in VS 7.1 and 8.0 I
actually like it better. I still miss ClassWizard, but I've learned to do
more things manually.

I don't really need great language conformance, I just need to create
Windows programs quickly that work. However, I am happy that there are
rocket scientists at MSFT making sure we are growing in that direction for
the inevevitable time when I will need something new.

The price seems to be creeping up as well, but since I live in this every
day it's easy enough, for me, to justify the cost. It's nice seeing the one
year moritorium on paying for the Express version.

Tom

"David Lowndes" <Da****@example.invalid> wrote in message
news:dv********************************@4ax.com...

Im currently migrating our application from C/C++/MFC to C++\CLI.

Why?

Dave

Mar 6 '06 #29

Carl Daniel [VC++ MVP]

Herby wrote:

After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

No not yet. Sounds good in theory though.

So is the VM part of .NET only virtual on top of Windows?

In theory, anyone can implement the CLI on whatever platform they choose
(witness Mono and dotGNU). In practice, there's quite a bit of the .NET
framework, including all C++/CLI support, that goes beyond what's in the
ECMA specs.

I'm not saying you won't ever see a CLI implementation on another platform
that supports C++/CLI - I believe you will eventually. But I strongly
suspect that it won't be this year. Or next.

-cd

Mar 6 '06 #30

Bo Persson

"Herby" <pr********@gmail.com> skrev i meddelandet
news:11**********************@i39g2000cwa.googlegr oups.com...

The same process happens in software industry now. All
spadework goes to India, China and other countries where
coders are cheaper.

So is this the fate for all coding in the western world,
it is to be farmed out much cheaper to third world countries?

Like t-shirts, and cheap PCs.
What are we to do?

We are to take care of the other jobs, that stay here.

The latest figures I saw, says that 2-3 percent of the IT jobs left
the US for India and China last year. This in an industry with a 5%
annual growth.

So, half of the *growth* leaves for Asia. The other half stays at
home. Try to get one of those jobs!
Bo Persson

Mar 6 '06 #31

>I moved away from using VC6 for a couple of reasons...

Hi Tom,

I don't know if I gave the impression that I've stuck with VC6 - I
haven't. I promote moving our C++ projects to VS2005 where I work -
something that seems to be happening since other people want to be
seen to have the latest tools on their CV :)

What we aren't doing is converting any existing projects to use
managed code. The only places we've used managed code are for a couple
of throwaway tests, and some MMCs that we've had to rewrite for
another company.

I've found that once I got used to the new interface in VS 7.1 and 8.0 I
actually like it better. I still miss ClassWizard, but I've learned to do
more things manually.

Same here. I find that the general improvements in the compiler & IDE
outweigh the losses from VC6. Hey, we've finally got a decent code
browser again with VS2005 :)

Dave

Mar 6 '06 #32

Herby wrote:

The same process happens in software industry now. All
spadework goes to India, China and other countries where
coders are cheaper.

So is this the fate for all coding in the western world,
it is to be farmed out much cheaper to third world
countries?
What are we to do?

Yes, I think boilerplate coding will extinct the same way as
production line manufacturing and assembling. Here's good
article about that:

"Outsourcing and Offshore Coders: Good or Evil?"
http://www.codeproject.com/gen/work/offshore.asp

Mar 6 '06 #33

Shawn B.

> previously developed with tools such as Visual Basic, Power

Builder, Java and Delphi.

You should hop over to the Delphi forums. They'll dissagree. There seems
to be a very strong adverse to .NET. Most can't see why anyone would want
to use it... mostly because of performance. But when they have Delphi and
Delphi.NET, they really don't like .NET. I suspect, there will be very few
Delphi converts to .NET.
Thanks,
Shawn

Mar 6 '06 #34

Tom Serface

Hi Dave,

"David Lowndes" <Da****@example.invalid> wrote in message
news:6u********************************@4ax.com...

I don't know if I gave the impression that I've stuck with VC6 - I
haven't. I promote moving our C++ projects to VS2005 where I work -
something that seems to be happening since other people want to be
seen to have the latest tools on their CV :)
Sorry, I wasn't reacting to anythiung you said specifically.
What we aren't doing is converting any existing projects to use
managed code. The only places we've used managed code are for a couple
of throwaway tests, and some MMCs that we've had to rewrite for
another company.
We're just getting started doing managed code. So far I like it, but native
code still performs better for my desktop applications so it's difficult to
push the paradigm for the kinds of things I do.
Same here. I find that the general improvements in the compiler & IDE
outweigh the losses from VC6. Hey, we've finally got a decent code
browser again with VS2005 :)

Yes! The only thing I don't like is the new help engine. Google is much
faster if you are online. I can start IE and do the Google before the help
engine finds anything and finally displays it's window. Local help is
nearly useless for me now.

Tom

Mar 6 '06 #35

>Yes! The only thing I don't like is the new help engine.

Agreed - that's indeed a step backwards IMHO. How do they keep
managing to make it worse? ;)

Dave

Mar 6 '06 #36

Stephen Howe

> Why this fixation on speed? .NET was not invented to make

applications run faster. Who needs this speed anyway?
My company does. We process vast volumes of data.
4 years worth of data amounts to several 100's of Gb's
Clients wait hours for reports.
We certatinly don't want a reduction in speed just because it is a .NET app.
There is no gain whatsoever rewriting as a .NET app
.NET is not programming fashion.
Oh yes it is. It is the latest fashion from Microsoft.
What difference is there between a C++ API based on objects and a .NET API?
None at all, AFAICT. Therefore it could just as easily be implemented as
part of Win32.
It is vital need of modern
software development. Applications are big and complex
nowadays. Time to market is shorter and more demanding. No
sane manager can afford himself the delusion that his
product can compete while using outdated technologies.
Almost any feature now is "some easy functionality you need
that is not easy to code using Win32 APIs". Can you imagine
today any decent desktop application without scriptability,
automation, possibility to make add-ons for it; without
highly customizable UI? Suppose, you have genius developers
and they managed to make it in Win32 API. Then what? How do
you think to convince your partners to make extensions for
your application? Where they should search for genuis
extension writers and support staff? Why they should invest
a lot of money to make additional training for existing
staff?
Well what do you think of ADO (no, not ADO.NET)?
It offers several simple objects all of which can be leveraged in terms of
doing most database functionality you could think of. They are all COM
objects. Now all you have said in the paragraph above applies to what is
offered in ADO. Yet it is not part of .NET.
With .NET many of these questions are simply not exist.
That's why it is already (not in 10 years) .NET is primary
development platform for WIndows applications.

It is not. 10 years from now Microsoft will be abandoning it for something
else which at that point in time you will say "is the future".

Stephen Howe

Mar 6 '06 #37

fernando.a.gomez.f

Hi Don,

I think that migrating C++ to C++/CLI is as "complicated" as migrating
it to C#. This is because:

1. You have to use NET services
2. Cannot mix well managed/unmanaged
3. You have to use (IMHO) weird syntaxis (gcnew, ^ instead of *, etc).
4. C++/CLI does not have any advantage over C# and vice versa.

Hence, if the app's being migrated, better use the "new trendy".

I think that's why.

Regards,
FG.

Mar 7 '06 #38

Stephen Howe wrote:

Why this fixation on speed? .NET was not invented to make
applications run faster. Who needs this speed anyway?

My company does. We process vast volumes of data.
4 years worth of data amounts to several 100's of Gb's
Clients wait hours for reports.
We certatinly don't want a reduction in speed just
because it is a .NET app.

There are different sectors in software market. Average
desktop application (which comprises lion's share of all
applications) does not process 100's of GB's of data. Also,
such application does not require high skilled developers.
Moreover, industry wants to make average desktop application
as cheap as possible and as fast as possible. That's why
some kind of managed infrastructure is inevitable for pure
economical reasons.

About 200 years ago the Luddites claimed the same thing: "we
don't need no stinky new machines!". They were highly
skilled, highly paid and worked primarily by hands. Workers
who used machines were uneducated, poorly trained and
underpaid. However, with machine's help one uneducated
worker could produce ten times more textile than whole team
before for the same period. The product was of slightly
lesser quality than before, however it is quantity and speed
that won, after all.

You can still find tailors who sew by hand and make a work
of art clothes. However, you know by yourself where the
money is now.

That's why it is already (not in 10 years) .NET is
primary development platform for WIndows applications.

It is not. 10 years from now Microsoft will be abandoning
it for something else which at that point in time you
will say "is the future".

10 years is a lot of time. If there is technology which will
last for 10 years, it's already worthwhile investing.

Mar 7 '06 #39

But the thing is: that was true in 1990's as well. For your "average"
desktop (and web, btw) applications, there were good RAD tools before
..NET appeared, and people were using them. C++ is a "general purpose
programming language with a bias towards systems programming" (quote B.
Stroustrup: http://public.research.att.com/~bs/C++.html) and not a
"Windows productivity language with a bias towards business
appliactions programming". There are applications that are best done
with such tools (.NET or others), and there are others where C or C++
are best fitted for.

All this talking about "obsolete" and "legacy" programming languages is
just buying the marketing hype. The oldest high level programming
language - FORTRAN is live and kicking in its niche, and so is COBOL,
not to mention C.

In short, please use .NET for your accounting application. If you ever
used C++ to develop such software, it is your fault, not C++'s. I work
on lower level stuff where tight control over memory and CPU
consumption is necessary, and I will continue using native C++ until I
find a better tool for the job. So far, I am not aware of such a tool.

Mar 7 '06 #40

Stephen Howe

> There are different sectors in software market.

I know that and your concerns are valid ones.
But they have been addressed some time ago.
Tools like Dephi, VB6 are RAD enviromnments and are suitable for rapid
development of Win32 applications.
Highly skilled developers are not required to use these.
They are very suitable for building dialog boxes etc, quickly.
For Visual C++, as good as the tools are, they have never been RAD.

In contrast .NET means a whole new learning curve of the Framework to
learn - nothing to do with RAD development at all, just MS's design for
..NET.

You can still find tailors who sew by hand and make a work
of art clothes. However, you know by yourself where the
money is now.

Yes. see above.

That's why it is already (not in 10 years) .NET is
primary development platform for WIndows applications.

That is not why. You are confusing RAD tools with .NET environment.
Why not use the RAD tools for Win32 environment?
That meets your productivity concerns _WITHOUT_ all this .NET baggage to
learn.

Stephen Howe

Mar 7 '06 #41

Tom Serface

Except if you already "know" C++ then you don't have to learn C# to do the
migration. I know that C# has a lot of cool tools that makes it compelling,
but the programming part isn't any easier (same libs, etc.). I hope the
C++/CLI platform gets the same level of tools in an upcoming release to make
it as interesting, but it is nice not having to learn another syntax just to
do the same things.

This is especially true for those of us who have to live in both worlds
(native and managed).

Tom

<fe****************@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

Hi Don,

I think that migrating C++ to C++/CLI is as "complicated" as migrating
it to C#. This is because:

1. You have to use NET services
2. Cannot mix well managed/unmanaged
3. You have to use (IMHO) weird syntaxis (gcnew, ^ instead of *, etc).
4. C++/CLI does not have any advantage over C# and vice versa.

Hence, if the app's being migrated, better use the "new trendy".

I think that's why.

Regards,
FG.

Mar 7 '06 #42

Shawn B.

> 4. C++/CLI does not have any advantage over C# and vice versa.

This mostly might be true. But, I wrote a CPU simulator in C# and wrote it
again in C++/CLI. Guess what? The C++/CLI binary was 12k (C# was 85K) and
while the C# version can execute something like 4.3 million "virtual" cycles
(emulate 4.3 MHz on a 2.2 GHz AMD 64-bit with 1GB RAM) the C++/CLI version
can execute 9.9 million "Virtual" cycles (9.9MHz)... though I think native
C++ can do better, and better yet, I wrote the same thing in win32 assembly
and it performed even better).

My point is that the C++/CLI produces better code than the C# compiler does,
obviously. Its not secret. The syntax is funky, but for my purposes, it
suits my well.

Another thing with C++/CLI, I recently rewrote the System.Console class to
include support for text-user-interfaces and had to do some serious interop.
I first did this in C# but kept having problems with translating the API's
and after 2 weeks something still wasn't working correctly and I couldn't
figure out what it was. I switched to C++/CLI and took me just a few
minutes to up and running (from scratch). They P/Invoke capabilities are
far superior in C++/CLI than they are in C#.

Some of my performance critical stuff I prefer to be inlined. I don't trust
the JIT to inline anything, when there's math involved (or a some
conditional statement or loop) it won't JIT most of the time (if it exceeds,
what they say, 32 bytes). C++/CLI is more likely to inline such code and,
at the very least, you can still use #define macros.

For the most part, these "little" things don't add up. I write business
applications all day (since mid-2001) in C#/ASP.NET and Windows Services/C#
among many other things. I won't give up C# in this environment for the
world, it performs really well. Much much better than VB6. But for certain
exotic things, clearly C++/CLI is the way to go even though you're main
performance limitation is the JIT and runtime. But that's an evil I'm
mostly willing to live with.

Thanks,
Shawn

Mar 7 '06 #43

Jerry Coffin

In article <#E**************@TK2MSFTNGP11.phx.gbl>,
tk*********@yahoo.com says...

[ ... ]

Moreover, industry wants to make average desktop application
as cheap as possible and as fast as possible. That's why
some kind of managed infrastructure is inevitable for pure
economical reasons.
Pardon my being blunt, but BULLSHIT! You're missing the
crucial link here: for this to be anywhere close to
correct, you need to show that a managed infrastructure
actually contributes to the ability to create desktop
applications more efficiently.

So far, that's just not the case. Even if it becomes
clear at some point that a managed framework really is
the way to go, that doesn't mean anything about the
quality of Microsoft's current tools to produce code to
run under their current framework.
About 200 years ago the Luddites claimed the same thing: "we
don't need no stinky new machines!". They were highly
skilled, highly paid and worked primarily by hands. Workers
who used machines were uneducated, poorly trained and
underpaid. However, with machine's help one uneducated
worker could produce ten times more textile than whole team
before for the same period. The product was of slightly
lesser quality than before, however it is quantity and speed
that won, after all.

I've pointed out repeatedly that VC++ 6 has better
productivity than the newer tools. You're replied by
pointing out that at least for some dialogs, the newer
environments have prettier, antialiased, fonts.

If we were to look at this in terms of more physical
tools, VC++ 6 is an ugly old radial arm saw (though it
does have laser guidance) -- and you're advocating
replacing it with a beautiful hand miter box because the
back saw has beautiful brass inlays!

Even your fellow advocate, Tom Serface, has admitted that
with the newer environment, "I've learned to do more
things manually."

To make a long story short, YOU are the Luddite here!

--
Later,
Jerry.

The universe is a figment of its own imagination.

Mar 7 '06 #44

Jerry Coffin

In article <#9**************@TK2MSFTNGP09.phx.gbl>,
tk*********@yahoo.com says...

[ ... ]

I'm sorry if I contributed a little bit of flame here. What
I'm trying to say is that besides technical reasons (which
are discussed most by developers) there are economical ones,
too. Quite often developers argue about merits of
language/technology and forget to consider economical
implications. Technologies like former VB and .NET/Java are
not there because of trendiness or fashion. Software
industry grows; it requires more developer, faster
development cycle and more complex software. At some point
it's impossible (or not worthwhile) to gain new qualities
with older/expensive tools.

You're starting from a fundamentally mistaken and false
premise: that it's more efficient and cheaper to produce
code with the newer tools.

Once you realize that's false, your entire argument
implodes.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Mar 7 '06 #45

Willy Denoyette [MVP]

"Shawn B." <le****@html.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
|> 4. C++/CLI does not have any advantage over C# and vice versa.
|
| This mostly might be true. But, I wrote a CPU simulator in C# and wrote
it
| again in C++/CLI. Guess what? The C++/CLI binary was 12k (C# was 85K)
and
| while the C# version can execute something like 4.3 million "virtual"
cycles
| (emulate 4.3 MHz on a 2.2 GHz AMD 64-bit with 1GB RAM) the C++/CLI version
| can execute 9.9 million "Virtual" cycles (9.9MHz)... though I think native
| C++ can do better, and better yet, I wrote the same thing in win32
assembly
| and it performed even better).
|

Well I have to disagree, others -
http://www.grimes.demon.co.uk/dotnet/man_unman.htm) and I have run numerous
benchmarks and the difference between both C# and C++ varies between + and -
5%, that means sometime C# produces 'better' code other times it's C++/CLI
which is a bit faster. But in general the differences are nill. After all
the C# team has been using the C# compiler since day one (they build the
framework library) so they are more expirenced in generating IL.

| My point is that the C++/CLI produces better code than the C# compiler
does,
| obviously. Its not secret. The syntax is funky, but for my purposes, it
| suits my well.

Any evidence to prove this claim? MSFT PM's have said many times before that
they won't care about optimizing IL, and have stated that over-optimizing IL
may disturb the JIT and produce worse results at the native code level,
really, the optimizer is the JIT compiler.
|
| Another thing with C++/CLI, I recently rewrote the System.Console class to
| include support for text-user-interfaces and had to do some serious
interop.
| I first did this in C# but kept having problems with translating the API's
| and after 2 weeks something still wasn't working correctly and I couldn't
| figure out what it was. I switched to C++/CLI and took me just a few
| minutes to up and running (from scratch). They P/Invoke capabilities are
| far superior in C++/CLI than they are in C#.
|

PInvoke is PInvoke,so, I guess you mean C++ interop. Well, whenever you
transition from managed to unmanaged, you take the same performance hit,
whether you use C++ interop (aka IJW) or PInvoke, more, the exact same code
is used inside the CLR, just write some small samples using both and single
step through the code when calling into unmanaged from managed, watch the
code path you'll see they are exactly the same, the reason is simple, there
is no difference at run-time, what's executed is native code and the CLR
doesn't have the slightest idea what tool was used to build the IL, all he
knows is that there is a transition from managed code into unmanaged and he
has to perform some tasks like signaling the GC that a thread leaves the
CLR, so he knows that he cant return when the GC runs. Other things like a
security walk must be done (can partly be suppressed), an unmanaged
exception frame must be created on the stack etc. The only difference is
that you have more control over the argument marshaling when using C++
interop (IJW ) which can give you some advantage if you really pay attention
to it, but for most of the data types there isn't that much to gain.
| Some of my performance critical stuff I prefer to be inlined. I don't
trust
| the JIT to inline anything, when there's math involved (or a some
| conditional statement or loop) it won't JIT most of the time (if it
exceeds,
| what they say, 32 bytes). C++/CLI is more likely to inline such code and,

You mean it won't inline do you? Well, the same is true for C++/CLI as it
generates IL just like all others managed compiler, the inlining is done by
the JIT compiler not by the IL.
Willy.

Mar 8 '06 #46