"Poll" Has C# Generally Replaced C++

[Andre Kaufmann]

Bo Persson wrote:

[...]
So, I claim that ISO C++ is not C, because it adds a lot and changes
some parts of the language. So does Java, and so does C++/CLI. They
all have some parts in common, but a lot of differences too. That
makes them all separate languages.

I have another point to add to the Java compiler comparison:

The Java compiler cannot compile C++ code, the C++ compiler cannot
compile all C code (C99 e.g.), but the same executable which holds the
C++/CLI compiler can compile all C++ code, if the language extensions
are not enabled by a compiler switch.
Not the same language (perhaps - as I already stated in the other
thread) but the same compiler ;-) - meaning the same executable holds
the C++/CLI compiler and the C++ compiler.

ISO C++ != ECMA (ISO in near future) C++/CLI, but
a C++/CLI compiler must also be a C++ compiler that can compile all C++
code if the C++/CLI extensions are not used for a certain piece of code.

Perhaps we have just different viewpoints ;-) - a C++/CLI compiler with
disabled C++/CLI extensions isn't a C++/CLI compiler anymore for you.
For me (and Tom) it's still a C++/CLI compiler with disabled extensions
and therefore 100% compliant to the C++ compiler.

Bo Persson

Andre

 

[Peter Oliphant]

How about:

typedef int[] Int_Array_A ;
typedef std::vector<int> Int_Array_B ;

How about those syntactical apples (vs. syntactical oranges?)!!! lol

[==P==]

std::vector<int> x;

std::vector<int> x;

vs.

int[] x;

I rest my case

 

[Peter Oliphant]

And yet Microsoft experiments with a research operating system written in

C#.

The main difference between C++ and C# is that C++ is in the public domain
and C# is owned by MS. Is there any wonder why they will at least *try* to
do everything in C#? : )

[==P==]

 

[Peter Oliphant]

But nobody uses types like int[] anymore for function arguments -- you

simply pass int*.

You calling MS a nobody? : )

They use precisely this syntax with their Graphics class draw functions that
require a list of Point[]:

http://msdn2.microsoft.com/en-us/library/system.drawing.graphics.drawpolygon.aspx

[==P==]

e.g. int[] x; v.s. int x[];

int[] x;
vs
cli::array<int> x;

I agree, the original designers of C could have separated the type a
little bit better. But nobody uses types like int[] anymore for function
arguments -- you simply pass int*.

C# has the advantage of practical "non-rushed" thinking in its design.

And yet it doesn't support such basic features as constants and constant
member functions. No destructor (!!!) means no RAII, which is big problem
when an object holds a resource. You can't create a class on the stack. No
operator overloading, no templates. You can't even declare a pointer and
increment it. And so on, I could continue.

Tom

 

[Dave]

There are some cases where C++ is the only option: e.g. a pure native
Windows App with no .NET Runtime required.

I don't think this is the case any more. It appears that MS has not
provided any way to install the required DLLs for a native app without
forcing install of the runtime. I've run into several cases where
native apps won't run, even with the native DLLs in System32 as has
been the convention forever.

MS claims you have to use the correct installation ritual (see your
Windows\WinSxS folder).

So...it appears that installation of the .NET runtime is forced even
if it is not used. Anyone know of any workaround for this?

 

[Brian Muth]

I don't think this is the case any more. It appears that MS has not
provided any way to install the required DLLs for a native app without
forcing install of the runtime. I've run into several cases where
native apps won't run, even with the native DLLs in System32 as has
been the convention forever.

This is incorrect.

I have no trouble running native apps on machines without the .NET
Framework. If native apps don't run, there is a reason, independent of the
..NET Framework. Usually one can use a tool like depends.exe to find out what
dependent DLL's are missing on the target system, and then install them
manually.

If one wants a more elaborate deployment with regards to VS2005, there are
some merge modules that can be used to install just the C++ CRT, or just the
ATL80 support, for example. Again, the .NET Framework is not required.

http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx
http://msdn2.microsoft.com/en-us/library/ms235317.aspx

I hope others aren't misled by the previous post.

Brian

 

[Nikola Dudar [MSFT]]

