Who owns C#?

[Sathyaish]

Who owns the language C#? I'm not talking about the compiler, but about
the language? Who owns it - Microsoft or the ECMA? I see there are two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

 

[Nick Hounsome]

Who owns the language C#? I'm not talking about the compiler, but about
the language? Who owns it - Microsoft or the ECMA? I see there are two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are nice
guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with an ISO
standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific but
some of the framework exposes MS specific stuff.

 

[Kevin Spencer]

Nobody owns it. C# is an ECMA standard which Microsoft developed and
submitted.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

 

[Alvin Bruney]

With C# it's not quite as bad. The language itself is not MS specific but

some of the framework exposes MS specific stuff.

Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

 

[William Stacey [MVP]]

| compiler so effectively they have a separate language.
|
| With C# it's not quite as bad. The language itself is not MS specific but
| some of the framework exposes MS specific stuff.

So exposing your own technology is now somehow bad? I don't get what your
saying.

 

[james.curran]

MS don't own C++ either but none of their header files will work with an ISO
standard compiler so effectively they have a separate language. <<

This is complete nonsense. The very purpose of system header files is
to isolate complier dependant code (so that a user program which
includes a such a header file can be standardized). The ISO C++
Standard make no requirements on the headers files at all --- They
don't even have to actually exist. The only requirement is that if a
user program contains the code (for example) "#include <iostream>" then
certain identifiers must be defined. How exactly a compiler
accomplishes that is purely it's concern.

 

[Kevin Spencer]

Yeah, actually, the C# language is *not* part of the framework. There are
compilers and class libraries for C# in the framework, but it is important
to distingusih between the language itself and the various tools and devices
for implementing it. The language itself is actually just a specification, a
protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people even
get the idea that Visual Studio is somehow part of the C# language. The
language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

With C# it's not quite as bad. The language itself is not MS specific but
some of the framework exposes MS specific stuff.

Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

The usual MS obfuscation. They want to tell the world that they are nice
guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with an
ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific but
some of the framework exposes MS specific stuff.

 

[William Stacey [MVP]]

And c#.net is MS's implementation of the spec (plus anything they add above
that). Mono is Novell's implementation of the spec, etc.

--
William Stacey [MVP]

| Nobody owns it. C# is an ECMA standard which Microsoft developed and
| submitted.
|
| --
| HTH,
|
| Kevin Spencer
| Microsoft MVP
| Professional Numbskull
|
| Hard work is a medication for which
| there is no placebo.
|
| | > Who owns the language C#? I'm not talking about the compiler, but about
| > the language? Who owns it - Microsoft or the ECMA? I see there are two
| > specifications to each version:
| >
| > 1. One that comes out from Microsoft; and
| > 2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
| > revised after every release from Microsoft.
| >
| > What's the deal?
| >
|
|
|

 

[Bruce Wood]

C# is a theoretically open standard. "Theoretically" in the sense that
you can legally write your own C# compiler for any platform you like,
and legally sell it. Microsoft cannot come after you for patent /
copyright infringement.

However, it is only in theory, because C# really isn't of much use
without the .NET Framework. Now, I'm not entirely clear on whether you
could legally reproduce the entire Framework without bringing the
lawyers out of the woodwork. Somehow I suspect not, but I'm open to
being corrected. Even if you could, the job would be so enormous as to
be impractical, even if the Framework weren't constantly changing,
which it is.

This is why Mono always lags far behind. Yes, in theory C# is an open
standard. However, in practice MS has a huge advantage in that they're
the ones establishing the standard, so they're always out in front, no
matter what. So, for all practical purposes, it's a proprietary
language.

Nonetheless, it still kicks ass.

 

[Nick Hounsome]

standard compiler so effectively they have a separate language. <<

