Is it your general opinion that C# is generally designed/intended/ready to
replace C++? I know the answer is not black and white but please repond YES
or NO (add any comments if you would like)
I just thought it might be interesting to get a tally. This is related to a
previous thread. So far we have two NOs from "aa" and Bo Persson.
--
Greg McPherran www.McPherran.com
Dec 10 '05
71  3186 
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.
"Tamas Demjen" wrote:
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
Bo Persson wrote: "Andre Kaufmann" <an************ ****@t-online.de> skrev i meddelandet
news:ef******** ******@TK2MSFTN GP12.phx.gbl... 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;
So I think it's equally true to speak of 2 and/or of 3 languages.
;-)
Let's disagree. :-)
:-( / ;-)
Bo Persson
Andre
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
"JAL" <JA*@discussion s.microsoft.com > wrote in message
news:87******** *************** ***********@mic rosoft.com... Sounds like C++ meets all your requirements and you have no need to code
in a garbage collected environment.
<SNIP>
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
--
Greg McPherran www.McPherran.com
"Andre Kaufmann" <an************ ****@t-online.de> skrev i meddelandet
news:uo******** *****@TK2MSFTNG P12.phx.gbl... Bo Persson wrote: "Andre Kaufmann" <an************ ****@t-online.de> skrev i
meddelandet news:ef******** ******@TK2MSFTN GP12.phx.gbl... 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<typena me 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
Bo Persson wrote: 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<typena me 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
Bo Persson wrote: "Andre Kaufmann" <an************ ****@t-online.de> skrev i meddelandet
[...]
The C++/CLI standard (9.1.1) also shows a problem with a template
struct called "generic" :-)
template<typena me 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
"Tamas Demjen" <td*****@yahoo. com> skrev i meddelandet
news:uZ******** ********@TK2MSF TNGP09.phx.gbl. .. Bo Persson wrote:
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.
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.
template<typena me T> struct generic {
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
"Andre Kaufmann" <an************ ****@t-online.de> skrev i meddelandet
news:ev******** ******@TK2MSFTN GP14.phx.gbl... Bo Persson wrote: "Andre Kaufmann" <an************ ****@t-online.de> skrev i
meddelandet [...]
The C++/CLI standard (9.1.1) also shows a problem with a template
struct called "generic" :-)
template<typena me 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.
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.
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
Bo Persson wrote: "Andre Kaufmann" <an************ ****@t-online.de> 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 This thread has been closed and replies have been disabled. Please start a new discussion. |
