remove struct's default constructor?

[Willy Denoyette [MVP]]

The fact that the standard is called the "C++/CLI" spec is a bit of a
hint in my opinion that the standard specifically targets the CLI,
whereas the C# spec doesn't - it could, in theory, target a different
architecture. It's unlikely to happen, but the spec still isn't tied to
the CLI, which is why I believe it's a mistake to call something in the
C# spec "inaccurate" just because it doesn't reflect what's going on
under the hood in an implementation which *does* target the CLI.

Your Interpretation Jon, "C++/CLI" is the name of a C++ dialect, just to distinct it from
C++ ISO and no-one guarantees that this name will be kept in future (awaiting ISO
ratification), it's target is the CLI but no-one stops you from targeting another platform.
It's just as tied to the CLR as C# is tied to the CLI, the compiler produces MSIL just like
MSFT's C# produces MSIL.
Also, note that C++/CLI produced MSIL run's on Mono as well.

Willy.

 

[Willy Denoyette [MVP]]

WHERE is he? if there is one you should be able to show me one.

Willy, it is beyond obvious you have not listened to a single thing,
in the most literal sense, that I've said about CIL and C#. (IL is
more properly called CIL, so I'll use that instead, I'm trying to use
the right terminology).

CIL is not C#.

CIL != C#.

I've already said this. Jon just showed an example of this, which
I'll post here again to show I have also been meaning the exact same
thing:

int i = new int();

There's the proof. It's calling a constructor. Now go look for it.
It wont' be in the CIL. It won't exist in the assembly code. So, you
*illogically* assume the constructor does not exist at the high
level. Yet, there it is.

There is no point in continuing this discussion. Because your entire
argument is based on a fallacy.

Imagine how frustrated you would be if you attempted to argue that C
has switch statement syntax, and I showed you the optimized assembly
code computed a singke memory address and called a single JMP
instruction to that address, to avoid numerous if/then/else style of
assembly, and claimed that the C language only has GOTO, because
that's all that exists in assembly. Imagine that. That's an analogy
of the stance you are taking. It's a fallacy.

There is no function call optimized away, see later.

I was showing an analogy. Please pay closer attention.

You are wrong by comparing managed code to native C++, the object model is too different.

That's irrelevant to the context of my point. I could use any high
level language in which lower language code is produced from the high
level language code to show the same point. What the low level has
doesn't dictate what the high level doesn't have.

Again, the C# compiler:

1) set's the 'initonly ' flag per default in the methods metadata, that means that the
JIT
compiler (and not the C# compiler) will have to produce code to initialize the stack
frame
at zero, and this for ALL variables on the stack frame regardless their type.
2) the runtime *initializes* the GC heap space, to hold reference instances, to zero,
that
means that an embedded value type will have it's fields at zero per default. This is a
runtime and in no way a language feature.
3) does NOT emit a public parameterless constructor method for the value type, which is
called a "default constructor",and obviously,
4 does not emit a "call" to the (non existent) "constructor" in IL, instead he emits a
"initobj", which is optimized away by the JIT as he has knowlegde of 1 and 2 and will
take
advantage of it.

Now, C# takes advantage of what happens as a result of 1 and/or 2, so it doesn't need to
emit IL for a "default constructor" and for a call to this constructor, in order to
*initialize* the object fields to their default value.
Now this (1 & 2) is what msdn and some of you guys call the "default constructor", well
I'm
sorry but this is not what I call a constructor. Call it an 'initializer' or 'conceptual
constructor' but not a "default constructor" (which isn't such "thing" , as per Jon's
definition <I would say that a default constructor is one supplied by the compiler> - see
one of it's replies)

You're defining what C# has based on the low level code the compiler
produces. That is fundamentally flawed. Everything based on that
assumption is therefore flawed. You can show us again and again what
CIL code is produced, and it is absolutely irrelevant.

But , there is no IL produced by the C# compiler that possibly could be called a "default
constructor". see above.

Willy, you're stepping out of bounds. CIL is not C#. There is no
assembly code produced by VC++ compiler that could possibly be called
a default constructor. MOV [EAX],0. Is that a constructor? No.
Does C++ have constructors for int's? Yes.

Assembly language is not C++.
CIL is not C#.

Zytan

Please stop treating me as a newbie, I know better than YOU what CIL is and what C# is, I
have nothing to learn from you, please keep that in mind.
Note also that what is poduced by MSFT's compilers is MSIL to be exact:

http://msdn.microsoft.com/library/d...ml/cpconMicrosoftIntermediateLanguageMSIL.asp

maybe you can start reading this, I already did several years back.



Willy.

 

[Jon Skeet [C# MVP]]

Your Interpretation Jon, "C++/CLI" is the name of a C++ dialect, just
to distinct it from C++ ISO and no-one guarantees that this name will
be kept in future (awaiting ISO ratification), it's target is the CLI
but no-one stops you from targeting another platform. It's just as
tied to the CLR as C# is tied to the CLI, the compiler produces MSIL
just like MSFT's C# produces MSIL.

The C++/CLI spec is tied to the CLI spec all over the place. There are
444 occurrences of "CLI" in the spec, excluding "C++/CLI". It talks
about CLI types, and the introduction even specifies: "It describes a
technology, called C++/CLI, which is a binding between the Standard C++
programming language and the Common Language Infrastructure (CLI)." Any
implementation which didn't target the CLI would make a nonsense of
half of the standard.

The C# spec, on the other hand, barely mentions the CLI (18
occurrences), and in *its* introduction has:

"Although Microsoft=3Fs implementation of C# relies on CLI for library
and runtime support, other implementations of C# need not, provided
they support an alternate way of getting at the minimum CLI features
required by this C# standard (see Annex D)."

In a few places, it talks about "For C# implementations targeting the
CLI..." giving the clear indication that there could certainly be other
implementations. Is there a single similar sentence in the C++/CLI
spec?


I certainly stand by my belief that the C# spec isn't nearly as tied to
the CLI as the C++/CLI spec is.

Also, note that C++/CLI produced MSIL run's on Mono as well.

Sure, because that's an implementation of the CLI standard.

 

[Willy Denoyette [MVP]]

The C++/CLI spec is tied to the CLI spec all over the place. There are
444 occurrences of "CLI" in the spec, excluding "C++/CLI". It talks
about CLI types, and the introduction even specifies: "It describes a
technology, called C++/CLI, which is a binding between the Standard C++
programming language and the Common Language Infrastructure (CLI)." Any
implementation which didn't target the CLI would make a nonsense of
half of the standard.

The C# spec, on the other hand, barely mentions the CLI (18
occurrences), and in *its* introduction has:

Isn't 18 occurences not enough to say that it's tied to the CLI?

"Although Microsoft=3Fs implementation of C# relies on CLI for library
and runtime support, other implementations of C# need not, provided
they support an alternate way of getting at the minimum CLI features
required by this C# standard (see Annex D)."