This is complete nonsense. The very purpose of system header files is
to isolate complier dependant code (so that a user program which
includes a such a header file can be standardized). The ISO C++
Standard make no requirements on the headers files at all --- They
don't even have to actually exist. The only requirement is that if a
user program contains the code (for example) "#include <iostream>" then
certain identifiers must be defined. How exactly a compiler
accomplishes that is purely it's concern.

I agree with what you are saying is strictly correct but that's not really
my point.

The Windows API (not the C++ std headers) makes extensive use of
non-standard keywords and pragmas.
This means that you cannot write much windows code without knowing those
keywords and pragmas and therefore it is effectively a different language.
Open any windows project and you will find some __somethingOrOther somewhere
and then there are LPCSTR et al - Yes they are only macros but they are used
so extensively in windows code that you have to know them and you could be
forgiven for thinking that they were keywords.

When I first saw a windows C++ program I was totally confused despite many
years of working with C++ on varous POSIX compliant systems. I created
something or other using a wizard (it was a while ago and I forget the
details) and the mess it generated was so full of double underscores,
pragmas and non-syntatctic macros that VS didn't even recognize it as a
class for syntax highlighting! I ran away in terror and I've only come back
to windows now that C# and .NET have made it intelligible.

 

[Nick Hounsome]

There is an area of overlap between language and framework. It exists in C++
as well but it is much smaller (basically just type_info,bad_cast,bad_typeid
and exception).

In C# the language and framework are much more closely entwined because all
the basic types are structs so, for example, "System.String" is part of the
C# language whereas "std::string" is not part of the C++ language.

Yeah, actually, the C# language is *not* part of the framework. There are
compilers and class libraries for C# in the framework, but it is important
to distingusih between the language itself and the various tools and
devices for implementing it. The language itself is actually just a
specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C# language.
The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

Who owns the language C#? I'm not talking about the compiler, but about
the language? Who owns it - Microsoft or the ECMA? I see there are two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are nice
guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with an
ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

 

[Nick Hounsome]

You've got me.
I take it back - I seem to remember reading something on the Mono website
but I can't find it so perhaps I was mistaken.

Incidentally, for anyone else who finds the MSDN pages really slow for .NET
help (especially the treeview on the left) it might be worth using the mono
ones for core stuff because they seem to be much faster
http://www.go-mono.com/docs/

With C# it's not quite as bad. The language itself is not MS specific but
some of the framework exposes MS specific stuff.

Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

The usual MS obfuscation. They want to tell the world that they are nice
guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with an
ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific but
some of the framework exposes MS specific stuff.

 

[Kevin Spencer]

There is an area of overlap between language and framework. It exists in

C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is part
of the C# language whereas "std::string" is not part of the C++ language.

This just doesn't fly. Note the "std::" in the C++ string class reference.
This is a reference to the STL. The STL is the C++ equivalent of the stdio
library used in C and the System NameSpace (the "Standard Library")
according to ECMA) in C#. There is no difference. Each version of the
language has a core set of functionlity for which a Standard Library is
defined and used.

The biggest difference here is that the Standard Library is not specific to
the C# language, whereas the STL and stdio are specific to the older flavors
of C. In .Net, the Standard Library is language-neutral, part of the CLI.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists in
C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is part
of the C# language whereas "std::string" is not part of the C++ language.

Yeah, actually, the C# language is *not* part of the framework. There are
compilers and class libraries for C# in the framework, but it is
important to distingusih between the language itself and the various
tools and devices for implementing it. The language itself is actually
just a specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C# language.
The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.
Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------


Who owns the language C#? I'm not talking about the compiler, but
about
the language? Who owns it - Microsoft or the ECMA? I see there are two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are
nice guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with
an ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

 

[Kevin Spencer]

I forgot to mention that the System Namespace (and the Standard Library) is
also only a specification, not an assembly or a DLL. That is, as far as the
language is concerned. Mono bears this out, as it does not use the same DLLs
as the Microsoft.Net Framework.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists in
C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is part
of the C# language whereas "std::string" is not part of the C++ language.

Yeah, actually, the C# language is *not* part of the framework. There are
compilers and class libraries for C# in the framework, but it is
important to distingusih between the language itself and the various
tools and devices for implementing it. The language itself is actually
just a specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C# language.
The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.
Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------


Who owns the language C#? I'm not talking about the compiler, but
about
the language? Who owns it - Microsoft or the ECMA? I see there are two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are
nice guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with
an ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

 

[William Stacey [MVP]]

| The Windows API (not the C++ std headers) makes extensive use of
| non-standard keywords and pragmas.
| This means that you cannot write much windows code without knowing those
| keywords and pragmas and therefore it is effectively a different language.
| Open any windows project and you will find some __somethingOrOther
somewhere
| and then there are LPCSTR et al - Yes they are only macros but they are
used
| so extensively in windows code that you have to know them and you could be
| forgiven for thinking that they were keywords.
|
| When I first saw a windows C++ program I was totally confused despite many
| years of working with C++ on varous POSIX compliant systems. I created
| something or other using a wizard (it was a while ago and I forget the
| details) and the mess it generated was so full of double underscores,
| pragmas and non-syntatctic macros that VS didn't even recognize it as a
| class for syntax highlighting! I ran away in terror and I've only come
back
| to windows now that C# and .NET have made it intelligible.

Mostly agree with that. All that junk was very confusing for me too. Thank
god we don't have to deal with any of that in c#.

 

[Nick Hounsome]

This just doesn't fly. Note the "std::" in the C++ string class reference.
This is a reference to the STL. The STL is the C++ equivalent of the stdio
library used in C and the System NameSpace (the "Standard Library")
according to ECMA) in C#. There is no difference. Each version of the
language has a core set of functionlity for which a Standard Library is
defined and used.

No. The standard library is the standard library - it is not part of the
definition of either C or C++ because it doesn't need to be.

The C++ compiler does not understand ANY class or function in the C or C++
libraries other than those I mentioned any more than it understands one that
you write. In particular std::string gets no special treatment compared to
any other class.

The typeinfo stuff is different because the compiler itself synthesizes
instances of type_info at compile time and will explicitly generate code to
throw bad_cast.

C# on the other hand explicitly understands all the basic type
classes/structs. For example <string s = "hello";> results in IL to call the
System.String constructor where as <char* s = "hello";> does not use the
standard library at all.
Also, everything derives from System.Object and the compiler must know this
implicitly - There is no equivalent knowledge in a C++ compiler to link a
class to anything in the standard library.

The biggest difference here is that the Standard Library is not specific
to the C# language, whereas the STL and stdio are specific to the older
flavors of C. In .Net, the Standard Library is language-neutral, part of
the CLI.

The .NET Framework is not specific to C# but C# IS specific to the .NET
framework - For example you could not change the System.String constructors
without changing C# whereas you can do what you like to std::string and it
will require no changes whatsoever to any C++ compiler or, more simply, it
is impossible to remove the System.Int32 class from the framework because
"int" really is System.Int32 whereas in C++ "int" is just "int".

C++ generates type_info in the same way that C# generates System.Type
objects.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists in
C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is part
of the C# language whereas "std::string" is not part of the C++ language.

Yeah, actually, the C# language is *not* part of the framework. There
are compilers and class libraries for C# in the framework, but it is
important to distingusih between the language itself and the various
tools and devices for implementing it. The language itself is actually
just a specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C# language.
The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"Alvin Bruney" <www.lulu.com/owc> wrote in message
With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.
Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------


Who owns the language C#? I'm not talking about the compiler, but
about
the language? Who owns it - Microsoft or the ECMA? I see there are
two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are
nice guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with
an ISO standard compiler so effectively they have a separate language.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

 

[Jon Skeet [C# MVP]]

Nick Hounsome wrote:

The .NET Framework is not specific to C# but C# IS specific to the .NET
framework

That's not true on two levels:

1) The .NET framework is just one implementation of the CLI spec. Mono
is another, for instance.

2) C# is specific to "frameworks similar to the CLI" - it must work in
a broadly similar way in order to support the C# semantics, and it must
have the types that C# specifically requires (and those types have to
work in broadly the same way). However, it would be possible for that
not to be a CLI. For instance, it's not inconceivable that someone
could write a C# compiler which compiled to native code instead of IL -
or to a different type of intermediate language.

There are certainly strong enough ties to make it unlikely that anyone
will ever compile to non-IL/non-CLI, but the specification doesn't
absolutely require it.

Jon

 

[Kevin Spencer]

No. The standard library is the standard library - it is not part of the

definition of either C or C++ because it doesn't need to be.

Hey, *you're* the guy who used std::string as an example of how they are
"sifferent," by comparing it with System.String. There is no difference.

Now, you are trying to argue with me by changing the parameters of your
argument. You switch to *char, which is not comparable to anything in C#,
since pointers are unsafe code, and not directly supported by the language.
So, now you're comparing apples to oranges. There is *no* equivalent of
*char in C#. Why? Because C# is fully object-oriented, and C++ is not. C++
supports true primitive data types like int, char, and byte, while the
"equivalents" in C# are not primitive data types at all, but are derived
from base classes. C# supports only objects. This is why they are referred
to as "value types."

So, when you compare apples to apples, that is, STL types and functions in
C++ to System namespace equivalents in C#, you are comparing things that are
conceptually alike. When you compare that which is included in C++ with
something which is *not* that, you are comparing apples to oranges.

The typeinfo stuff is different because the compiler itself synthesizes
instances of type_info at compile time and will explicitly generate code
to throw bad_cast.

The compiler is not the language. The C++ language is dependent upon the STL
in the same way that C# is dependent upon the Standard Library. Again, the
Standard Library is a specification. The fact that the STL specification is
part of a C++ compiler doesn't mean that C++ is not dependent upon the STL.
In fact, C# is also indirectly dependent upon stdio, without which there
would *be* no data types, just bits.

In other words, there is no difference between what you term "overlap
between language and framework" in C# and the "overlap between language and
framework" in C++ and C.

I think that what you seem to find objectionable is the fact that C# is a
higher-level language than C++. But C++ is a higher-level language than C,
which is a higher-level language than Assembler, which is a higher-level
language than machine language. The only difference is a matter of degree.
As to why that difference exists, you would have to trace back the history
of programming. Each successively higher level of language has arisen out of
the need to optimize the time spent in development on increasingly complex
applications, on increasingly faster machines.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

