Re: C++ vs. C#

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Note that I can do anything you can do in .NET by writing assembly code. I can do
anything you can do in MFC in the native WIn32 API. I can do anything you can do in C# in
MFC.

It is not interesting is "what" I can do, but "how cost-effective is it to do it?" .NET
builds in features I have to code "by hand" in MFC.

What annoys me is that I don't have primitives like "draw button face", so if I want a
button that generally looks like a regular button but has some really cool extension, I
can't make it look like a "real" button because the dweebs at Microsoft have decided that
buttons now have to look "cool" but they don't give me the same primitives they have
(hello: antitrust cases anyone?). This limits my ability to do reasonable interfaces.

But ultimately the ONLY valid metric is "can I do what I need to do in a cost-effective
fashion?" This will *include* concepts like performance, flexibility, maintainabilty,
etc. If I can't do a tight inner loop in C# or Java to do image convolution, no matter
how good it is otherwise, it isn't solving my problem. But if all I need to do is write
some native code for that little piece of my problem and the rest of my app comes up in
one week isntead of 3 weeks, then C# really is a better choice.
joe

On Tue, 14 Apr 2009 19:40:27 -0700 (PDT), Ajay <ajaykalra@xxxxxxxxx> wrote:

On Apr 14, 5:53 pm, Daniel James <wastebas...@xxxxxxxxxxxxxxxx> wrote:
Thats really a wrong comparison. You can do much more in C# because it
gives access to .Net framework which is not available to C++
(native). .Net is very rich compared to Win32  and is not accessible
to native C++.

That's a crass, unhelpful, and totally misleading statement.

I dont think so. I should have put out of the box.

There is nothing you can do in .NET that you can't do in native code.

OK. But that would be upto the devleoper to do it. All that framework
is available at no cost. I cant imagine someone sitting down and
coding those asynchronous constructs available in .Net. Of course you
can do it. But why would you? Why not just go where its available.

NET is written in native code, so that's a self-evident truth.

So? It also uses COM. So what? MFC is written on top of Win32 but that
doesnt mean MFC is not useful.

Yes, the .NET runtime provides APIs that make some functionality easily
available to managed code, and some of that functionality is not so
easily available to native code ... but if you really can't find an
alternative to the .NET APIs you CAN call them from native code via a
C++/CLI wrapper.

Thats why I highlighted "native". Regardless, this approach highlights
the inherent limitation of whats available in native.

C++ is a vastly more powerful language than C#, and can be used for both
native and managed applications.

Yes. In real world, when you find this need, its better to stay
native. How many companies/projects do you know going thru this. Its a
good selling point for C++ but thats all it is.

However, because C# is a simpler language than C++ it is
easier to write tools for, and Visual Studio incorporates a variety of
different code generation and code manipulating tools for C# that it
doesn't support for C++. For many people this is a sufficient reason to
eschew the superiority of C++ ... C# programs are fairly easy to write,
and the versatility of the toolset largely makes up for the lack of
power and flexibility in the language itself -- as long as you don't
have a specific need to generate native code.

Agreed.

.. of course, what many of us would REALLY like is for Microsoft to
produce the same quality and range of tools for native C++ as they do
for C#. Then nobody would want or have to use C# at all (see above).

I disagree. Its not the lack to tools that is making C++ unpopular.
The language itself is the culprit. What you call superiority is
really baggage when it comes to finding the right people for job.
maintenance, compesation etc. You shouldnt expect the workforce to be
adept at it.

fact, if they'd just concentrated on getting the tool support for C++ up
to scratch they'd never have had to get involved in all this .NET stuff
at all.

Thats BS. VB was significantly more popular than C++. It wasnt because
of tools. Tools are insignificant for that reason. They become
meaningful after the fact.


As I said, though, it's much harder to produce good tools for
C++ than it is for C# because C++ is more complex and more powerful.

Agreed and thats not a good thing. Occasionally it is, but for a vast
majority it isnt.


The important thing is to learn enough about the two approaches that you
understand the trade-offs that are made when you choose between native
code development and .NET, and when you choose between C# and any other
language on .NET. Only when you have that understanding can you make
your decision ...

Of course.


After having used C++ for many many years and been with .Net for last
3-4 years, I can safely say .Net is significantly more powerful,
productive than anything I used in MFC/C++. C++ is needlessly complex
and costly compared to C#/.Net. That doesnt imply C++ doesnt have any
place in the dev community. But its dated and should be used only for
specialized projects. I have also noticed that people complaining
about .Net have simply not used it the way it ought to be used. Tools
have nothing to do with this.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast