"Poll" Has C# Generally Replaced C++

[Guest]

Hi Bo... Of course, the code is not _exactly_ equivalent Stack vs Heap
allocation.

 

[Andre Kaufmann]

Some have pointed out advantages of C++ which I don't contest. Yet, I am not
sure these are outweighed by other considerations for many .NET development
scenarios.

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

Currently yes. But Microsoft (research) has a native C#/MSIL compiler
and there are AFAIK also some commercial native C# compilers.
Though all memory is still garbage collected and surely the C# native
compilers are somewhat restricted.

However for a .NET app, if C++ is on par with C#, then how does one decide
which language to use. Are there any criteria besides being already familiar
with C++ etc.?

I think you are more productive by using C#/VB.Net than C++ for a .NET
app, at least with Visual Studio.
Just because you have many more IDE features available for that
languages. Refactoring, Code Snippets, more Intellisense Features, Test
Cases and many others and they are much faster in compilation.
If you need to access unmanaged resources or (old) C++ code surely
C++/CLI is the way to go.
But since the languages in .NET can be very tightly coupled, it's no big
deal to mix them. Write a C++/CLI Dll which is accessing and dealing
with the umanaged resources and exports .NET wrapper classes and consume
the from C#/VB.Net or any other .NET language.

Another criteria is speed / optimized code. Optimized code currently can
be written only in a native language, like C++ and the C++ compiler
generates more optimized MSIL code than the C#/VB.Net compilers do
(currently).

I.e. are there any concrete reasons why the full development cycle right up
to delivery will be more cost effective and yield greater ROI using one
language vs. the other?

See above. For GUI applications or GUI components I wouldn't use C++,
but prefer C#, just for the reasons I mentioned above.
For speed centric and optimized code I would prefer C++.

Thank You

Regards,
Andre

 

[Guest]

Andre.. Ok this stuff IS harder than brain surgery. If I get some time I will
try to implement this but after doing 40 hours of neurosurgery I need to go
to sleep .

But this unfortunately doesn't help if you need to have an object in
multiple lists and automatically disposed after the last reference has
been removed from the list.

[...]

Andre

 

[Bo Persson]

Hi Bo... Of course, the code is not _exactly_ equivalent Stack vs
Heap
allocation.

I know it's different, that was a point.

Managed code solves the memory leak "problem" of

void foo()
{
MyClass* p = new MyClass;
p->DoSomethingThatThrows();
delete p;
}

My solution is not to invent a new language, but use what is already
in C++

void foo()
{
MyClass m;
m.DoSomethingThatThrows();
}

Here the m object, and any subobjects or allocations done by m, will
be destroyed at the end of scope. The destructor of m is called,
Always.

So, there isn't any problem in the first place, and then I'm offered a
solution. No thanks. .-)


Bo Persson

 

[Bo Persson]

Some have pointed out advantages of C++ which I don't contest. Yet,
I am not
sure these are outweighed by other considerations for many .NET
development
scenarios.

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

However for a .NET app, if C++ is on par with C#, then how does one
decide
which language to use. Are there any criteria besides being already
familiar
with C++ etc.?

But that weighs in heavily. If I have been writing C++ code for 15-20
years, and are happy with that, what are the productivity advantages
of moving to another language?

I.e. are there any concrete reasons why the full development cycle
right up
to delivery will be more cost effective and yield greater ROI using
one
language vs. the other?

Exactly my question!


That is actually 3 languages, not 2.

C++/CLI is not even close to the language called ISO C++. It just
looks similar, just like Java does.


Bo Persson

 

[Tamas Demjen]

class JALCollection : IDisposable //, IEnumerator
{
private bool disposed = false;
private ArrayList list = new ArrayList(); [...]
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
foreach (IDisposable d in list)
{
d.Dispose();
}
}

Yes, this is exactly how Delphi programmers are forced to handle
containers too. Always wrap it into a 200 line class, just to achieve
the functionality of what the framework provided collection is supposed
to do. It's rather error prone when this responsibility is left up to
the programmer. Let alone the time being spent on typing in the same
code again and again. My applications use 100s of C++ containers, some
of which are inter-references, and it would be very painful to
substitute them with ad-hoc hand-written replacement containers, just
because the language doesn't provide the concept of destructors. Having
destructors makes a lot of difference, and with large projects it saves
a whole lot of time in the long run.

To be fair, using generics in C# 2.0 you can write your own dream
resource-holding containers, that's true, so you don't have to retype
the same kind of code again and again. But it's still a bit
disappointing to me that deterministic destruction of resources is not
automatic but often requires serious effort on the programmer's side.
Isn't it ironic that in C# you're not supposed to worry about leaks
anymore, and yet in old native C++ you can achieve safe resource
handling much easier and safer?

Of course everything can be done in every language, even in assembly,
it's just a matter of how much effort it requires, how error prone it
is, and how maintainable the code is.

Tom

 

[Andre Kaufmann]

"Greg" <[email protected]> skrev i meddelandet
[...]

IMHO C++ - C++/CLI and C# can be used very effectively together and
both ...

That is actually 3 languages, not 2.

C++/CLI is not even close to the language called ISO C++. It just
looks similar, just like Java does.

C++/CLI is an extension to C++, therefore a C++/CLI compiler must be
able to compile standard C++.
So I think it's equally true to speak of 2 and/or of 3 languages. ;-)

Bo Persson

Andre

 

[Andre Kaufmann]

Andre.. Ok this stuff IS harder than brain surgery. If I get some time I will
try to implement this but after doing 40 hours of neurosurgery I need to go
to sleep .

Uff. I would just state the opposite. You (will) have a comparison
between both - I better don't give it a try - should be better for the
patient ;-)

[...]
Andre

 

[Bo Persson]

"Greg" <[email protected]> skrev i meddelandet
[...]

IMHO C++ - C++/CLI and C# can be used very effectively together
and
both ...

That is actually 3 languages, not 2.

C++/CLI is not even close to the language called ISO C++. It just
looks similar, just like Java does.

C++/CLI is an extension to C++, therefore a C++/CLI compiler must be
able to compile standard C++.

No, it does not.

There are some extensions, but also some parts that are missing, and
some parts that just behave differently.

So I think it's equally true to speak of 2 and/or of 3 languages.
;-)

Let's disagree.

Bo Persson

 

[Guest]

Sounds like C++ meets all your requirements and you have no need to code in a
garbage collected environment.

 

[Guest]

Tom... For an expert C++ coder, exception safe deterministic destructors and
smart pointers offers a powerful solution. Some things just don't lend
themselves well to a garbage collected language and are better done in C++.
Unfortunately, the reality is that for many programmers, a garbage collected
language is safer and more maintainable. Many problems are well addressed by
Java and C#. There is a lot of useful code out there written in Java and C#.
I am not here to defend them. Let the marketplace decide if Java and C# will
flourish. I will continue to code in whatever language does the job for me
including C++/cli. I will even stoop as low as scripting if it keeps my
databases up and running.

 

[Andre Kaufmann]

Bo Persson wrote:

[...]

C++/CLI is an extension to C++, therefore a C++/CLI compiler must be
able to compile standard C++.

No, it does not.

Quote from the C++/CLI standard:

"C++/CLI is an extension of the C++ programming language as described in
ISO/IEC 14882:2003"

There are some extensions, but also some parts that are missing, and
some parts that just behave differently.

Could you give an example of C++ code, which the C++/CLI compiler
cannot compile ?

AFAIK there's currently only one C++/CLI compiler VC 2005. And it's able
to compile most of the C++ code to MSIL intermediate language.
Parts that don't compile to MSIL code will be automatically compiled to
native code.

If I use #pragma unmanaged for a single function it will be compiled
always to native code. So I don't see any restrictions for the C++/CLI
compiler.

What's restricted for some cases is to mix C++/CLI and C++ code.
E.g. you cannot embed currently a native class in a reference class,
only as a pointer. IIRC it has been announced by Herb Sutter that the
next version of the VC compiler won't have this restriction.
Also other compiler vendors announced to implement the C++/CLI standard.

Additionally I can use some C++/CLI extensions directly in native C++
code: E.g.:

vector<int> a;
.......
for each(int v in a) cout << v << endl;

Let's disagree.

:-( / ;-)

Bo Persson

Andre

 

[Michael Viking]

Nobody ever seems to point out that if one wants garbage collection, they
don't need Java or C#, etc. There are supposedly good, commercial garbage
collectors available for C++. On the other hand, if people would quit
writing garbage, they wouldn't need a collector.

-Michael Viking

Sounds like C++ meets all your requirements and you have no need to code in a
garbage collected environment.

<SNIP>

 

[Guest]

Regarding performance, I would hope that floating point (i.e. float, double)
math operations in .NET will still use the math hardware in the CPU. I.e. the
runtime layer, even though not native, will still access hardware facilities
as needed?

Thank You

 

[Bo Persson]

Bo Persson wrote:

[...]

C++/CLI is an extension to C++, therefore a C++/CLI compiler must
be able to compile standard C++.

No, it does not.

Quote from the C++/CLI standard:

"C++/CLI is an extension of the C++ programming language as
described in ISO/IEC 14882:2003"

There are some extensions, but also some parts that are missing,
and some parts that just behave differently.

Could you give an example of C++ code, which the C++/CLI compiler
cannot compile ?

Sure. A silly example is

namepace cli
{
int x;
}

That is valid ISO C++ code, but C++/CLI has reserved the namespace cli
for itself.

The C++/CLI standard (9.1.1) also shows a problem with a template
struct called "generic"

template<typename T> struct generic {

typedef int I;

};

class X {};

generic<class X> x1;

generic<class X()> x2;

This would compile in ISO C++, but is invalid C++/CLI.

There are other differences in name lookup for subclasses, if they are
native or ref. Can you override a private virtual function? Not to
talk about multiple inheritance from non-interface classes...


Bo Persson

 

[Tamas Demjen]

That is valid ISO C++ code, but C++/CLI has reserved the namespace cli
for itself.

That will hardly ever be a problem in the real world. Every framework
reserves its own namespace, so you could easily have two independent
libraries using the same framework. Even that wouldn't be a big problem
-- you just have to ensure that they're not include from the same unit.
Let alone those billions of old libraries that pollute the global namespace.

template<typename T> struct generic {

Interesting. But this is almost the same as

#define if for
#define public private

You're hijacking the language.

You wrote "C++/CLI is not even close to the language called ISO C++. It
just looks similar, just like Java does", and Andre pointed out that
it's not so. Now you're bringing up fabricated examples to prove that
C++/CLI is indeed just 99.9% ISO compatible, not 100%. They're very
entertaining examples, but C++/CLI is in fact truly an extension to ISO
C++, even if it break a couple of subtle details. I agree that the
extensions themselves are not that close to ISO C++, and when you
program in a pure managed environment, you're using the extension part
mostly, and therefore it looks different than an ISO C++ code.

There are other differences in name lookup for subclasses, if they are
native or ref. Can you override a private virtual function? Not to
talk about multiple inheritance from non-interface classes...

They're only for ref classes. We all agree that the extensions C++/CLI
adds to ISO C++ are not ISO C++ compatible.

Tom

 

[Andre Kaufmann]

"Andre Kaufmann" <[email protected]> skrev i meddelandet
[...]
The C++/CLI standard (9.1.1) also shows a problem with a template
struct called "generic"

template<typename T> struct generic {

typedef int I;

};

class X {};

generic<class X> x1;

generic<class X()> x2;

This would compile in ISO C++, but is invalid C++/CLI.

There are other differences in name lookup for subclasses, if they are
native or ref. Can you override a private virtual function? Not to
talk about multiple inheritance from non-interface classes...

Yes. But I pointed out that you can compile the ISO C++ code, you just
have to disable the language extension if you have code that should use
the new reserved keywords. So this wouldn't be a real world problem as
Tom has already pointed out.

There are enough examples for valid ISO C++ code that have the same
problems:

E.g.:

class export {};

Has been for a long time valid ISO C++ code. While VC 2005 still
compiles this code, other compilers e.g. Comeau won't compile it.

There are also other examples for the upcoming C++ standard, which will
break existing code.

Bo Persson

A valid C++/CLI compiler must be also able to compile ISO C++ code, if
you have to disable the language extensions or change the code is
another story.
I've already agreed that you cannot freely mix C++ and C++/CLI code in
all aspects, but that wasn't part of our discussion ;-)


The ISO C++ comitee has been very restrictive in introducing new
keywords, because they could break existing code. Microsoft has done a
fairly good job in introducing the new keywords in a context sensitive way:

E.g.:

class abstract
{
virtual void s() abstract;
};

compiles without any problems as managed and unmanaged code.

IIRC the ISO C++ committee has also adopted this way in introducing new
context sensitive keywords, but I'm not sure about that - please correct
me if I'm wrong.

I don't have anything against new keywords. Far from it, IMHO they, the
ISO C++ committee, shouldn't have been that restrictive.

virtual void s() abstract;

looks better and would be more logical for developers learning C++ than

virtual void s() = 0;


To sum it up, I think Microsoft has done it well to introduce a new
C++/CLI standard, rather than continuing the ISO compliant managed C++
extensions.

Andre

 

[Bo Persson]

That will hardly ever be a problem in the real world.

No, but it is an example of a piece of that is valid ISO C++, but does
not compile with C++/CLI.

It shows that "a C++/CLI compiler must be able to compile standard
C++" is not all true. C++/CLI might compile some C++ code, or most C++
code. That doesn't make them the same language.

A lot of C code is compilable by a C++ or C++/CLI compiler, but that
doesn't mean that they are all C. They are just similar, but
different.

Interesting. But this is almost the same as

#define if for
#define public private

No, it is not. Using #define to change keyword is explicitly
forbidden. A struct generic { } is valid C and C++, but in some cases
doen't wortk in C++/CLI. Because the languages are different?

You're hijacking the language.

But it is valid in my language, not in your. And I claim that they are
different. Perhaps they are?

You wrote "C++/CLI is not even close to the language called ISO C++.
It just looks similar, just like Java does", and Andre pointed out
that it's not so. Now you're bringing up fabricated examples to
prove that C++/CLI is indeed just 99.9% ISO compatible, not 100%.
They're very entertaining examples, but C++/CLI is in fact truly an
extension to ISO C++, even if it break a couple of subtle details.

That's what I said.

C++/CLI is an extended subset of ISO C++, with an few sematic
differences thrown in.

I agree that the extensions themselves are not that close to ISO
C++, and when you program in a pure managed environment, you're
using the extension part mostly, and therefore it looks different
than an ISO C++ code.

Right.

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.


Bo Persson

 

[Bo Persson]

"Andre Kaufmann" <[email protected]> skrev i
meddelandet [...]
The C++/CLI standard (9.1.1) also shows a problem with a template
struct called "generic"

template<typename T> struct generic {

typedef int I;

};

class X {};

generic<class X> x1;

generic<class X()> x2;

This would compile in ISO C++, but is invalid C++/CLI.

There are other differences in name lookup for subclasses, if they
are native or ref. Can you override a private virtual function? Not
to talk about multiple inheritance from non-interface classes...

Yes. But I pointed out that you can compile the ISO C++ code, you
just have to disable the language extension if you have code that
should use the new reserved keywords. So this wouldn't be a real
world problem as Tom has already pointed out.

There are enough examples for valid ISO C++ code that have the same
problems:

E.g.:

class export {};

Has been for a long time valid ISO C++ code. While VC 2005 still
compiles this code, other compilers e.g. Comeau won't compile it.

No, export is a reserved word in ISO C++. MS has just not implemented
that part, being too busy doing C++/CLI instead.

There are also other examples for the upcoming C++ standard, which
will break existing code.

Probably, but that will be a revised language. That's ok.

A valid C++/CLI compiler must be also able to compile ISO C++ code,
if you have to disable the language extensions or change the code is
another story.

But if I have to change the code, how could it be the same language?

I've already agreed that you cannot freely mix C++ and C++/CLI code
in all aspects, but that wasn't part of our discussion ;-)

The ISO C++ comitee has been very restrictive in introducing new
keywords, because they could break existing code. Microsoft has done
a fairly good job in introducing the new keywords in a context
sensitive way:

E.g.:

class abstract
{
virtual void s() abstract;
};

compiles without any problems as managed and unmanaged code.

IIRC the ISO C++ committee has also adopted this way in introducing
new context sensitive keywords, but I'm not sure about that - please
correct me if I'm wrong.

I don't have anything against new keywords. Far from it, IMHO they,
the ISO C++ committee, shouldn't have been that restrictive.

virtual void s() abstract;

looks better and would be more logical for developers learning C++
than

virtual void s() = 0;


To sum it up, I think Microsoft has done it well to introduce a new
C++/CLI standard, rather than continuing the ISO compliant managed
C++ extensions.

I agree to that. I just don't agree that it is still the same
language. It's an new one, sometimes called "New C++" by Microsoft.



Bo Persson

 

[Andre Kaufmann]

"Andre Kaufmann" <[email protected]> skrev i meddelandet
[...]

There are enough examples for valid ISO C++ code that have the same
problems:

E.g.:

class export {};

Has been for a long time valid ISO C++ code. While VC 2005 still
compiles this code, other compilers e.g. Comeau won't compile it.

No, export is a reserved word in ISO C++. MS has just not implemented
that part, being too busy doing C++/CLI instead.

Yes, but it has been introduced some years ago, before it could be used
without any problems as class name. Should be only an example, like the
example you gave by using the "generic" C++/CLI keyword.

Microsoft (Herb Sutter IIRC) has stated, that the effort (2 man years)
isn't worth the benefit to implement "export".

[...]
I agree to that. I just don't agree that it is still the same
language. It's an new one, sometimes called "New C++" by Microsoft.

Not the same language (perhaps ;-) ) but the same compiler.
I still can compile my "old" C++ code and add some managed code to it.
And you might interpret it as a mixture of 2 languages in the same
source file - perhaps we could agree on that ? ;-)

Bo Persson

Andre