This just doesn't fly. Note the "std::" in the C++ string class
reference. This is a reference to the STL. The STL is the C++ equivalent
of the stdio library used in C and the System NameSpace (the "Standard
Library") according to ECMA) in C#. There is no difference. Each version
of the language has a core set of functionlity for which a Standard
Library is defined and used.

No. The standard library is the standard library - it is not part of the
definition of either C or C++ because it doesn't need to be.

The C++ compiler does not understand ANY class or function in the C or C++
libraries other than those I mentioned any more than it understands one
that you write. In particular std::string gets no special treatment
compared to any other class.

The typeinfo stuff is different because the compiler itself synthesizes
instances of type_info at compile time and will explicitly generate code
to throw bad_cast.

C# on the other hand explicitly understands all the basic type
classes/structs. For example <string s = "hello";> results in IL to call
the System.String constructor where as <char* s = "hello";> does not use
the standard library at all.
Also, everything derives from System.Object and the compiler must know
this implicitly - There is no equivalent knowledge in a C++ compiler to
link a class to anything in the standard library.

The biggest difference here is that the Standard Library is not specific
to the C# language, whereas the STL and stdio are specific to the older
flavors of C. In .Net, the Standard Library is language-neutral, part of
the CLI.

The .NET Framework is not specific to C# but C# IS specific to the .NET
framework - For example you could not change the System.String
constructors without changing C# whereas you can do what you like to
std::string and it will require no changes whatsoever to any C++ compiler
or, more simply, it is impossible to remove the System.Int32 class from
the framework because "int" really is System.Int32 whereas in C++ "int" is
just "int".

C++ generates type_info in the same way that C# generates System.Type
objects.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists in
C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is part
of the C# language whereas "std::string" is not part of the C++
language.

Yeah, actually, the C# language is *not* part of the framework. There
are compilers and class libraries for C# in the framework, but it is
important to distingusih between the language itself and the various
tools and devices for implementing it. The language itself is actually
just a specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C#
language. The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"Alvin Bruney" <www.lulu.com/owc> wrote in message
With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.
Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------


Who owns the language C#? I'm not talking about the compiler, but
about
the language? Who owns it - Microsoft or the ECMA? I see there are
two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are
nice guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work with
an ISO standard compiler so effectively they have a separate
language.

With C# it's not quite as bad. The language itself is not MS specific
but some of the framework exposes MS specific stuff.

 

[Nick Hounsome]

Hey, *you're* the guy who used std::string as an example of how they are
"sifferent," by comparing it with System.String. There is no difference.

Yes there is.

std::string is not part of the definition of C++.

System.String is part of the definition of C#

Now, you are trying to argue with me by changing the parameters of your
argument. You switch to *char, which is not comparable to anything in C#,

That was my point:

string in C# IS System.String which is also part of the library/CLI/.NET
Framework or whatever you want to call it.

The nearest thing to a C# string in the C++ LANGUAGE definition is (const)
char* which IS NOT defined in the standard library whereas std::string is
defined ONLY in the library and not referenced by the C++ LANGUAGE spec.

It is possible to have a C++ without a standard library (except for
type_info etc) - I've used it myself for embedded work. It is NOT possible
to have C# without System.String, System.MulticastDelegate etc.

[end of annotations]

since pointers are unsafe code, and not directly supported by the
language. So, now you're comparing apples to oranges. There is *no*
equivalent of *char in C#. Why? Because C# is fully object-oriented, and
C++ is not. C++ supports true primitive data types like int, char, and
byte, while the "equivalents" in C# are not primitive data types at all,
but are derived from base classes. C# supports only objects. This is why
they are referred to as "value types."

So, when you compare apples to apples, that is, STL types and functions in
C++ to System namespace equivalents in C#, you are comparing things that
are conceptually alike. When you compare that which is included in C++
with something which is *not* that, you are comparing apples to oranges.

The typeinfo stuff is different because the compiler itself synthesizes
instances of type_info at compile time and will explicitly generate code
to throw bad_cast.

The compiler is not the language. The C++ language is dependent upon the
STL in the same way that C# is dependent upon the Standard Library. Again,
the Standard Library is a specification. The fact that the STL
specification is part of a C++ compiler doesn't mean that C++ is not
dependent upon the STL. In fact, C# is also indirectly dependent upon
stdio, without which there would *be* no data types, just bits.

In other words, there is no difference between what you term "overlap
between language and framework" in C# and the "overlap between language
and framework" in C++ and C.

I think that what you seem to find objectionable is the fact that C# is a
higher-level language than C++. But C++ is a higher-level language than C,
which is a higher-level language than Assembler, which is a higher-level
language than machine language. The only difference is a matter of degree.
As to why that difference exists, you would have to trace back the history
of programming. Each successively higher level of language has arisen out
of the need to optimize the time spent in development on increasingly
complex applications, on increasingly faster machines.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists
in C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is
part of the C# language whereas "std::string" is not part of the C++
language.

This just doesn't fly. Note the "std::" in the C++ string class
reference. This is a reference to the STL. The STL is the C++ equivalent
of the stdio library used in C and the System NameSpace (the "Standard
Library") according to ECMA) in C#. There is no difference. Each version
of the language has a core set of functionlity for which a Standard
Library is defined and used.

No. The standard library is the standard library - it is not part of the
definition of either C or C++ because it doesn't need to be.

The C++ compiler does not understand ANY class or function in the C or
C++ libraries other than those I mentioned any more than it understands
one that you write. In particular std::string gets no special treatment
compared to any other class.

The typeinfo stuff is different because the compiler itself synthesizes
instances of type_info at compile time and will explicitly generate code
to throw bad_cast.

C# on the other hand explicitly understands all the basic type
classes/structs. For example <string s = "hello";> results in IL to call
the System.String constructor where as <char* s = "hello";> does not use
the standard library at all.
Also, everything derives from System.Object and the compiler must know
this implicitly - There is no equivalent knowledge in a C++ compiler to
link a class to anything in the standard library.

The biggest difference here is that the Standard Library is not specific
to the C# language, whereas the STL and stdio are specific to the older
flavors of C. In .Net, the Standard Library is language-neutral, part of
the CLI.

The .NET Framework is not specific to C# but C# IS specific to the .NET
framework - For example you could not change the System.String
constructors without changing C# whereas you can do what you like to
std::string and it will require no changes whatsoever to any C++ compiler
or, more simply, it is impossible to remove the System.Int32 class from
the framework because "int" really is System.Int32 whereas in C++ "int"
is just "int".

C++ generates type_info in the same way that C# generates System.Type
objects.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

There is an area of overlap between language and framework. It exists
in C++ as well but it is much smaller (basically just
type_info,bad_cast,bad_typeid and exception).

In C# the language and framework are much more closely entwined because
all the basic types are structs so, for example, "System.String" is
part of the C# language whereas "std::string" is not part of the C++
language.

Yeah, actually, the C# language is *not* part of the framework. There
are compilers and class libraries for C# in the framework, but it is
important to distingusih between the language itself and the various
tools and devices for implementing it. The language itself is actually
just a specification, a protocol, a set of rules, concepts, and ideas.

This is a point that a lot of people seem to get stuck on. Some people
even get the idea that Visual Studio is somehow part of the C#
language. The language is much more abstract than that.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"Alvin Bruney" <www.lulu.com/owc> wrote in message
With C# it's not quite as bad. The language itself is not MS
specific but some of the framework exposes MS specific stuff.
Such as???

--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------


Who owns the language C#? I'm not talking about the compiler, but
about
the language? Who owns it - Microsoft or the ECMA? I see there are
two
specifications to each version:

1. One that comes out from Microsoft; and
2. Another that is a follow up from ECMA TC39 (ECMA-334) that is
revised after every release from Microsoft.

What's the deal?

The usual MS obfuscation. They want to tell the world that they are
nice guys using open standards but in practice they're not.

MS don't own C++ either but none of their header files will work
with an ISO standard compiler so effectively they have a separate
language.

With C# it's not quite as bad. The language itself is not MS
specific but some of the framework exposes MS specific stuff.

 

[Nick Hounsome]

Nick Hounsome wrote:



That's not true on two levels:

1) The .NET framework is just one implementation of the CLI spec. Mono
is another, for instance.

2) C# is specific to "frameworks similar to the CLI" - it must work in
a broadly similar way in order to support the C# semantics, and it must
have the types that C# specifically requires (and those types have to
work in broadly the same way). However, it would be possible for that
not to be a CLI. For instance, it's not inconceivable that someone
could write a C# compiler which compiled to native code instead of IL -
or to a different type of intermediate language.

There are certainly strong enough ties to make it unlikely that anyone
will ever compile to non-IL/non-CLI, but the specification doesn't
absolutely require it.

I'm sorry, I don't seem to be communicating my point - I'll try again:

It is possible to have C++ without a standard library (except for type_info
etc) - I've used it myself for embedded work. It is NOT possible to have C#
without System.Object, System.String, System.MulticastDelegate etc.

I may have been a bit lax in my use of framework/library/CLI but my point
remains that however you define it there is a mutual dependency between
these things and C# that doesn't exist between C++ and its standard
libraries.