The same can be said about C++/CLI, it's a standard, it's not owned by MS, any-one can
implement his own set of tools and infrastructure to support the language (probably no-one
will ever do, but technically it's posiible.

In a few places, it talks about "For C# implementations targeting the
CLI..." giving the clear indication that there could certainly be other
implementations. Is there a single similar sentence in the C++/CLI
spec?


I certainly stand by my belief that the C# spec isn't nearly as tied to
the CLI as the C++/CLI spec is.


Sure, because that's an implementation of the CLI standard.

Don't get too optimistic, I didn't say that everything works as it should and STL/CLR
(Orcas) doesn't work at all, no surprises here, the CLR derives from the CLI standard as you
probably know.


I said before that ECMA-334 is a cleaned up version, it has gone through a number of
revisions, the first drafts did even mention CLR instead of CLI, the annotated version has
hundred of notes indicating where MSFT's implementation differs from the standard . ECMA-372
is not cleaned up, it's based on the only implementation available, but when it ever will be
submitted to ISO it will have to get a clean-up (I heard rumors that the first draft was
refused, don't know for sure whether MS still is in the process).

Willy.


Willy.

 

[Jon Skeet [C# MVP]]

Isn't 18 occurences not enough to say that it's tied to the CLI?

No - not when you look at what those references are.

The same can be said about C++/CLI, it's a standard, it's not owned
by MS, any-one can implement his own set of tools and infrastructure
to support the language (probably no-one will ever do, but
technically it's posiible.

Given that it's a binding *to the CLI* then any "implementation" which
didn't use the CLI wouldn't really be implementing that binding, would
it?

Don't get too optimistic, I didn't say that everything works as it
should and STL/CLR (Orcas) doesn't work at all, no surprises here,
the CLR derives from the CLI standard as you probably know.

Sure. I dare say the CLI spec will be appropriately revised and
implemented by Mono all in good time.

I said before that ECMA-334 is a cleaned up version, it has gone
through a number of revisions, the first drafts did even mention CLR
instead of CLI, the annotated version has hundred of notes indicating
where MSFT's implementation differs from the standard .

Did you mean 335 there, out of interest? I think so, but I'm not sure.

ECMA-372 is not cleaned up, it's based on the only implementation
available, but when it ever will be submitted to ISO it will have to
get a clean-up (I heard rumors that the first draft was refused,
don't know for sure whether MS still is in the process).

I think it's unlikely they'll get rid of the ties to the CLI to the
same extent that the C# spec explicitly makes room for
non-CLI-targetting implementations.

 

[Willy Denoyette [MVP]]

No - not when you look at what those references are.


Given that it's a binding *to the CLI* then any "implementation" which
didn't use the CLI wouldn't really be implementing that binding, would
it?


Sure. I dare say the CLI spec will be appropriately revised and
implemented by Mono all in good time.


Did you mean 335 there, out of interest? I think so, but I'm not sure.

No I mean ECMA-334 The "C# Language Specification".
And I'm also talking about ECMA-372 which is the "C++/CLI Language Specification".
What ECMA-372 tries to do is explain how the new syntax maps to the CLI types, the document
clearly targets the C++ community, for instance an array is created like this:
array<int>^ iar = gcnew array<int>(10);
they try to make clear the "differences" between the C++ ISO binding and the C++ CLI
binding, so they talk about CLI Arrays, Int32 CLI type, short CLI type etc... (int is 32 bit
in C++/CLI, is not defined in C++;, see).
C# doesn't mention the CLI when talking about C# arrays, int, short etc... they talk about
"Array Types", int type, short type..
But in fact they can remove all these CLI and just do as ECMA-334 does, something like this:

C++/CLI supports two kinds of types: value types and reference types. Value types include
simple types (e.g.,
char, int, and float), enum types, and struct types. Reference types include class types,
interface types,
delegate types, and array types.

See what I mean?

I think it's unlikely they'll get rid of the ties to the CLI to the
same extent that the C# spec explicitly makes room for
non-CLI-targetting implementations.

And who are "they"? If you mean MS, I'm sure you are right, If you mean some other org. I'm
afraid the C++ community is not waiting for this, so guess you are right too. But
technically it should be possible.
Note, that there is more I can tell you about this but I can't do it in a public forum like
this.

Willy.

 

[Jon Skeet [C# MVP]]

No I mean ECMA-334 The "C# Language Specification".
Okay.

And I'm also talking about ECMA-372 which is the "C++/CLI Language
Specification". What ECMA-372 tries to do is explain how the new
syntax maps to the CLI types, the document clearly targets the C++
community, for instance an array is created like this: array<int>^
iar = gcnew array<int>(10); they try to make clear the "differences"
between the C++ ISO binding and the C++ CLI binding, so they talk
about CLI Arrays, Int32 CLI type, short CLI type etc... (int is 32
bit in C++/CLI, is not defined in C++;, see). C# doesn't mention the
CLI when talking about C# arrays, int, short etc... they talk about
"Array Types", int type, short type.. But in fact they can remove all
these CLI and just do as ECMA-334 does, something like this:

C++/CLI supports two kinds of types: value types and reference types.
Value types include simple types (e.g., char, int, and float), enum
types, and struct types. Reference types include class types,
interface types, delegate types, and array types.

See what I mean?

Yes - but if that were the intention, why not do it from the start? As
you said before, 372 has the benefit of hindsight, that the CLI is
already "out there" - so if the authors wanted a platform-agnostic
spec, why not write one like the C# spec to start with?

And who are "they"? If you mean MS, I'm sure you are right, If you
mean some other org. I'm afraid the C++ community is not waiting for
this, so guess you are right too. But technically it should be
possible. Note, that there is more I can tell you about this but I
can't do it in a public forum like this.

I meant "they" as in "anyone who gets to shape the spec". It just feels
unlikely to me that a spec so heavily CLI-specific would try to become
agnostic.

But I think we've probably reached the stage where we need to just
agree to disagree.

 

[Willy Denoyette [MVP]]

Yes - but if that were the intention, why not do it from the start? As
you said before, 372 has the benefit of hindsight, that the CLI is
already "out there" - so if the authors wanted a platform-agnostic
spec, why not write one like the C# spec to start with?

History of is paved with mistakes I guess.

I meant "they" as in "anyone who gets to shape the spec". It just feels
unlikely to me that a spec so heavily CLI-specific would try to become
agnostic.

That's why the spec needs a clean-up, as I said before the ISO commitee seems to have some
objections.

But I think we've probably reached the stage where we need to just
agree to disagree.

I don't think we are in complete disagreement, but I'm afraid I can't tell you exactly why.

Willy.

 

[Zytan]

You are totally missing the point. I'm just trying to show you tje
fallacy.

Show me machine code (or assembly that maps 1:1 with machine code),
and I'll show you no structs, classes, or any C# concepts other than
'goto'. It was meant as an exaggerated analogy to your statement:
"because CIL doesn't show a default constructor, then C# doesn't have
one".

It is such a simple logical concept. How can you miss this point?

Just because machine code does have 'if/then/else' it doesn't mean C
code that made it didn't have that construct. Likewise, just because
CIL doesn't call a method called .cctor, it doesn't mean the C# code
that made it didn't have it.

This shows the fallacy that your position is based on.

Isn't the CIL code supposed to be the 'end byte code' from any number
of possible .NET languages? Couldn't I make my own .NET language, and
it compile into CIL code? Couldn't this language have constructs that
NO other .NET language has? But, because CIL code doesn't natively
support these constructs, I'll have to compile it in a fancy way that
makes the CIL code emulate what I want? To which, someone who holds
your fallacy would say "hey, the CIL code doesn't do X, thus your
language doesn't have X."

But, isn't that exactly what assembly code DOES for a high level
language? Emulates what it wants?

This is exactly how the first C++ compilers worked. They compiled
into C code, so it could be compiled for any number of CPUs. Now,
even though ***C didn't support classes***, amazingly the 'lower
level' C code did precisely what C++'s classes demanded, thus proving
that just because the lower level code doesn't have a certain
construct, it doesn't mean the higher level language doesn't have it!

No you simply showed your complete ignorance.

My last paragraph is a proof that your argument is based on a fallacy.

Funny.

It wasn't meant to be.

Where does "classes" in C++ come from?

I look at the C code that the old C++ compiler makes, and I don't see
any classes. So where do "classes" come from?

The C++ designer.

Right?

Zytan

 

[Zytan]

I have nothing to learn from you, please keep that in mind.

I would never be so arrogant to say that I have nothing to learn from
you, even if I disagreed with everything you've said. Your thought
certaonly explains your defensive behavior right from the first post
-- you've assumed that I'm wrong before you've read my words.

Note also that what is poduced by MSFT's compilers is MSIL to be exact:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgu...

"This intermediate language was once called Microsoft Intermediate
Language (MSIL), just called IL. But the most proper term is now the
Common Intermediate Language (CIL)."
-- Charles Petzold, .NET Book Zero, Version 1.1, January 1, 2007

Zytan

 

[Zytan]

Couldn't I make my own .NET language, and

it compile into CIL code? Couldn't this language have constructs that
NO other .NET language has? ... To which, someone who holds
your fallacy would say "hey, the CIL code doesn't do X, thus your
language doesn't have X."

Case in point:

http://www.codeplex.com/IronPython
"IronPython is a new implementation of the Python programming language
running on .NET"

Zytan

 

[Willy Denoyette [MVP]]

I would never be so arrogant to say that I have nothing to learn from
you, even if I disagreed with everything you've said. Your thought
certaonly explains your defensive behavior right from the first post
-- you've assumed that I'm wrong before you've read my words.


"This intermediate language was once called Microsoft Intermediate
Language (MSIL), just called IL. But the most proper term is now the
Common Intermediate Language (CIL)."
-- Charles Petzold, .NET Book Zero, Version 1.1, January 1, 2007

And it's still called MSIL, it's MSFT's implementation of what is called CIL...
http://blogs.msdn.com/brada/archive/2005/09/20/CILorMSIL.aspx
just like the CLR is MSFT's implementation of the CLI.
It's mentioned here in the detailed description of the 20060059474 patent claim, see:
http://www.freepatentsonline.com/20060059474.html for a brief description.
So do others that specifically target MSFT's implementation of the CLI, see here :
http://www.microfocus.com/dotnet.asp, note that this means that MF is supporting MSIL and
the CLR.
The MS SDK tools compile to MSIL, however , if you don't agree with MSFT naming feel free to
add your arguments/comments to MSDN's Wiki pages at:
http://msdn2.microsoft.com/en-us/library/c5tkafs1(VS.80).aspx

Willy.

 

[Zytan]

"This intermediate language was once called Microsoft Intermediate

And it's still called MSIL, it's MSFT's implementation of what is called CIL...http://blogs.msdn.com/brada/archive/2005/09/20/CILorMSIL.aspx
just like the CLR is MSFT's implementation of the CLI.
It's mentioned here in the detailed description of the 20060059474 patent claim, see:http://www.freepatentsonline.com/20060059474.htmlfor a brief description.
So do others that specifically target MSFT's implementation of the CLI, see here :http://www.microfocus.com/dotnet.asp, note that this means that MF is supporting MSIL and
the CLR.
The MS SDK tools compile to MSIL, however , if you don't agree with MSFT naming feel free to
add your arguments/comments to MSDN's Wiki pages at:http://msdn2.microsoft.com/en-us/library/c5tkafs1(VS.80).aspx

I've read Brad's post before. Isn't that a bit like saying someone is
programming, say, "MS-C++", and not C++, since MS's implementation of C
++ is slightly non-conformant? Every other place I read about it
states that MSIL was the original official name, and then it was
changed into CIL after standardization.
http://en.wikipedia.org/wiki/Common_Intermediate_Language
So, it is Microsofties who now choose to call their implementation of
it MSIL, when that name used to be the official name itself. And, if
they want to do so, I guess that's their prerogative. Certainly
everyone agrees that the official bytecode (and it is called bytecode,
so it was ok for me to refer to the IL as bytecode) is called CIL,
which is what any specific implementation is based off of.

I think I'll stick the majority / consensus on this one, and call it
CIL, just as I prefer to say that I am programming C++ within VC++,
even though MS's implementation of C++ is not quite the same, and thus
could technically be called something different.

Zytan

 

[Willy Denoyette [MVP]]

I've read Brad's post before. Isn't that a bit like saying someone is
programming, say, "MS-C++", and not C++, since MS's implementation of C
++ is slightly non-conformant? Every other place I read about it
states that MSIL was the original official name, and then it was
changed into CIL after standardization.
http://en.wikipedia.org/wiki/Common_Intermediate_Language
So, it is Microsofties who now choose to call their implementation of
it MSIL, when that name used to be the official name itself. And, if
they want to do so, I guess that's their prerogative. Certainly
everyone agrees that the official bytecode (and it is called bytecode,
so it was ok for me to refer to the IL as bytecode) is called CIL,
which is what any specific implementation is based off of.

I think I'll stick the majority / consensus on this one, and call it
CIL, just as I prefer to say that I am programming C++ within VC++,
even though MS's implementation of C++ is not quite the same, and thus
could technically be called something different.

Zytan

You can call it whatever you like (and I, like the majority will continue to call it MSIL or
IL in this NG) as long as you know what you are talking about, but MSIL was NEVER changed
into CIL, it was called CIL by the standards committee because 1) the committee never
accepts a name that reflects the name to the original designer, 2) MSIL is what is produced
by the Microsoft compilers/assemblers.

And it's officially called MSIL by Microsoft:
http://msdn2.microsoft.com/en-us/library/c5tkafs1(VS.80).aspx
these are the latest official msdn pages (seems like you don't care as it doesn't fit your
point) and they talk about MSIL, Serge Lidin, the lead developer of the MSIL assembler
http://msdn2.microsoft.com/en-us/library/496e4ekx(VS.80).aspx ,disassembler and peverify,
call it MSIL (or IL for short), just to make it clear that it's Microsoft's implementation
he's talking about. In his book
http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463 he clearly explains what
MSIL, CIL an IL stands for, this is what I call authorative information.
ILASM is producing MSIL and is able to produce non-CIL compliant IL, if you need to be sure
that the IL produced is CIL compliant, you'll have to run PEVERIFY on it. The same goes for
C++/CLI which can produce non-conformant CIL while still being MSIL compliant, C# and VB.NET
both produce verifiable IL ( CIL compliant) .

Willy.

 

[Zytan]

You can call it whatever you like (and I, like the majority will continue to call it MSIL or

IL in this NG) as long as you know what you are talking about, but MSIL was NEVER changed
into CIL, it was called CIL by the standards committee because 1) the committee never
accepts a name that reflects the name to the original designer, 2) MSIL is what is produced
by the Microsoft compilers/assemblers.

And it's officially called MSIL by Microsoft:http://msdn2.microsoft.com/en-us/library/c5tkafs1(VS.80).aspx
these are the latest official msdn pages (seems like you don't care as it doesn't fit your
point) and they talk about MSIL, Serge Lidin, the lead developer of the MSIL assemblerhttp://msdn2.microsoft.com/en-us/library/496e4ekx(VS.80).aspx,disassembler and peverify,
call it MSIL (or IL for short), just to make it clear that it's Microsoft's implementation
he's talking about. In his bookhttp://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463he clearly explains what
MSIL, CIL an IL stands for, this is what I call authorative information.
ILASM is producing MSIL and is able to produce non-CIL compliant IL, if you need to be sure
that the IL produced is CIL compliant, you'll have to run PEVERIFY on it. The same goes for
C++/CLI which can produce non-conformant CIL while still being MSIL compliant, C# and VB.NET
both produce verifiable IL ( CIL compliant) .

No, I do care. I want to know the truth. Petzold has been wrong
before (one time was due to listening to the Win32 team's completely
wrong notion of what hungarian notation was, and spreading it to the
masses as the right method, so it wasn't really his fault, but he did
popularize it outside of MS).

MSIL is what they've been calling their own code since day 1, then.
CIL was a standard made from MSIL. But MSIL is not 100% compatible
with CIL. That doesn't make any sense. I can understand the
standardization process to make it available to all, and I'm sure
that's what MS wanted. But, how can the standards committee come in
and change it? There must have been stuff that was still too much MS
specific in it. I guess, it's all irrelevant. We now have a
standard, CIL, and MS's products follow it somewhat, and produce their
own flavour. Of which they themselves call MSIL, since that's the
name it always had.

But, even after all this, I can still understand why Charles Petzold
and everyone else not "in the know" about these details prefer to use
CIL. Because that's the standard. Just like C++ is a standard, and
we all code C++, not something called, say, MS-C++. If MS called
their code MS-C++, we likely all would keep on using the name C++,
since that's the standard. So, yeah, the MSIL team calls their code
MSIL, since it's not 100% CIL, and was always call that. But, Petzold
and others call any of this stuff produced CIL, since they are all
based on a standard.

It sounds like both people are right, in different perspectives. One
is technically right (like saying, "I'm programming C++ with MS
extensions"). The other is right in the terms of dealing with that
the standard is meant for / is all about ("I'm programming C++").

Zytan