Brian is absolutely right. It is absolutely possible with VS2005 to build
and deploy to another computer apps with only native code following
documented steps.

Nikola

--
Nikola Dudar
Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Suggestions? Bugs? Talk directly to dev teams using
http://lab.msdn.microsoft.com/productfeedback/
My Blog - http://blogs.msdn.com/nikolad/

 

[Andre Kaufmann]

There are some cases where C++ is the only option: e.g. a pure native
Windows App with no .NET Runtime required.

I don't think this is the case any more. It appears that MS has not
provided any way to install the required DLLs for a native app without
[...]

If you statically link the CRT you won't have any problems to run your
native executables on WinXP / Win2K.
If you want to deploy executables dynamically linked to the C runtime,
there's perhaps an interesting article for you:

http://www.codeproject.com/useritems/vcredists_x86.asp

Hope that helps.

Andre

 

[MasterChief]

I don´t think that C# will replace C++. As long as you need to deliver the
Redist with, I don´t know exactly how much but too much MB´s, for a simple
application with just about 10kB this thing can´t be used for all customers.
Another thing is this Garbage Collector, where MS says that they handle the
memory. But I can say that the memory isn´t handle correctly and when you
have a big Application (C#) with forms you can reboot your computer at least
every 2 days because the Memory Usage increases.
Mono is just half of the game unless they implement forms -> if you have to
work on other plattforms too, you have to use c++.

ElBarto

There are some cases where C++ is the only option: e.g. a pure native
Windows App with no .NET Runtime required.

I don't think this is the case any more. It appears that MS has not
provided any way to install the required DLLs for a native app without
[...]

If you statically link the CRT you won't have any problems to run your
native executables on WinXP / Win2K.
If you want to deploy executables dynamically linked to the C runtime,
there's perhaps an interesting article for you:

http://www.codeproject.com/useritems/vcredists_x86.asp

Hope that helps.

Andre

 

[Andre Kaufmann]

I don´t think that C# will replace C++. As long as you need to deliver the
Redist with, I don´t know exactly how much but too much MB´s, for a simple
application with just about 10kB this thing can´t be used for all customers.

Currently yes but, Windows Vista (will have) and Win2003 has the runtime
pre-installed.
Also if you have an ATI graphics card and are using the Catalyst Center
you will have the framework installed.

Another thing is this Garbage Collector, where MS says that they handle the
memory. But I can say that the memory isn´t handle correctly and when you
have a big Application (C#) with forms you can reboot your computer at least
every 2 days because the Memory Usage increases.

Perhaps you have a resource problem ? GC handles memory but not
necessarily resources.

Mono is just half of the game unless they implement forms -> if you have to
work on other plattforms too, you have to use c++.

C++ ? There are platform independent GUI frameworks for C++ as there are
for C#. WinForms surely not.

C# won't replace C++ (yet), but it will have also a huge user base and
regarding the .NET framework it doesn't matter (that) much in which
language you are developing.

And native code isn't necessarily faster:

E.g.: http://www.grimes.demon.co.uk/dotnet/man_unman.htm

ElBarto
[...]
Andre

Andre

 

[Vladimir Nesterovsky]

...

And native code isn't necessarily faster:

I do not debate this statement,

E.g.: http://www.grimes.demon.co.uk/dotnet/man_unman.htm

however results presented in Mr.'s Grimes "Managed Or Unmanaged?" article.

In his tests Mr. Grimes used "slow" IJW thunk in measurements of native C++
part. Mr. Grimes agreed with fixes he has been presented with, which show
that release build of native C++ at least 5% faster.

It's sad however, Mr. Grimes did not publish corrected results.

 

[Andre Kaufmann]

I do not debate this statement,

*g* - would be a very long thread ;-)

however results presented in Mr.'s Grimes "Managed Or Unmanaged?" article.

In his tests Mr. Grimes used "slow" IJW thunk in measurements of native C++
part. Mr. Grimes agreed with fixes he has been presented with, which show
that release build of native C++ at least 5% faster.
It's sad however, Mr. Grimes did not publish corrected results.

Thanks for the info. I agree, he should do so.

Andre