Is C++/CLI gaining any traction???
Don Kim
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!
I can understand those companies looking to create new applications
looking to start with C#, since it is the new trendy language and one
made specifically for .net, but I would think those looking to migrate
their C++/Win32/MFC/ATL stuff, would be looking at the new and improved
C++/CLI to migrate those portions which make sense to integrate .net.
Instead, I've mostly seen the following types of positions with respect
to C++ on Windows:
1) New apps with C#/.Net requested, and some vb.net only
2) Port all native C++ apps to C#/.Net
3) Stick with native C++, with no .Net at all
Like I mentioned, I can understand 1) since if your going to create new
.Net stuff, might as well use the language built specifically for it.
3) I can understand, since if you have native stuff already that is
working well for you, and especially if its apps with performance and
portability in mind, there is no reason to go .net.
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 can only conclude a few things: 1) C++/CLI came too late. This should
have been the first language to come out, instead of the horrendous
managed C++. 2) Microsoft has done a lackluster job of marketing
C++/CLI. 3) My feeling is that the hardcore C++ programming shop could
care less about .Net, and furthermore, I think there is quite some
resistance about a .Net extended language of C++. Just read some of the
newsgroups like comp.lang.c++ or comp.lang.c++.moderated.
Its sad to see this, given all the investment put into C++/CLI, as well
as the fact that two of my favorite C++ authors, namely Stan Lippman and
Herb Sutter, put a lot of work into this, yet it seems the marketplace
is ignorant of, and maybe even resistent to it.
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.
-Don Kim
Ajay Kalra
I am in agreement with you regarding CLI/C#. I dont think CLI is
gaining any momentum. Even MC++ did not gain any momentum. It may have
been different had CLI been released when .Net as first released. But I
really doubt it.
But in my view, the main factor is that applications developed using
MFC/ATL/Win32 typically do not have any need to go managed. There is no
compelling reason to do so. It really does not buy you anything other
than possible headaches(more QA) and possibly performance issues. For a
existing commercial unmanaged application written in C++, its a major
step. In my view, C++ in managed land is kind of not natural. It was
hard to see Herb Sutter asking for input to modify C++ to its present
managed form(CLI) (that too in Redmond).
As far as C# vs CLI is concerned, C# wins mainly because of its
ease(compared to C++) and was marketed very well compared to CLI.
--------
Ajay Kalra
ajay...@yahoo.com
Shawn B.
> have been the first language to come out, instead of the horrendous
> managed C++. 2) Microsoft has done a lackluster job of marketing C++/CLI.
> 3) My feeling is that the hardcore C++ programming shop could care less
> about .Net, and furthermore, I think there is quite some resistance about
> a .Net extended language of C++. Just read some of the newsgroups like
> comp.lang.c++ or comp.lang.c++.moderated.
>
> Its sad to see this, given all the investment put into C++/CLI, as well as
> the fact that two of my favorite C++ authors, namely Stan Lippman and Herb
> Sutter, put a lot of work into this, yet it seems the marketplace is
> ignorant of, and maybe even resistent to it.
C++/CLI is much better... but I would have preferred if they left the syntax
alone. Instead of all this "ref" stuff and "^" pointers, they should have
just said
managed class MyClass
{
...
public:
void DoSomething(int *myInt) // * pass by reference
{
...
}
unmanaged int DoSomethingElse()'
{
}
}
and perhaps a few .NET specific things that aren't expressible in standard
C++... but for the most part, I think the C++/CLI syntax is "quircky" though
better than MC++.
I use C++/CLI (sometimes) instead of C# because (some of) the types of
project I create see significant performance increases when using the
C++/CLI compiler instead of C# because the C++/CLI compiler will optimize
code during compile time instead of leaving everything to the JIT'er as C#
does. This results in drastically better performance .NET applications for
the things I use C++/CLI for. Usually I use C#, though.
That said, I'm noticing C++/CLI making slow uptake also, but all things .NET
2.0 seem to be slow. Don't know why. Perhaps its because the "awe" factor
of the new 2.0 features wore off two years ago when they first starting
talking about it. Now its out and its no big deal. I predict the same for
.NET 3.0.
Thanks,
Shawn
Stephen Howe
> MFC/ATL/Win32 typically do not have any need to go managed.
Exactly. GC has been around for many decades. It is not new. MS gives the
impression they have created brand new technology - they have not.
It solves one set of problems and introduces others
There are some applications that might benefit, not all applications. Many
will be slower - by a lot.
To me, the whole of .NET is political. It is not an advance.
It is designed to take on and kill Java.
> There is no compelling reason to do so.
Exactly
>It really does not buy you anything other than possible headaches(more QA)
and possibly performance >issues.
Exactly. 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.
We have MFC7 apps and Win32 DLLs in our company. None of them need writing
as a .NET app.
No benefit whatsover.
> For a
> existing commercial unmanaged application written in C++, its a major
> step. In my view, C++ in managed land is kind of not natural. It was
> hard to see Herb Sutter asking for input to modify C++ to its present
> managed form(CLI) (that too in Redmond).
He has done a good job.
The first version of managed C++ was appalingly clunky.
The current version is much better.
Even so, I am not enam
> As far as C# vs CLI is concerned, C# wins mainly because of its
> ease(compared to C++) and was marketed very well compared to CLI.
Not sure about that.
Right now there are many dialects of the same syntactic langauge - C++,
C++/CLI, C#, Java, D
which take various positions on single/multiple inheritance,templates,
garbage collection.
I personally think that in the long run C# will lose. It is only .NET and
Windows.
C++ is available for multiple platform, it does not require graphics and
there are many bright people continually inputing into its development in
terms of a ISO standard.
Java will still be around but it has lost its way somewhat.
D is one to watch.
Stephen Howe
Igor Tandetnik
> C++/CLI is much better... but I would have preferred if they left the
> syntax alone. Instead of all this "ref" stuff and "^" pointers, they
> should have just said
>
> managed class MyClass
> {
> ...
> public:
> void DoSomething(int *myInt) // * pass by reference
There are good reasons to keep * and ^ separate, and for other C++/CLI
design decisions. See
http://www.gotw.ca/publications/C++CLIRationale.pdf
From the horse's mouth, so to speak.
--
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
Shawn B.
> design decisions. See
>
> http://www.gotw.ca/publications/C++CLIRationale.pdf
>
Yeah, I've heard many of them and still dissagree somewhat. I won't argue
why because its unimportant. What is important is that C++/CLI is much
better than unmanaged C++ and the MS C++/CLI compiler can (in some cases)
produce better code than C# equivelant code, only because of the
optimizations the C++ compiler does, though, that C# does not do. But with
future revisions of .NET and dev tools/languages, it'll get better.
Thanks,
Shawn
Nemanja Trifunovic
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.
Tim Roberts
>
>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
>...
>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.
Igor Tandetnik
> 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.
Don Kim
> 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
William DePalo [MVP VC++]
news:evHVtpvP...@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
John Carson
>> 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
Alex Blekhman
> [...] 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.
Nemanja Trifunovic
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?
Ian
> 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.
snip
> Can you imagine
> today any decent desktop application without scriptability,
> automation, possibility to make add-ons for it; without
> highly customizable UI?
snip
Hi Alex,
can you give me some examples of the above as I am struggling to come up
with compelling reasons to switch to VS2005 (from VS6 and mostly win32 c/c++
programming).
regards
Ian
Tamas Demjen
> 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
Mark Randall
news:ejn%23O87PG...@tk2msftngp13.phx.gbl...
> snip
> can you give me some examples of the above as I am struggling to come up
> with compelling reasons to switch to VS2005 (from VS6 and mostly win32
> c/c++ programming).
Because VC6 is non-standard-conformant trash and code created on it will
likely explode on VS2003 onwards because they pick up the errors correctly.
--
- Mark Randall
"We're Systems and Networks"
"It's our job to know"
David Wilkinson
Mark:
I have to say I disagree with your comment here. If you like VC6 and
write MFC applications, I do not think the move to VC8 is all that
compelling. VC6 is a stable product, with 6 service packs, and a nice
IDE for MFC work. We have yet to see a service pack for VC7 or 7.1. Yes,
the template support in VC6 is not what it might be, and the for loop
scope thing is annoying, but if your code was written in VC6, you have
learned to live with these things long ago.
[Actually, I have recently started using the
#define for if(false){} else for
trick in VC6. It works well. It even found a couple of errors missed by
VC7.1, because of the "soft-injection" default in VC7.1]
I do not have VC8, but I recently spent some time compiling my MFC code
in VC7.1. Yes, I found quite a few errors, but they were really errors
in VC6 too, and when I was done my code would compile cleanly in both
VC6 and VC7.1. If you download the Feb 2003 PSDK for VC6, you can even
fix the Win64 warnings, and still go back to VC6. So I am "VC7.1 ready"
and I don't think it would be hard to get "VC8 ready."
David Wilkinson
Andre Kaufmann
>
> I have to say I disagree with your comment here. If you like VC6 and
> write MFC applications, I do not think the move to VC8 is all that
> compelling. VC6 is a stable product, with 6 service packs, and a nice
Perhaps, it's a fast IDE, but I would miss the debugging features of VC
2005. E.g. STL debugging.
Also I would miss some boost libraries, which don't compile at all in VC6.
Andre
P.J. Plauger
news:uQ9UzoEQ...@TK2MSFTNGP14.phx.gbl...
> David Wilkinson wrote:
>>
>> I have to say I disagree with your comment here. If you like VC6 and
>> write MFC applications, I do not think the move to VC8 is all that
>> compelling. VC6 is a stable product, with 6 service packs, and a nice
>
> Perhaps, it's a fast IDE, but I would miss the debugging features of VC
> 2005. E.g. STL debugging.
That feature has been available in our upgrade library for V6 for
several years now.
> Also I would miss some boost libraries, which don't compile at all in VC6.
True enough. But we have managed to get a few of the boost components
in TR1 working under V6 (for our next release).
Having said all that, I agree that there are good reasons to move at
least to V7.1 for language completeness, and to V8 for the opportunity
to mix vanilla C++ code with C++/CLI and other .NET languages.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Alex Blekhman
> .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.
Alex Blekhman
> can you give me some examples of the above as I am
> struggling to come up with compelling reasons to switch
> to VS2005 (from VS6 and mostly win32 c/c++ programming).
The good example is VS2005 itself. I can't imagine how many
person-years it is necessary to invest to make similar
product with MFC/ATL, not to speak of plain Win32 API. When
you see all the stuff they put in, you understand that even
MS with all its resources wouldn't be able to undertake such
project without quite all-embracing infrastructure.
Alex Blekhman
Actually, on new LCD monitors VC6 IDE is quite unpleasant.
It uses raster fonts which is not anti-aliased. So, many GUI
elements are pixelized.
Igor Tandetnik
news:eXnYF6HQ...@TK2MSFTNGP10.phx.gbl
> Ian wrote:
>> can you give me some examples of the above as I am
>> struggling to come up with compelling reasons to switch
>> to VS2005 (from VS6 and mostly win32 c/c++ programming).
>
> The good example is VS2005 itself.
You might be unplesantly surprised to find out that VS2005 IDE is _not_
a managed WinForms application. It is built on a native engine - the
same one that MS Office uses. Scriptability and add-on API is expressed
in terms of COM interfaces, not managed interfaces. Add-ons written in
managed code are hosted via COM interop.
Try opening devenv.exe in ILDASM.
None of MS Office products are .NET applications. Neither is Internet
Explorer. I can't think of any large application written with WinForms,
by MS or otherwise.
Alex Blekhman
>>> can you give me some examples of the above as I am
>>> struggling to come up with compelling reasons to switch
>>> to VS2005 (from VS6 and mostly win32 c/c++ programming).
>>
>> The good example is VS2005 itself.
>
> You might be unplesantly surprised to find out that
> VS2005 IDE is _not_ a managed WinForms application. It is
> built on a native engine - the same one that MS Office
> uses. Scriptability and add-on API is expressed in terms
> of COM interfaces, not managed interfaces. Add-ons
> written in managed code are hosted via COM interop.
Ooops! :) Thanks for correction.
> None of MS Office products are .NET applications. Neither
> is Internet Explorer. I can't think of any large
> application written with WinForms, by MS or otherwise.
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?
Jerry Coffin
tkfx....@yahoo.com says...
[ ... ]
> Actually, on new LCD monitors VC6 IDE is quite unpleasant.
> It uses raster fonts which is not anti-aliased. So, many GUI
> elements are pixelized.
Hi Alex,
I'm not sure if you're on a personal vendetta against VC
6 or what, but you should at least make a minimal attempt
at being accurate -- and your post is anything but.
The fact is that VC 6 lets you choose the fonts it uses
-- you can use TrueType fonts for as much or as little as
you see fit. If you've chosen to use raster fonts, so be
it -- but they're certainly not inherent to the design of
the IDE.
I could just as accurately set VC 7.1 to use Castellar
MT, and then claim that: "VC 7.1 displays upper and lower
case identically, leading to many coding errors" or set
VC 8 to display black text on a black background, and
then claim: "VC 8 makes text completely unreadable."
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin
tkfx....@yahoo.com says...
> Ian wrote:
> > can you give me some examples of the above as I am
> > struggling to come up with compelling reasons to switch
> > to VS2005 (from VS6 and mostly win32 c/c++ programming).
>
> The good example is VS2005 itself. I can't imagine how many
> person-years it is necessary to invest to make similar
> product with MFC/ATL, not to speak of plain Win32 API.
First of all, I'm pretty sure it's really not written
in/with .NET at all. It all appears to be native code.
The real question would be how much worse it would be if
it had been developed with .NET. In fairness, my guess is
"not much" -- I don't think its problems stem from lousy
tools, but from lousy design.
> When
> you see all the stuff they put in, you understand that even
> MS with all its resources wouldn't be able to undertake such
> project without quite all-embracing infrastructure.
Unless it actually does use .NET, its having been written
seems to indicate rather the opposite of what you're
trying to claim.
IMO, frameworks tend to make more difference to smaller
projects than larger ones. In a big project, you tend to
develop some sort of framework for that project more or
less regardless of whether you started with one or not.
In a small project, having a substantial part of that
framework pre-written saves a lot of work, but as the
project grows, it's a diminishing percentage of the
whole.
Nemanja Trifunovic
>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.
Nemanja Trifunovic
> job market requires C#/.NET much more frequently than C++.
I have just run a search on Dice.com. The result:
C++: 7667 positions
C#: 4550 position.
Even more important, C++ positions seem much more interesting than C#
ones.
Don Kim
> 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
Alex Blekhman
>> Actually, on new LCD monitors VC6 IDE is quite
>> unpleasant. It uses raster fonts which is not
>> anti-aliased. So, many GUI elements are pixelized.
>
> Hi Alex,
>
> I'm not sure if you're on a personal vendetta against VC
> 6 or what, but you should at least make a minimal attempt
> at being accurate -- and your post is anything but.
>
> The fact is that VC 6 lets you choose the fonts it uses
> -- you can use TrueType fonts for as much or as little as
> you see fit. If you've chosen to use raster fonts, so be
> it -- but they're certainly not inherent to the design of
> the IDE.
>
> I could just as accurately set VC 7.1 to use Castellar
> MT, and then claim that: "VC 7.1 displays upper and lower
> case identically, leading to many coding errors" or set
> VC 8 to display black text on a black background, and
> then claim: "VC 8 makes text completely unreadable."
Yes, probably I have reached critical mass of aggravation
using VC6. It has its good sides, of course. For example,
MFC support is very good. Overall IDE is fast. The fonts I'm
speaking of are not inside windows. Problem is with fonts
used for dialogs and controls. Raymond Chen explained this
situation very well:
"What's the deal with the DS_SHELLFONT flag?"
http://blogs.msdn.com/oldnewthing/archive/2005/02/04/366987.aspx
Part of VC6 GUI correctly inherits system shell fonts.
However, Many dialogs get boring MS Sans Serif, which is not
antialiased. Both VC7.1 and VC8 are much better in that
respect.
Alex Blekhman
>> 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.
Alex Blekhman
Notice that considerable amount of C++ jobs has title like:
"C#, .NET, C++, Developer" or "C++/Java". I can't say
anything whether these jobs are more or less interesting.
Probably, some time ago people were saying that "C jobs" are
much more interesting than these modish "C++ jobs".
Herby
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#.
David Lowndes
Why?
Dave
Herby
#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 ?
David Lowndes
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
Alex Blekhman
> 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.
Nemanja Trifunovic
> 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.
Herby
>>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.
Nemanja Trifunovic
> 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.
Herby
>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?
Tom Serface
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" <Dav...@example.invalid> wrote in message
news:dv5o021vqk19a7qdp...@4ax.com...
Carl Daniel [VC++ MVP]
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
Bo Persson
"Herby" <prmar...@gmail.com> skrev i meddelandet
news:1141653912.3...@i39g2000cwa.googlegroups.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
David Lowndes
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
Alex Blekhman
>>> 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
Shawn B.
> 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
Tom Serface
"David Lowndes" <Dav...@example.invalid> wrote in message
news:6upo029r5st2q21if...@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
David Lowndes
Agreed - that's indeed a step backwards IMHO. How do they keep
managing to make it worse? ;)
Dave
Stephen Howe
> 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
Stephen Howe
> job market requires C#/.NET much more frequently than C++.
> All these coders are doing something, isn't it?
Doesn't that tell you something when major MS apps are not .NET apps?
Why write as a .NET app if it currently does all that is necessary in its
current non-.NET form?
Stephen Howe
fernando....@gmail.com
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.
Alex Blekhman
>> 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.
Nemanja Trifunovic
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.
Stephen Howe
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
Tom Serface
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
<fernando....@gmail.com> wrote in message
news:1141711950.4...@u72g2000cwu.googlegroups.com...
Shawn B.
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
Jerry Coffin
tkfx....@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.
Jerry Coffin
tkfx....@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.
![Willy Denoyette [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXfXiAXGhHYcXf-iOUYGXHMIHmtAw4w01ItpjRcuAnrUu-vVQ=s40-c)
Willy Denoyette [MVP]
"Shawn B." <lea...@html.com> wrote in message
news:%23k4at5g...@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.
Alex Blekhman
> You're starting from a fundamentally mistaken and false
> premise: that it's more efficient and cheaper to produce
> code with the newer tools.
Is it not? If you're talking about overall investments in IT
and software development in particular, then I will agree
with you: it constantly grows. However, today you get more
value for the same money than before. I see software
development somewhat akin to hardware: average PC always
costs about $1000, but its capability grows.
ajk
<tkfx....@yahoo.com> wrote:
>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.
and where the quality is...
Ajay Kalra
maker group to develop a new application. Guess what they end up using
for developing a brand new application(no legacy code): NOT .Net (I
think its C++). That said a lot about MSFT's own embrace to .Net.
---------
Ajay Kalra
ajay...@yahoo.com
Ajay Kalra
is significant investment in software developers doing the work. The
human cost and experience alone prohibits going blindly to new tools,
regardless of how productive one may perceive these are. There are
other significant costs: QA, training, transition, deployment etc. All
this is real. As opposed to Hardware upgrade for developers, which is
essentially meaningless. These two could not be further apart.
-------
Ajay Kalra
ajay...@yahoo.com
Ajay Kalra
Excellent. I had missed this discussion on Richard's site as well.
--------
Ajay Kalra
ajay...@yahoo.com
Carl Daniel [VC++ MVP]
> On the same note, Eric Gunnerson moved some time ago from C# to DVD
> maker group to develop a new application. Guess what they end up using
> for developing a brand new application(no legacy code): NOT .Net (I
> think its C++). That said a lot about MSFT's own embrace to .Net.
It says even more about the requirements placed on projects that use
extensive libraries of legacy code and need the broadest possible platform
support.
-cd
Ajay Kalra
http://blogs.msdn.com/ericgu/archive/2006/01/09/510833.aspx
Specifically:
<>
4: Is DVD Maker written in managed code?
A: No. Yes, it is ironic that I spent so much time on C# and then spent
a ton of time writing something in C++ code. Everybody on the team is a
believer in managed code, and we hope we'll be able to use it for
future projects.
8: Followup on question #4. Why didn't you use managed code?
A: I would have loved to use managed code for the UI part, which is
what I own. I won't go into the details, but suffice it to say that it
wasn't the team's decision.
</>
I was very amused by "it wasn't the team's decision". Here is the
justification, which I dont find as compelling:
<>
[Update: I've thought about what I can say about this. I don't know all
the details of the decision, but the reasons I know are related to
decoupling and reducing dependencies.
I should also note that shipping managed code in an OS is different
than shipping managed code elsewhere.]
</>
---------
Ajay Kalra
ajay...@yahoo.com
Shawn B.
> 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.
>
C++ 2005 and they make no secret that the compiler actually does do more
agressive inlining at compile time rather than leaving it to the JITer. It
also does whole application optimizations and profil guided optimizations.
All of which the C# compiler does not do at all. Do a google, there's
plenty of support; I'm not just pulling this out of my rear.
Further more, on my CPU emulator, when I converted it into C++/CLI and
turned on/off the inlining optimization options, the runtime performance of
the virtual CPU jumps drastically when inlining optimzations are turned on,
when off, they are more inline (no pun intended) with the performance
characteristics of C#. I'm not saying C++/CLI is better or worse than C#,
I'm simply saying on exceptionally performance needy projects I create (I've
only created two, everything else is in C#) the C++/CLI compiler make a
noticable difference in performance when I run the application. Clearly,
there is something in the C++ compiler that is doing something much smarter
than what the C# compiler does.
Thanks,
Shawn
Shawn B.
> 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.
Maybe so, but fighting this crap in C# for weeks and getting it right in
C++/CLI after only hours of trying, one can argue, performance gain or not,
there was certainly a productivity gain. Anyway, I was watching one of the
PDC05 videos on sitestream.com the other day and they were talking about
some of performance enhancements. They specifically mentioned that for
certain data types, such as int, long, byte, string, you know, the basics,
they interop transitioning has been greatly improved and optimized. I was
left with the distinct impression that 1) it wasn't optimized in previous
managed C++ compiler, and 2) it is more optimized than the P/Invoke in C#.
So, again, there possibly is a performance benefit whether significant or
not in the scheme of things, I don't know, but the point is they made some
improvements above and beyond what we had before.
Thanks,
Shawn
Don Kim
> On the same note, Eric Gunnerson moved some time ago from C# to DVD
> maker group to develop a new application. Guess what they end up using
> for developing a brand new application(no legacy code): NOT .Net (I
> think its C++). That said a lot about MSFT's own embrace to .Net.
Indeed. But as the famous phrase states, "if you forget the past, you
are doomed to repeat it". I can cleary recall during the java hype days
of the late 90s, when a company (I think it was Corel?) stupidly decided
to REWRITE (I emphasize this, because it was a complete line by line
rewrite) their office application to java. At least Winforms has some
decent performance, not to mention the hardware improvements since then,
but back then was when the gawd aweful AWT was the standard, and Swing
(which still sucked) was just comming in. If I recall, this literally
bankrupted the company.
I doubt (though you never know) that a company would give into hype in
such an all embracing and detrimental manner, but if you buy into some
new trend w/out careful evaluation of when such a trend will be useful,
some pretty bad outcome will happen. This goes for the developers as
well, who stake their career chasing after the hottest trends (SOAP
anyone? What happnened to all the hype about SOAP/web services?!),
instead of the fundamentals and broad knowledge.
-Don Kim
Willy Denoyette [MVP]
|> | 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.
| >
| There are many MS developers that discuss compiler optimizations in Visual
| C++ 2005 and they make no secret that the compiler actually does do more
| agressive inlining at compile time rather than leaving it to the JITer.
It
| also does whole application optimizations and profil guided optimizations.
Right, but they are talking about VC8 ISO/C++ not about C++/CLI, we are
talking about C++/CLI don't we?
All this is NOT applicable to managed code! Inlining is done at the "native"
code level, how would you do this at the IL level?.
Note also thet inlining is very restricted in .NET, only small pieces of
code are inlined, that is the method must be < 32 bytes of IL byte code,
must not have guarded block (try/catch/finally), cannot have complicated
constructs like loops, cannot call into unmanaged code etc...
| All of which the C# compiler does not do at all. Do a google, there's
| plenty of support; I'm not just pulling this out of my rear.
|
No but you are talking about something alse.
| Further more, on my CPU emulator, when I converted it into C++/CLI and
| turned on/off the inlining optimization options, the runtime performance
of
| the virtual CPU jumps drastically when inlining optimzations are turned
on,
| when off, they are more inline (no pun intended) with the performance
| characteristics of C#. I'm not saying C++/CLI is better or worse than C#,
| I'm simply saying on exceptionally performance needy projects I create
(I've
| only created two, everything else is in C#) the C++/CLI compiler make a
| noticable difference in performance when I run the application. Clearly,
| there is something in the C++ compiler that is doing something much
smarter
| than what the C# compiler does.
I've run hundreds of benchmarks comparing both C#, C++/CLI, differences
obtained between different runs of the benchmarks are neglectable.
And the reason is simple, IL is translated into native code, and the IL
level there is little or nothing to optimize without the risk to produce
unverifiable code. I remember Ronald Laeremans (PM VS C++ team) said this:
"we are focusing on the JIT to perform optimizations" some time ago, not on
the IL level", that's why the C++ back-end compiler team owns the JIT
compiler.
Believe me, both C# and C++/CLI look more like a one-egg twin at run-time.
Willy.
Willy Denoyette [MVP]
Well, you need to take care about marshaling yourself, and oh... don't
forget to pin and un-pin when passing managed types to unmanaged, this is
something you don't have to care about when using PInvoke (in C# or C++).
Note also that the interop performance in managed C++ (ME C++) was bad (and
worse than C# PInvoke), this has greatly improved in C++/CLI, where it's now
on par with C# or C++ PInvoke interop. The reason for this is that they have
unified the interop path in V2 of the framework, both C# or C++/CLI go from
managed to unmanaged using the same CLR generated thunk(s), It just needs a
small piece of code and a native code debugger to watch this.
Note that, here I'm comparing C# PInvoke to IJW. IJW is mixed mode interop,
that means that the caller (managed) and callee (unmanaged) are in the same
assembly.
However, when calling from managed into a unmanaged accross DLL boundaries ,
the performance of C# PInvoke is better than the C++ interop, the reason for
this is that C++ interop calls GetLastWin32Error after each call, this
behavior cannot be switched off, while in PInvoke interop you can set a flag
(SetLastErrorCode=false) to turn this off.
Willy.
Ajay Kalra
>of the late 90s, when a company (I think it was Corel?) stupidly decided
>to REWRITE (I emphasize this, because it was a complete line by line
>rewrite) their office application to java.
I do recall this. It made the business news and boosted Sun's stock.
> I doubt (though you never know) that a company would give into hype in
> such an all embracing and detrimental manner,
I agree but I think its developers who fall for the hype before the
company does.
I recall in one of the summits at Redmond, BillG was asked about why
not making a product which used VB. He had no answer. It was followed
by why not use .Net to make a product. Again he had no answer but he
promised to make sure that would happen. That was ~3 years ago. It
appears .Net to MSFT is same as VB was at least for desktop
applications. I think .Net makes a whole lot of sense for web
applications than desktop. For desktop, it makes sense if you are
writing a new application. Microsoft had earlier suggested that .Net
will now be the only way they will release new API. That was a threat
so that you should move to .Net. That was 3-4 years ago. They have
retreated from it as they found .Net wasnt being adopted as they
expected.
I used .Net (C#) for about a year few months ago. After initial
hesitation, I thought it was very productive. I was actually happy that
I wasnt using C++. No header files, no macros, no STL, no templates,
excellent type safety etc. The transition was difficult, especially
from MFC(very different mindset) but when it finally hit me, I thought
it was good. In my new job, we will migrate from unmanaged(C++) to
managed some time soon and we are still figuring out the performance
issues. Initial research has indicated that performance hit isnt there
(Its a big multi-threaded financial application; eg trading stocks
etc). We will see.
------
Ajay Kalra
ajay...@yahoo.com
Jerry Coffin
tkfx....@yahoo.com says...
> Jerry Coffin wrote:
> > You're starting from a fundamentally mistaken and false
> > premise: that it's more efficient and cheaper to produce
> > code with the newer tools.
>
> Is it not?
That's correct -- they're less efficient, so they're more
expensive to use.
> If you're talking about overall investments in IT
> and software development in particular, then I will agree
> with you: it constantly grows. However, today you get more
> value for the same money than before. I see software
> development somewhat akin to hardware: average PC always
> costs about $1000, but its capability grows.
I'm talking about the fact that there are simply a lot of
things that ClassWizard made quick and simple that the
newer tools require the user to do by hand so they take
more time and effort.
I'm not talking about investments in software up front --
I'm talking about the ongoing cost of the development
itself. It's slower and clumsier, so it's more expensive.
A hardware upgrade is a one-time cost, so you can
amortize it over its life. When you look at things in
terms of amortized cost vs. productivity, it's easy to
figure out whether a particular upgrade makes sense.
The problem is that in this case, we're talking about the
equivalent of taking your 3.4 GHz P4 that you paid $1500
for, and trying to justify replacing it with a 266 MHz P2
that costs $10,000 instead.
In this case, the cost of the tools and/or hardware to
run them on is almost irrelevant -- what's relevant is
that the tools get in the way of getting the job done,
and there's no amount of hardware upgrade that makes up
for the fact that I have to do 20 minutes of hand editing
instead of clicking one button one time to get the job
done.
Shawn B.
> will now be the only way they will release new API. That was a threat
> so that you should move to .Net. That was 3-4 years ago. They have
> retreated from it as they found .Net wasnt being adopted as they
> expected.
Lets be corrected on this. They haven't retreated from anything. New API's
are primarily in .NET and available to unmanged code by using mixed mode
programming in C++/CLI as they recomment. WSE2 is a .NET API. Windows
Presentation Foundation (Avalon) is a .NET API. In fact, after looking at
the upcoming stuff on Microsoft's website, I can see, they are pretty vocal
about the new API's being .NET first.
I don't know whether .NET is the future or not. I know I get paid very well
to be a .NET developer since 2001. Its what I know. There are plenty of
job oppurtunities for .NET developers in general. Its thriving. Lots of
businesses are using .NET. There are reasons why not to. But companies
like Microsoft cannot simply just rewrite Windows and Office or Exchange and
SQL Server in .NET. They have a legacy code base to maintain that is
well-invested. I suspect Office may eventually go .NET but not by way of
rewrite. IJW is probly going to be the leveraging tool in this case. They
are going out of their way to integrate .NET into Office and SQL Server.
They must believe in it. If they can't completely rewrite, at least they're
providing hooks for .NET integration.
I think new API's should be native but I can understand why they'd want it
to be .NET. While new functionality can be added to Windows Next and
consumed by .NET on that platform, it would be too much effort to backport
the new Windows functionality to earlier versions of still supported OS's.
With .NET, they can take advantage of the native platform feature internally
on the Windows that supports it, and emulate the feature for those that
don't. Makes sense to me why they would make new API's a .NET API.
However, shrinkwrap software may not be going .NET in droves, but internal
development is increasingly using .NET. I think as our knowledge improves
of the platform so will also the projects using that knowledge follow.
Thanks,
Shawn
Shawn B.
> obtained between different runs of the benchmarks are neglectable.
I've created a real application in both C# and the same in C++/CLI and the
difference was staggering (a CPU emulator for an Apple2 emulator targeting
.NET -- not a business application or service). It was identicle code, not
different in architecture or design. So there we are. So your benchmarks
don't reveal any real benefits, but my real application that I'm doing
something with and have vested over a year in building, actually shows
interesting results. You written a CPU emulator? In my design, there are
hundreds of functions that emulate a CPU instruction. These functions get
called 9 million times per second on an unthrottled emulation (using
C++/CLI). Using C#, and almost identical translation of the code, comipled
in C#, gives me 4 million iterations per socond. Big difference. Clearly,
the C++/CLI compiler is doing something that the C# compiler is not.
Anyway, I refer you to the April 2005 edition of MSDN magazine where Stephen
Toub discusses some of the improvements in the Visual C++ 2005 compiler
http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/ .
I quote an important paragraph (the last paragraph in the optimizations
section):
---------
In an important change for developers using .NET, the Visual C++ 2005
optimizer performs most of the same optimizations when targeting MSIL as it
does when targeting the native platform, though it does so with different
tuning. While the just-in-time (JIT) compiler today analyzes for
optimizations at run time, allowing the C++ compiler to optimize during the
initial compilation can still provide significant performance benefits (the
C++ compiler has much more time to perform its analysis than does the JIT).
The Visual C++ 2005 compiler optimizes managed types for the first time,
performing loop optimizations, expression optimizations, and inlining. There
are places, though, where the compiler can't optimize .NET-based code. For
example, it has problems with strength reduction due to the unverifiability
of pointer arithmetic, and certain code can't be inlined due to the strict
type and member accessibility requirements of the CLR, though it does do
significant analysis for legal inlining opportunities. In addition,
optimizing MSIL introduces the need to make trade-offs concerning what is
presented to the JIT compiler. For example, you wouldn't want to unroll a
loop and expose a plethora of variables to the JIT compiler, whereupon it
would have to perform register allocation (an NP-complete problem). The
Visual C++ team is working through these issues and will have a very
well-tuned optimizing solution by the time the system is released.
--------
This directly contradicts what you've been saying.
Thanks,
Shawn
Ajay Kalra
growth. Look at Richard's analysis here:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
You will note that MSFT has in fact removed number of services that
depend upon .Net in newer version of Vista. .Net is now relatively
matured and you would expect MSFT to be sort of the leader in accepting
it. IMO, that has not been the case.
My expertise is MFC and I typically post in that newsgroup. I am
surprised that number of people posting there have actually gone up
recently. May not be big deal but it appears some of newer
developers/products are actually going unmanaged.
-------
Ajay Kalra
ajay...@yahoo.com
Shawn B.
> growth. Look at Richard's analysis here:
>
> http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
>
> You will note that MSFT has in fact removed number of services that
> depend upon .Net in newer version of Vista. .Net is now relatively
> matured and you would expect MSFT to be sort of the leader in accepting
> it. IMO, that has not been the case.
>
those make up 95% of his references. Second, read the Microsoft website
today and you will see that many of the new .NET API's will be managed only.
Don't believe me? Don't care. But at least take the time to read MS's own
(current) information. I did just last week because this same exact topic
keeps coming up other places and many people read what others have to say
(ala Richard Grimes during PDC03 -- 2 years ago) but I prefer to see what MS
currently says, since they are always changing their mind. Their current
state of mind is that new WinFX API's will be managed. Until they change
this information on the WinFS homepage I'll continue to believe it.
Thanks,
Shawn
Shawn B.
> growth. Look at Richard's analysis here:
>
> http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
>
> You will note that MSFT has in fact removed number of services that
> depend upon .Net in newer version of Vista. .Net is now relatively
> matured and you would expect MSFT to be sort of the leader in accepting
> it. IMO, that has not been the case.
Okay, after re-reading it. I don't know. Everyone takes one aspect of a
situation and doomday-speaks it. I don't believe MS is having problems
believing in .NET. Just read every single microsoft programmers blog and it
seems every employee has nothing but passion and faith for .NET. There
could well be far too many other issues involved than just whether something
is .NET or not. That's just an aspect and I don't believe it is
representative.
However, on their current WinFS homepage, they are pretty clear that the
newer API's will be .NET based. Not just there, but all over the Microsoft
developer blogs they are constantly talking about it. I think they released
they need to increment their way to change rather than do it all at once. I
agree. That's why Office hasn't been completely rewritten.
Anyway, Delphi programmers and C++ programmer have a major hesitation to
migrate to .NET and their arguments are two-fold: 1) .NET doesn't perform as
well as native code and 2) Microsoft hasn't rewritten any of their
applications to use .NET so they must not believe in it. I don't think
either of which are good enough reasons to avoid it. .NET performs very
well for our high-volume applications that get millions of transactions per
day. And while they haven't rewritten any of their major revenue-generating
products in .NET (why should they, they've millions invested in bug fixes
stability and enhancements already) it doesn't mean we shouldn't. Like I
said, shrinkwrap software may not be written in .NET but many internal and
server-type applications are already being done in .NET or will be soon.
Some people just want excuses and will use any they can to support their
bias. Me? I think .NET is quite capable of supporting about 90% of all the
applications that would need to be created... for numerical-heavy crunching
use a better tool, FORTRAN or C++, for everything else, C# is sufficient.
CPU clock-cycle performance isn't a necessary argument when the applications
spends 98% of its time waiting for the user to click or type, or when the
bottle neck is the network/sql server load combo.
Thanks,
Shawn
Jerry Coffin
lea...@html.com says...
[ ... ]
> Anyway, Delphi programmers and C++ programmer have a major hesitation to
> migrate to .NET and their arguments are two-fold: 1) .NET doesn't perform as
> well as native code and 2) Microsoft hasn't rewritten any of their
> applications to use .NET so they must not believe in it. I don't think
> either of which are good enough reasons to avoid it.
That depends. Just for a quick example, I recently did a
quick test re-compiling some code to run as C++/CLI. This
particular piece of code just does number crunching on
some big matrices, so it didn't take much to make it
compile.
The result is basically disastrous. In C++, the code is
slow enough to be mildly annoying. The number crunching
normally takes anywhere from a few seconds up to around
15 or 20 minutes. Much more than that, and you run out of
memory (at least on a 32-bit OS).
Under the CLR, a fairly small dataset that takes a couple
of minutes to process with native code ran for a couple
of hours before I gave up and killed it -- I have no idea
how long it would have taken to actually finish. Just for
run, I once converted (an older version of) the code to
Java, and while the performance dropped, it wasn't nearly
this bad -- performance dropped by something like 7:1 or
so, but this was more like 30:1 (and maybe worse).
> .NET performs very
> well for our high-volume applications that get millions of transactions per
> day.
The minute somebody starts talking about transactions per
day, it's virtually a certainty that you're dealing with
an I/O bound application. Talking about language
performance in I/O bound applications is basically
meaningless.
> Some people just want excuses and will use any they can to support their
> bias. Me? I think .NET is quite capable of supporting about 90% of all the
> applications that would need to be created... for numerical-heavy crunching
> use a better tool, FORTRAN or C++, for everything else, C# is sufficient.
> CPU clock-cycle performance isn't a necessary argument when the applications
> spends 98% of its time waiting for the user to click or type, or when the
> bottle neck is the network/sql server load combo.
So, basically, your argument is that C# can provide good
enough performance, at least for situations where
performance just doesn't matter (at all).
I'm always left with a question though: given that C++ is
already known, and even according to the C# advocates
provides substantially superior performance, what real
advantage does C# provide to make up for its obvious
shortcomings?
MS's tools have deteriorated so development (at least for
desktop apps) is clearly slower and clumsier. All of the
.NET stuff strikes me as being a lot like the VB used to
be, where everything tried to be forms based, whether it
made any sense or not, so at least without a lot of extra
work, everything ends up looking cookie-cutter generic.
The runtime performance isn't exactly something you can
get excited about.
I'm may be a little to young (and the wrong gender) to
play the part to perfection, but "Where's the meat?"
Tom Serface
Most of this is hearsay, but from what I understand they actually went back
to Longhorn and removed a lot of the .NET they were trying to use because
they were having performance problems. So, from what I understand much of
Vista, and Office 12 for that matter, is still unmanaged code. I believe in
the effort to make software more trustworthy, but it seems that we are all
not so eager to do it at the cost of performance or size. I think that
curve may change over time.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1141852068.2...@i40g2000cwc.googlegroups.com...
Edward Diener
>
> I can only conclude a few things: 1) C++/CLI came too late. This should
> have been the first language to come out, instead of the horrendous
> managed C++.
Microsoft destroyed Managed C++ with the DLL Initialization bug. It just
happened to occur ( hardy har har ) and give C# and VB .NET a four year
head start in .NET programming. Given that head start, what do you
suppose would happen to companies when it came to moving their C++ apps
to .NET ? And please do not tell me that MS did not have a strong
interest in promoting C# over C++.
Tim Roberts
>
>I do not agree with you on MSFT's own confidence in organic .Net
>growth. Look at Richard's analysis here:
>
>http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
>
>You will note that MSFT has in fact removed number of services that
>depend upon .Net in newer version of Vista. .Net is now relatively
>matured and you would expect MSFT to be sort of the leader in accepting
>it. IMO, that has not been the case.
On the other hand, the Media Center app in Windows Media Center Edition is
all written in .NET. It's not my favorite Microsoft application, but it is
evidence that a .NET front-end with a clever back-end can do some pretty
neat things.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
David Lowndes
>all written in .NET. It's not my favorite Microsoft application, but it is
>evidence that a .NET front-end with a clever back-end can do some pretty
>neat things.
And be just as buggy as any other program ;)
Dave
Edward Diener
> Don Kim wrote:
>
>>
>> I can only conclude a few things: 1) C++/CLI came too late. This
>> should have been the first language to come out, instead of the
>> horrendous managed C++.
>
> Microsoft destroyed Managed C++ with the DLL Initialization bug.
I should have said the Loader Lock bug, as that is its more popular name.
Willy Denoyette [MVP]
"Shawn B." <lea...@html.com> wrote in message
news:eNG7IDvQ...@TK2MSFTNGP12.phx.gbl...
|> I've run hundreds of benchmarks comparing both C#, C++/CLI, differences
| > obtained between different runs of the benchmarks are neglectable.
|
| I've created a real application in both C# and the same in C++/CLI and the
| difference was staggering (a CPU emulator for an Apple2 emulator targeting
| .NET -- not a business application or service). It was identicle code,
not
| different in architecture or design. So there we are. So your benchmarks
| don't reveal any real benefits, but my real application that I'm doing
| something with and have vested over a year in building, actually shows
| interesting results. You written a CPU emulator? In my design, there are
| hundreds of functions that emulate a CPU instruction. These functions get
| called 9 million times per second on an unthrottled emulation (using
| C++/CLI). Using C#, and almost identical translation of the code,
comipled
| in C#, gives me 4 million iterations per socond. Big difference.
Clearly,
| the C++/CLI compiler is doing something that the C# compiler is not.
|
You keep refering to the one and only application, and based on that you
claim that C++/CLI is much faster than C# (twice as fast!) while this
http://www.grimes.demon.co.uk/dotnet/man_unman.htm proves it's not the case,
but I guess this isn't of any value for you.
I can't comment on what you have done without seeing any code, you might be
calling into native code or using unsafe constructs (bypassing security
walks) which is what IJW does, while in C# this isn't true by default. If
you want to compare both you need to turn of Securty checks in C# as well,
or you need to compile your stuff using /clr:safe , if this isn't possible
because the compiler complains about mixed mode stuff, then we are not
talking about the same thing really.
I have run several benchmarks (hundreds), just like many others, and all I
can say is that the differences are minimal, sometimes C# wins and sometime
C++/CLI wins, sometimes C# produces better IL sometimes C++ does, but the
differences at run-time are minimal (+- 5%), that's all. Do you think that
the C# team isn't able to emit the same optimized IL as the C++/CLI
front-end, do you really believe both teams are competitors? Would they
build the Framework (and Most of WinFX(WPF and WCF..) using C# if C++/CLI
was that better performing?
| Anyway, I refer you to the April 2005 edition of MSDN magazine where
Stephen
| Toub discusses some of the improvements in the Visual C++ 2005 compiler
| http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/ .
|
This guy is a Technical Editor for MSDN Magazine, his job is to 'spread the
message' and promote MSFT products, and he did a great job. But sorry, I
don't believe everything I read, especially when it's possible to verify
what there is written.
Realy? Are you basing your findings on a piece written by a technical
editor, not a member of the C++ team, before the product was even released?
(note the final sentence - well-tuned optimizing solution by the time the
system is released), more, that same article mixes C++/ISO and C++/CLI
stuff, like you did when you talked about PGO which is a native code thingy
( and btw. not very valuable either).
Other sources at MSFT, (contradicting the story in MSDN Magazine), have
clearly stated that the front end of C++/CLI which simply emits IL isn't a
target for agressive optimization which may hurt the correct functioning of
the JIT compiler. And the front end doesn't do any inlining at all, why?
well he can't, if you know what inlining is all about you will understand
why it's not possible at that level in a managed world, you can't inline IL,
point. Note that the article doesn't mention any figures reflecting the
advantages because of the optimizations included in the product, you know
why?
Willy.
Willy Denoyette [MVP]
| >I do not agree with you on MSFT's own confidence in organic .Net
| > growth. Look at Richard's analysis here:
| >
| > http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm
| >
| > You will note that MSFT has in fact removed number of services that
| > depend upon .Net in newer version of Vista. .Net is now relatively
| > matured and you would expect MSFT to be sort of the leader in accepting
| > it. IMO, that has not been the case.
| >
| This Grimes article refers to information at was current during PDC03, as
| those make up 95% of his references.
Not true, read the article, his findings reflect several builds including
the latest CTP Feb 2006 build 5308.
What Richard is trying to say is that NetFX is just a managed API in top of
unmanaged code, nothing more. He did expect Vista to contain more managed
code at the core, which is not the case, actually Vista does not contain any
managed applications, you can even run Vista without the framework
installed. All there is are some administrative applications (the event
viewer, and the performance monitor) that are build using WinFX WPF. But
that's only a facade, the underlying code is still managed (and n case of
perfmon, it's still the sme COM server code as on XP). All other stuff is
unmanaged, not using the framework at all and that's what Richard is ranting
about.
Willy.
Shawn B.
> Realy? Are you basing your findings on a piece written by a technical
> editor, not a member of the C++ team, before the product was even
> released?
> (note the final sentence - well-tuned optimizing solution by the time the
> system is released), more, that same article mixes C++/ISO and C++/CLI
> stuff, like you did when you talked about PGO which is a native code
> thingy
> ( and btw. not very valuable either).
> Other sources at MSFT, (contradicting the story in MSDN Magazine), have
> clearly stated that the front end of C++/CLI which simply emits IL isn't a
> target for agressive optimization which may hurt the correct functioning
> of
> the JIT compiler. And the front end doesn't do any inlining at all, why?
> well he can't, if you know what inlining is all about you will understand
> why it's not possible at that level in a managed world, you can't inline
> IL,
> point. Note that the article doesn't mention any figures reflecting the
> advantages because of the optimizations included in the product, you know
> why?
Every body is quoting a source. Everybody is contradicting everybody.
Personally, I don't care what people say. I received a major performance
boost by moving to C++/CLI in a particular piece of software. I didn't say
anyway that would hold true everywhere, just in this case it does. Despite
your findings, I've received the improvements in performance. That's what I
know.
And yes, you can inline IL. Even the Delphi.NET compiler does. There's
always a restriction but I don't care to argue.
The point is your tests prove your right. My real world applications proves
its possible that the C++/CLI compiler can produce a better app.
Done,
Shawn
Shawn B.
http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/
Here's he clearly spells out the the VC++ compiler for .NET does a lot of
work in optimzations that the JIT is incapable of. Just another article
spelling out that the C++ compiler doesn't just emit IL and that's it.
Thanks,
Shawn
Don Kim
> Here's he clearly spells out the the VC++ compiler for .NET does a lot of
> work in optimzations that the JIT is incapable of. Just another article
> spelling out that the C++ compiler doesn't just emit IL and that's it.
Yeah, in the article he flatly claims the following:
"In Visual Studio 2005, the C++ compiler team went to great lengths to
make sure that all of the expertise gained from years of optimizing
native code was applied to managed code optimization. C++ gives you the
flexibility to do fine tuning such as high-performance marshaling that
is not possible with other languages. Moreover, the Visual C++ compiler
generates the best optimized MSIL of any of the .NET languages. The
result is that the best optimized code in .NET comes from the Visual C++
compiler."
Now, this being established, I wish more promotion would be done to make
companies out there knnow about this, so we're not stuck programming all
.Net with C#/VB.NET only.
-Don Kim
Stephen Howe
can produce a better app.
No it does not. I have seen 100's of rigged benchmarks over the years that
"prove" one langauge is faster than another. For all we know, you may have
ineptly chosen your C# compiler switches and so reached a false conclusion
by not comparing like-with-like.
Stephen Howe
Willy Denoyette [MVP]
Yes I do, and he is the source of the stuff that's been written by Stephen
Toub in MSDN mag two years ago. The most hilarious part in his story is the
"Whole Program Optimization" chapter, where he gives a sample of what WPO
can do with respect to inlining and constant propagation... but here is the
exact same sample that proves it's not done, but again, that's the danger of
talking about features before they ever get implemented.
// file sub.cpp
// Compile with: cl /LD /clr:safe /O2 sub.cpp
public ref class C
{
public:
int Square(int x)
{
return x*x;
}
};
// File: main.cpp
// Compile with: cl /clr:safe /O2 main.cpp
//
#using <sub.dll>
int main()
{
C^ c = gcnew C;
c->Square(42);
}
And here is the IL ...
// ILDASM output (partly)
...
.maxstack 2
IL_0000: newobj instance void ['sub']C::.ctor()
IL_0005: ldc.i4.s 42
IL_0007: call instance int32 ['sub']C::Square(int32)
IL_000c: pop
IL_000d: ldc.i4.0
IL_000e: ret
...
where do you see the constant propagation, or the inlining? ...Nowhere, but
rest assured the JIT will take care of this optimization (the constant
proagation and inlining).
I also know his team leader, and his story is somewhat different (sorry
can't tell you anything more because of NDA restriction), it's true they
have done a great job at this level in C++/CLI compared to MC++, but now
they are on par with what C# delivers, or do you think that developers on
the C# or VB team couldn't optimize the IL, provided it was possible? Don't
you think they didn't optimize aggressively and found out that the result
was a performance degradation because they interfered with the JIT.
All this stuff is nothing more than product promotion, something they needed
after the disaster called MC++? But it's strange that now the product is
rleased
Willy.
Shawn B.
I know far more about how to configure the various switches for C# than I do
the C++ compiler. That said, I'm not an advanced C++ user and I got great
results. Who said anything about "rigging"? I needed more performance,
switched to C++/CLI, and achieved it relatively effortlessly. Everybody
keeps nagging me about various security checks in C#. Everything is
unchecked because the way my virtual CPU is programmed it can either
guarantee there will be no overflows or will check and handle them
appropriately, among many other things.
Just because you guys haven't got the same results doesn't mean I can't. I
don't know what kinds of stuff you benchmark with, but I'm not benchmarking.
I have a simple program that runs in a loop million of times persecond and
makes about 12 function call or more in each loop to do its processing, not
to mentiond the processing overhead of the virtual devices (display,
keyboard, mouse, storage).
What I am saying, is that, I'm not basing my statements on what I read. I'm
basing my statements on my experience. I have not benchmarked anything (for
the sake of doing so), I have not testing numerical crunching (wouldn't know
how to, I have no need), and have not obsorbed what everyone else is saying
as gospel. I rewrote some code in C++/CLI that looks nearly identicle
semantically with its C# predecessor and received major performance boost.
Could be that the overhead of all my function calls are to blame, could be
other things, who knows? When I run in debug mode I get the same if not
worse performance than the C# build. When I run in Release mode with some
C++/CLI compiler settings (that C# doesn't have) I get great performance
boost. Rigged or not, No matter what I do in C# I cannot get similar
performance characteristics.
I'm not really out to "prove" anything, unlike all the MVP's in this forum.
You guys experienced contrary to me, so I must be wrong. Whatever. Grow
up. Learn that there's more to the world than your limited experience and
views. I'm simply saying that things are possible outside of your
experience and limited knowledge of things.
I guess I don't care because now I have the same performance characteristics
I was hoping for and in the end, that's good enough for me, and whether you
believe it or not I don't give a d**n because it isn't your project and your
hobby and your passion. Seems your passion is to live in your box and never
accept other ideas or possibilities. Mine is exploring and growing and
improving my skills and knowledge and learning the best tool for the job.
Thanks,
Shawn
Andre Kaufmann
>
> #using <sub.dll>
What is this line for ? Do you really expect other IL code to be inlined
by the C++/CLI compiler ? This compilation/inlining is part of the
.NET runtime, why should this be optimized by the C++/CLI compiler ?
Nobody wrote that global optimization should work over other languages /
external DLL's too.
> int main()
> {
> C^ c = gcnew C;
> c->Square(42);
> }
>
> And here is the IL ...
> // ILDASM output (partly)
> ...
> .maxstack 2
> IL_0000: newobj instance void ['sub']C::.ctor()
> IL_0005: ldc.i4.s 42
> IL_0007: call instance int32 ['sub']C::Square(int32)
> IL_000c: pop
> IL_000d: ldc.i4.0
> IL_000e: ret
> ...
And here is mine:
.method assembly static int32 main(string[] args) cil managed
{
// Code size 12 (0xc)
.maxstack 1
IL_0000: ldc.i4 0x6e4
IL_0005: call void [mscorlib]System.Console::WriteLine(int32)
IL_000a: ldc.i4.0
IL_000b: ret
} // end of method 'Global Functions'::main
>
> where do you see the constant propagation, or the inlining? ...Nowhere, but
> rest assured the JIT will take care of this optimization (the constant
> proagation and inlining).
I see it. But not in your example.
>
> All this stuff is nothing more than product promotion, something they needed
> [...]
And what is your stuff ?
> Willy.
Andre
Andre Kaufmann
> "Shawn B." <lea...@html.com> wrote in message
>[...]
> However, when calling from managed into a unmanaged accross DLL boundaries ,
> the performance of C# PInvoke is better than the C++ interop, the reason for
> this is that C++ interop calls GetLastWin32Error after each call, this
I cannot reproduce this behavior ?! Event if that would be >generally<
true, which I cannot reproduce, the overhead would be accessing a DWORD
value, eventually testing it. This is all what's GetLastError() is
about. IMHO you don't have to call the function. At least Microsoft
shouldn't have to. I think this overhead could be neglected, compared to
the marshaling and other code.
> behavior cannot be switched off, while in PInvoke interop you can set a flag
> (SetLastErrorCode=false) to turn this off.
>
> Willy.
Andre
Willy Denoyette [MVP]
"Andre Kaufmann" <andre.kau...@t-online.de> wrote in message
news:OIFN8CaR...@TK2MSFTNGP09.phx.gbl...
| Willy Denoyette [MVP] wrote:
|
| >
| > #using <sub.dll>
|
| What is this line for ?
used to refer to the assembly containing the metadata of the class C, but I
guess you know that.
Do you really expect other IL code to be inlined
| by the C++/CLI compiler ? This compilation/inlining is part of the
| .NET runtime, why should this be optimized by the C++/CLI compiler ?
| Nobody wrote that global optimization should work over other languages /
| external DLL's too.
|
No, I know that they can't inline (existing) IL, and that's exactly my point
and what I tried to prove, but OK, I have two separate assemblies (a DLL and
an EXE) which is somewhat misleading.
Now, I guess your sourcecode files looks like this (please correct me when
I'm wrong):
public ref class C
{
public:
int Square(int x)
{
return x*x;
}
};
#include "sub.h"
int main()
{
C^ c = gcnew C;
int r = c->Square(42);
System::Console::WriteLine(r);
}
and you compiled it like:
cl /clr:safe /O2 main.cpp
It's true the call will be inlined, but this is one compiland (a sinle
source file) and is not what the article suggest [1]. The header file is
included in the one and only source file and then compiled, right?
< [1] article snip...
The compiler can now perform analysis and optimization across multiple
source files. Without WPO, for example, the compiler can only inline
functions within a single compiland. With WPO, the compiler can inline
functions from any source file in the program.>
now if you make it two compilands (two source files).
// file sub.h, common header
public ref class C
{
public:
int Square(int x);
};
// file sub.h
#include "sub.h"
int C::Square(int x)
{
return x*x;
}
// file main.cpp
#include "sub.h"
int main()
{
C^ c = gcnew C;
int r = c->Square(42);
System::Console::WriteLine(r);
}
And compile its using:
cl /c /clr:safe /O2 sub.cpp
cl /clr:safe /O2 main.cpp sub.obj
and here is the resulting IL:
.method assembly static int32 main() cil managed
{
.entrypoint
// Code size 19 (0x13)
.maxstack 2
IL_0000: newobj instance void C::.ctor()
IL_0005: ldc.i4.s 42
IL_0007: call instance int32 C::Square(int32)
IL_000c: call void [mscorlib]System.Console::WriteLine(int32)
IL_0011: ldc.i4.0
IL_0012: ret
} // end of method 'Global Functions'::main
You see no inlining any more.
If you have other options, that would inline accross source files, I would
be happy to hear how.
Willy.
Shawn B.
>
> What is this line for ? Do you really expect other IL code to be inlined
> by the C++/CLI compiler ? This compilation/inlining is part of the .NET
> runtime, why should this be optimized by the C++/CLI compiler ?
> Nobody wrote that global optimization should work over other languages /
> external DLL's too.
I think you're pulling things out of your arse to make an argument. You're
own lack of understanding is causing you to "think" things up and base
you're whole argument on that. It does not inline methods in external
assemblies. It inlines source code that it can see in the *same project*
with some restrictions.
But I thought you would know that, since you're so certain, that despite
what many publications, blogs, and info an MSDN say, the C++/CLI compiler
does not optimize or inline. I don't know what kind of "test" and
"benchmarking" you've done, but you certainly haven't done any that resemble
the application I'm working on.
Thanks,
Shawn
Shawn B.
Clearly, my performance hasn't nearly doubled by rewriting it in C++/CLI
(similar code symantics, different syntax), I'm just imaging it. Clearly,
everyone that writes on the topic is wrong. Clearly, the C++/CLI compiler
doesn't do any optimzation, despite what MSDN says and quite a few others
who have tested and publicly documented their very interesting findings.
<bows to almighty Willy>
I'm just not worthy.
With Respectful Servitude,
Shawn
Andre Kaufmann
> "Andre Kaufmann" <andre.kau...@t-online.de> wrote in message
> news:OIFN8CaR...@TK2MSFTNGP09.phx.gbl...
> | Willy Denoyette [MVP] wrote:
> |
> | >
> | > #using <sub.dll>
> |
> | What is this line for ?
>
> used to refer to the assembly containing the metadata of the class C, but I
> guess you know that.
An assembly in an external DLL ? Yes I know that. I only asked to be
sure that it was no typo.
>
> Do you really expect other IL code to be inlined
> | by the C++/CLI compiler ? This compilation/inlining is part of the
> | .NET runtime, why should this be optimized by the C++/CLI compiler ?
> | Nobody wrote that global optimization should work over other languages /
> | external DLL's too.
> |
>
> No, I know that they can't inline (existing) IL, and that's exactly my point
> and what I tried to prove, but OK, I have two separate assemblies (a DLL and
> an EXE) which is somewhat misleading.
Yes it's misleading.
Would one expect the C++ compiler to optimize code in an external DLL ? No.
With IL code theoretically it could be done - but since the DLL is
loaded at runtime the compiler would have to optimize the code at
runtime ?! IIRC the C++/CLI compiler is not part of the runtime and
therefore cannot do that.
The C++/CLI "only" optimizes the code of a single solution - only
"source" code - no binary IL code.
No one expected or said that it would also optimize code of other
compilers residing in a DLL.
Ok - let's simply forget about external "DLLs" ;-) and let do that a
future .NET framework compiler.
>
> Now, I guess your sourcecode files looks like this (please correct me when
> I'm wrong):
Not quite. I've not used only a header file.
That would be "normal" inlining. I've separated the code into CPP /
Header file.
My code looks like the following:
Header:
public ref class C
{
public:
int Square(int x);
};
CPP:
#include "sub.h"
int C::Square(int x)
{
return x*x;
}
> #include "sub.h"
> int main()
> {
> C^ c = gcnew C;
>
> int r = c->Square(42);
> System::Console::WriteLine(r);
> }
>
Main is O.K.
> It's true the call will be inlined, but this is one compiland (a sinle
> source file)
Nope - 2 source files.
> and is not what the article suggest [1]. The header file is
> included in the one and only source file and then compiled, right?
No. As already said above it's separated in header and CPP file and only
a compiler with "link time" code generation is able to do that optimization.
> < [1] article snip...
> The compiler can now perform analysis and optimization across multiple
> source files. Without WPO, for example, the compiler can only inline
> functions within a single compiland. With WPO, the compiler can inline
> functions from any source file in the program.>
>
> now if you make it two compilands (two source files).
Like in my sample.
> // file sub.h, common header
> public ref class C
> {
> public:
> int Square(int x);
> };
>
> // file sub.h
> #include "sub.h"
> int C::Square(int x)
> {
> return x*x;
> }
>
> // file main.cpp
> #include "sub.h"
> int main()
> {
> C^ c = gcnew C;
> int r = c->Square(42);
> System::Console::WriteLine(r);
> }
>
> And compile its using:
>
> cl /c /clr:safe /O2 sub.cpp
> cl /clr:safe /O2 main.cpp sub.obj
> You see no inlining any more.
I wouldn't expect them to be inlined with /O2.
You don't use global optimization. Without that option the compiler
cannot do "global optimization" which is required for /GL and /LTCG
> If you have other options, that would inline accross source files, I would
> be happy to hear how.
/GL and /LTCG
> Willy.
Andre