D
David Lowndes
Im currently migrating our application from C/C++/MFC to C++\CLI.
Why?
Dave
Why?
Dave
H
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 ?
#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 ?
D
David Lowndes
#1 They are paying me to do it
Always a very good reason
OK, so you probably do have a reasonable technical argument for going
this way.
Hmm, maybe. This is MS you're talking about. Have you tried this?
Dave
Always a very good reason
OK, so you probably do have a reasonable technical argument for going
this way.
Hmm, maybe. This is MS you're talking about. Have you tried this?
Dave
A
Alex Blekhman
Don said:
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.
N
Nemanja Trifunovic
I mean applications like word processors, image editors,
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
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.
Sorry, but I dissagree
There were good reasons these applicationswere never written in VB or Java, and the same reasons hold today for
..NET
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.
H
Herby
The same process happens in software industry now. All
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.
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.
N
Nemanja Trifunovic
I mean applications like word processors, image editors,
Well, we will agree to dissagree on this I just don't see .NET
*ever* gaining any significant role in these areas.
Well, we will agree to dissagree on this
I just don't see .NET*ever* gaining any significant role in these areas.
H
Herby
After all its is a VM, designed to compete with Java, ultimately they
No not yet. Sounds good in theory though.
So is the VM part of .NET only virtual on top of Windows?
No not yet. Sounds good in theory though.
So is the VM part of .NET only virtual on top of Windows?
T
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
)
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
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
)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
C
Carl Daniel [VC++ MVP]
Herby said:
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
B
Bo Persson
Herby said:
Like t-shirts, and cheap PCs.
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
D
David Lowndes
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.
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
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.
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
A
Alex Blekhman
Herby said:
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
S
Shawn B.
previously developed with tools such as Visual Basic, Power
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
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
T
Tom Serface
Hi Dave,
Sorry, I wasn't reacting to anythiung you said specifically.
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.
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
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.
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
D
David Lowndes
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
Agreed - that's indeed a step backwards IMHO. How do they keep
managing to make it worse?
Dave
S
Stephen Howe
Why this fixation on speed? .NET was not invented to make
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
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.
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.
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
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
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.
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.
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
F
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.
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.
A
Alex Blekhman
Stephen said:
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.
10 years is a lot of time. If there is technology which will
last for 10 years, it's already worthwhile investing.
N
Nemanja Trifunovic
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.
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.