I have a struct constructor to initialize all of my private (or public
readonly) fields. There still exists the default constructor that sets
them all to zero. Is there a way to remove the creation of this
implicit default constructor, to force the creation of a struct via my
constructor only?
Zytan
Mar 8 '07
74  15842 
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Ah, no - there I disagree. I would say that a default constructor is
one supplied by the compiler. It is a public, parameterless constructor
which looks identical to one which can (for reference types, obviously)
be supplied in code, but it's often handy to be able to distinguish
between a default constructor as generated by the compiler and a public
parameterless constructor as supplied by the user.
It depends on what documents you reading, there is no consistent
definition of a "default constructor", some call a "default user
defined constructor" a default constructor" while others don't make
the distinction. Anyway, you got a point, I also prefer to call the
compiler generated constructor the "default constructor".
Yes, it's a shame it's not explicitly defined, only used.
If we're quoting ECMA, we should also quote the C# spec (ECMA 334)
which doesn't say that the compiler will generate a default constructor
for value types, but which *does* say that "every struct implicitly has
a parameterless instance constructor, which always returns the value
that results from setting all value type fields to their default
value". (2nd edition)
Which is "wrong" also, the C# compiler does not produce a "default
constructor" for value types, that is, there is no .ctor() emitted in
IL.
As I said, there's nothing in the spec which says the C# compiler will
generate a default constructor for value types - just that (from a C#
point of view) every value type has an implicit constructor.
Put it this way: suppose the CLI (which is independent of C#) *did*
require the compiler to output a parameterless constructor, and instead
of initobj, that constructor were used. What bit of C# as a language
would change? Nothing.
You need to distinguish between the IL constructor and the constructor
as defined and used in C# code.
ECMA-334 also says that such constructor "returns" an initialized
value type! Now, how can something that doesn't exist return
something, more, how can you ever call such thing?
Because it exists conceptually in C#, and the compiler makes sure that
the semantics match the specification. What goes on at the CLI level is
outside the scope of the C# spec.
All what the C# compiler does in this case is:
Irrelevant. The C# compiler just makes the visible semantics match the
specification.
As I've said in another post, I think that's reasonable for the C# spec
to define in terms of keeping C# itself consistent, even though no
actual IL parameterless constructor is generated or called.
Agreed, but the more you dive into the ECMA specs, the more apparent
the inconsistencies and contradictions become, this confuses some
people as you now.
Some of the inconsistencies have certainly confused people - this is
the first time I remember this particular one coming up.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Zytan" <zy**********@yahoo.comwrote in message
news:11********************@s48g2000cws.googlegrou ps.com...
So, basically, it is regarded as a default constructor. It's just
that all it does it zero things out, so it most cases, it needn't be
called, so it isn't called. Because of this, it cannot be replaced.
That's why C# doesn't allow a parameterless struct constructor. If
none of the above were true, there would be no issue with C# allowing
the coding of a parameterless default constructor. I think this
proves pretty conclusively that struct's have default constructors.
No. Its' not that structs can't have parameterless constructors, it's the C# compiler
that
doesn't emit such constructor (called a "default constructor"), and doesn't allow you to
define a parameterless constructor in C#.
The zero initialization you are noticing and what you call a "default constructor", comes
from;
1) the 'initlocals 'flag set in the method metadata by the C# compiler, this flag is a
hint
for the JIT to initialize all local variables to zero, so, a local variable holding a
struct
is zero initialized because of a default action on all the locals.
2) for embedded structs, it comes from the fact that the memory allocated for a reference
instance on the GC heap is zeroed by the GC/memory allocator, but not by a constructor.
Ok, yes, I know something else zeroes the memory. What I am saying is
that because of these other things that zeor the memory, there is no
need to call a constuctor that does so, thus, the byte code or IL code
or whatever it is that is created from the C# code, doesn't explicitly
call a constructor. It would be foolish for two reasons: 1. to repeat
the zeroing out, and 2. it's just plain slow.
Now, because the code that is created / compiled from the C# code,
whether its byte code or IL code, whatever it is called, I have no
idea, but my point is, just because whatever created this code is
smart enough to realize, hey, yeah, don't call a constructor for all
basic value types and all structs since they are already zeroed out by
the methods you've described, it doesn't *mean* that the C# language
doesn't have a constructor.
What I am trying to say is: Everything I am saying could be
absolutely true, and the result is precisely what you see: no
constructor calls in the IL.
>Now, if you continue to call this a "default constructor" or a "conceptual constructor",
no
problem for me. But I know they are not constructors "pure sang".
It is very convenient to call it a default constructor, because
everything flows into place with that thought.
And, yes, I can see that it does from your perspective, too.
So, it's basically up to the language designers to say what it what.
Given the evidence, I highly suspect that default constructors for
struct is a concept that they created.
>I'm not talking about byte code ether, I'm talking about what is produced by the #C
compiler, that is, no "default constructor".
What? Isn't "what is produced by the #C compiler" == "byte code"? If
not, replace "byte code" with "IL". Or replace it with whatever
should be there. Whatever that is called, that's what I'm talking
about, and excuse my lack of knowledge with the terminology. I will
use "IL" from now, assuming that's correct.
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
WHERE is he? if there is one you should be able to show me one.
Just because
the compiler is smart enough to not make it have one, then it's ok.
It's like constructors for basic data types in C++, you can call them,
but you know that down in the assembly code that is made, there is no
function call to any constructor. It just stores the value right into
memory. It doesn't mean the constructor doesn't exist, and in fact,
you can initialize a variable with constructor like syntax, which
shows at the C++ level, it does exist. IL is not C#. I guess that's
the issue. It's like you're looking under the hood, and seeing
'what's really there', and you're saying 'hey, no constructor call!
thus, C# structs have no constructor'.
>Just because something it optimized out, it
This is not about optimizing out.
If C# structs have default constructors, then, yes, they are.
>I have to disagree, with what MSDN says, the page you are refering to is "too strong
worded,
and confusing.
<snip
Structs cannot contain explicit parameterless constructors
I would agree when there was written, "C# Structs cannot contain...". Structs is too
broad a
term here, see later for a sample that proves that structs (aka value types) can have
"explicit parameterless constructors" .
Do you mean that basic value types are structs? I think that's a case
where C# says they are structs, but you know deep down inside, they
are not anything but a memory address. That's how digging down can
lead you to the wrong conclusion about the high level language.
>To illustrate my point consider following sample written in ILasm (just another (low
level)
language on the platform) which allows you to declare a parameterless constructor.
//compile: ilasm /out:mystruct.dll /dll mystruct.il
.assembly extern mscorlib {}
.assembly mystruct{}
.class public sequential ansi sealed beforefieldinit S
extends [mscorlib]System.ValueType
{
.field public int32 ii
.field public int64 l
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
ldarg.0
ldc.i4.2 // store 2 in field l
conv.i8
stfld int64 S::l
ret
}
}
Do yourself a favor, and compile it and look at the IL using ildasm, you'll notice the
parameterless constructor .ctor (which is not emitted by C# for structs).
Yes, I know, I trust you, I don't need to compile this. I know that IL
makes a parameterless constructor which C# does not 'emit' into IL
code. I know this.
What I am saying is that doesn't matter. It matters no more than the
function call that was optimized out of existance,
There is no function call optimized away, see later.
so it doesn't
appear in IL. You'd never say that function didn't exist. The IL
doesn't have to match C#. As long as it does what actual, non-
optimized, stupidly created IL could would do based precisely on the
C# syntax, it's ok. Speed is an issue, so basic types do not call
constructors, just as they don't in C++. It doesn't mean they are not
conceptually there at the *high level language*.
You are wrong by comparing managed code to native C++, the object model is too different.
>Now let's try to use this value type from C# (or from VB or C++/CLI whatever):
// comile: csc /r:mystruct.dll thisfile.cs
class Program
{
static void Main()
{
S ms = new S();
Console.WriteLine("{0} - {1}", ms.ii, ms.l);
}
}
this will output 0 - 2, you see that C# supports calling parameterless constructors, only
that it doesn't allow to produce one, and that's what I'm trying to say since days now.
I don't think this is a fair call. You're creating non-C# code. Yes,
I agree that C# doesn't let you make parameterless constructor.
Conceptually, this is because the optimizied IL code doesn't call one,
No , the C# compiler doesn't create the IL for a constructor method, AND (obviously) does
not create a call to this constructor, but this is not about optimizing away the call.
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)
and couldn't possibly call your own in a decent enough way that the
designers could guarantee it be called, so the language denies your
right. I could make assembly code do anything, and call it from a
high level language, but that really says nothing about the high level
language. I could make C# call a function that does things beyond
what the language allows, but it doesn't mean C# 'knows' about this.
You're stepping out of bounds.
Again, your position is totally about the IL code generated.
But , there is no IL produced by the C# compiler that possibly could be called a "default
constructor". see above.
And that's exactly my point about why msdn is wrong.
Look at the ECMA specs for C++/CLI which produces the exact same IL as C#, the spec says:
[...value classes do not support user-defined destructors, finalizers, default constructors,
....],
value classes are the same a structs in C#, here is said no ... default constructors...but
not because there is already such "thing".
If you
think whatever IL code is generated IS what C# IS, then you're taking
a side that's impossible to argue against, because I'm talking about
C#, not the IL code.
I'm talking about what a C# compiler produces, the C# language itself as no
notion/definition of "default constructor", this is something that is emitted by the
compiler. So what makes you think I'm not talking about C#?
It is pointless to continue if this is the
position you hold, which I believe you've clearly shown. I don't
follow that logic, since the IL code can be vastly different. Ffor
instance, what do you say about C# static classes when looking at IL
code?
What have static class to do with this discussion?
Shouldn't you also hold C# to what the IL code is generated in
those cases, as well? It seems illogical to me, since you have to
pick and choose when you want to follow that stance or not. In terms
of default struct constructors existing, every piece fits. IL code is
out of bounds. If you pick that, why can't I go one step further and
start talking assembly, and say C# only supports JMP and CALL
instructions for program flow? I can't. It's out of bounds.
Who's talking about machine code? machine code is what gets executed by the processors, IL
is not, IL is byte code, it's the source code for the VM (the JIT), everything in .NET
translates into IL.
Note however, that the sample I showed you is not IL, it's a higher level language which is
called "ILAsm", which compiler produces IL just like all other compilers who target the CLR.
Note that could have produced the exact same value type using C#!
Anyway, I have not the intention to continue this discussion, so we'll have to agree to
disagree.
Willy.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
WHERE is he? if there is one you should be able to show me one.
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Now, we both know that isn't calling a constructor in IL - but from a
C# point of view, it is. It's calling the implicit parameterless
constructor which sets all the fields to 0/null/etc.
But , there is no IL produced by the C# compiler that possibly could be called a "default
constructor". see above.
Where does it say that the C# compiler *produces* a default
constructor? It just says that there is an *implicit* parameterless
constructor. And value types behave *from a C# point of view* exactly
*as if* they had a parameterless constructor in the IL.
The IL itself is outside the scope of the C# spec - the C# spec only
talks about what is allowed within C# and what will happen when the
produced code is executed. There's nothing to say that a C# compiler
has to produce IL at all.
And that's exactly my point about why msdn is wrong.
Note that it's not just MSDN - it's the ECMA C# spec itself that claims
that value types have an implicit parameterless constructor.
Look at the ECMA specs for C++/CLI which produces the exact same IL
as C#, the spec says: [...value classes do not support user-defined
destructors, finalizers, default constructors, ...], value classes
are the same a structs in C#, here is said no ... default
constructors...but not because there is already such "thing".
Do you treat ECMA specs as authoritative or not? If so, then the C#
spec is quite clear. If not, quoting a different one doesn't prove
anything.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
WHERE is he? if there is one you should be able to show me one.
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Here you show a "constructor" call, not the actual constructor. What the C# compiler does
here is, emit IL (a load and a store) to set the evaluation stack slot, reserved for the int
to 0 (possibly optimized away by the JIT), now do you call this IL a "constructor", a
"default constructor "or a "conceptual" constructor or what? This is what I call an
initializer and there is always one produced (or through IL or by the JIT depending on the
'initlocals' flag).
What I call a "constructor" is what I've showed with the ILAsm sample, here the compiler
emit's MSIL and injects a .ctor method in the type's method table, you can see this .ctor
entry at run-time using windbg with sos.dll.
>
Now, we both know that isn't calling a constructor in IL - but from a
C# point of view, it is. It's calling the implicit parameterless
constructor which sets all the fields to 0/null/etc.
Conceptually it looks like a constructor, but actually it isn't one
>
>But , there is no IL produced by the C# compiler that possibly could be called a "default
constructor". see above.
Where does it say that the C# compiler *produces* a default
constructor? It just says that there is an *implicit* parameterless
constructor. And value types behave *from a C# point of view* exactly
*as if* they had a parameterless constructor in the IL.
The C# reference < http://msdn2.microsoft.com/en-us/lib...ft(vs.80).aspx says:
<snip
Each struct already has a default constructor that initializes the object to zero.
Therefore, the constructors that you can create for a struct must take one or more
parameters.
>
My question is where does this "default constructor " comes from?
You know perfectly well that the *thing* that "initializes the object to zero" is the JIT
compiler, who see the "initlocals" attribute in the method metadata (set by the C#
compiler), and generates native code to set all "locals" stack locations to zero. For an
embedded struct (value type) it doesn't do anything specific.
The IL itself is outside the scope of the C# spec - the C# spec only
talks about what is allowed within C# and what will happen when the
produced code is executed. There's nothing to say that a C# compiler
has to produce IL at all.
That's not my point. My point is that C# says:
1 That there is a "default constructor", and this is what I consider outside the scope of
the spec, this is an implementation detail, and it's exactly this detail which I'm fighting.
2 That this is the reason why a user defined parameterless constructor is not allowed, which
is not the real reason.
>And that's exactly my point about why msdn is wrong.
Note that it's not just MSDN - it's the ECMA C# spec itself that claims
that value types have an implicit parameterless constructor.
MSDN and ECMA have the same source, I can show you paragraphs which are identical, only
thing is that ECMA is a bit cleaned up, both are written by the same technical writers, I
don't tell you secrets I assume.
>Look at the ECMA specs for C++/CLI which produces the exact same IL
as C#, the spec says: [...value classes do not support user-defined
destructors, finalizers, default constructors, ...], value classes
are the same a structs in C#, here is said no ... default
constructors...but not because there is already such "thing".
Do you treat ECMA specs as authoritative or not? If so, then the C#
spec is quite clear. If not, quoting a different one doesn't prove
anything.
Yes I do, and I didn't say ECMA (or MSDN) wasn't clear, I said it was "inacurate" and
"inconsistent" across different ECMA documents depending on the language.
Therefore, I prefer what is said in the C++/CLI ECMA spec.:
[...value classes do not support user-defined destructors, finalizers, default
constructors,...], see - no default constructors supported- , however they don't say that's
it's because value classes already have such thing.
ECMA 372 (C++/CLI) is written long after ECMA-334, and by other people, and that's why I
said 334 shows it's age.
I also prefer the way (syntactically) you declare value types in C++/CLI, no big deal,
different languages different syntax, I can live with that. (I live in a country who has
three official languages, I speak all three of them, so, it's part of my culture).
Her is what I mean.
public value struct S
{
public: int i;
}
....
S s;
s.i = 123;
....
constrast this with C#
public struct S
{
public int i;
}
...
S s; // valid, this emits the "initobj", here the object is guaranteed to be
initialized.
s.i = 123; // this is not accepted, the compiler barfs.
s = new S(); // this is needed to please the compiler, but doesn't produce any MSIL.
s.i = 123;
Willy.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Here you show a "constructor" call, not the actual constructor. What
the C# compiler does here is, emit IL (a load and a store) to set the
evaluation stack slot, reserved for the int to 0 (possibly optimized
away by the JIT), now do you call this IL a "constructor", a "default
constructor "or a "conceptual" constructor or what? This is what I
call an initializer and there is always one produced (or through IL
or by the JIT depending on the 'initlocals' flag).
What the C# compiler does is irrelevant to what kind of C# expression
is involved here.
Everyone agrees that in IL there is no parameterless constructor.
That's not the same thing as there not being a parameterless
constructor at the C# level of looking at things.
What I call a "constructor" is what I've showed with the ILAsm
sample, here the compiler emit's MSIL and injects a .ctor method in
the type's method table, you can see this .ctor entry at run-time
using windbg with sos.dll.
Then you're talking in CLI terms, not C# terms. It's vital to
distinguish between the two.
Now, we both know that isn't calling a constructor in IL - but from a
C# point of view, it is. It's calling the implicit parameterless
constructor which sets all the fields to 0/null/etc.
Conceptually it looks like a constructor, but actually it isn't one
At the IL level, which isn't what the C# spec describes.
But , there is no IL produced by the C# compiler that possibly
could be called a "default constructor". see above.
Where does it say that the C# compiler *produces* a default
constructor? It just says that there is an *implicit* parameterless
constructor. And value types behave *from a C# point of view* exactly
*as if* they had a parameterless constructor in the IL.
The C# reference <http://msdn2.microsoft.com/en-us/lib...ft(vs.80).aspx says:
<snip
Each struct already has a default constructor that initializes the object to zero.
Therefore, the constructors that you can create for a struct must take one or more
parameters.
My question is where does this "default constructor " comes from?
It's of no interest to me (in this discussion) how the C# compiler
achieves the effect of implementing the C# spec. The important thing is
what the spec states, which is that there is a parameterless
constructor.
You know perfectly well that the *thing* that "initializes the object
to zero" is the JIT compiler, who see the "initlocals" attribute in
the method metadata (set by the C# compiler), and generates native
code to set all "locals" stack locations to zero. For an embedded
struct (value type) it doesn't do anything specific.
Agreed, but irrelevant.
The IL itself is outside the scope of the C# spec - the C# spec only
talks about what is allowed within C# and what will happen when the
produced code is executed. There's nothing to say that a C# compiler
has to produce IL at all.
That's not my point. My point is that C# says:
1 That there is a "default constructor", and this is what I consider
outside the scope of the spec, this is an implementation detail, and
it's exactly this detail which I'm fighting.
There *is* a default constructor from the point of view of what you can
do in C#. The semantics are consistent with there being a default
constructor. If the CLI were different, and the C# compiler *did* have
to generate a parameterless constructor, C# as a language wouldn't have
to change.
2 That this is the reason why a user defined parameterless
constructor is not allowed, which is not the real reason.
Well, that can be the reason from the C# spec's point of view. It would
prohibit a parameterless constructor being declared even when
targetting a platform where such a constructor would be feasible, make
sense etc.
And that's exactly my point about why msdn is wrong.
Note that it's not just MSDN - it's the ECMA C# spec itself that claims
that value types have an implicit parameterless constructor.
MSDN and ECMA have the same source, I can show you paragraphs which
are identical, only thing is that ECMA is a bit cleaned up, both are
written by the same technical writers, I don't tell you secrets I
assume.
Of course not. A compiler error isn't the same as the spec, of course -
but I see that the spec does in fact contain the same kind of logic.
Do you treat ECMA specs as authoritative or not? If so, then the C#
spec is quite clear. If not, quoting a different one doesn't prove
anything.
Yes I do, and I didn't say ECMA (or MSDN) wasn't clear, I said it was
"inacurate" and "inconsistent" across different ECMA documents
depending on the language.
Inconsistent I would certainly agree with, although I don't think
consistency between documents which are describing things is always
necessary. Preferable, generally, but not absolutely necessary.
Inaccurate I find harder to swallow. The C# spec is defining the
behaviour of a C# program, and I don't see any inaccuracy in there.
Therefore, I prefer what is said in the C++/CLI ECMA spec.: [...value
classes do not support user-defined destructors, finalizers, default
constructors,...], see - no default constructors supported- , however
they don't say that's it's because value classes already have such
thing. ECMA 372 (C++/CLI) is written long after ECMA-334, and by
other people, and that's why I said 334 shows it's age.
It's fine to prefer one spec to another, but I don't see that it makes
the C# spec inaccurate in defining the C# language, which is all the C#
spec is meant to do.
I also prefer the way (syntactically) you declare value types in C++/CLI, no big deal,
different languages different syntax, I can live with that. (I live in a country who has
three official languages, I speak all three of them, so, it's part of my culture).
Her is what I mean.
public value struct S
{
public: int i;
}
...
S s;
s.i = 123;
...
constrast this with C#
public struct S
{
public int i;
}
..
S s; // valid, this emits the "initobj", here the object is guaranteed to be
initialized.
s.i = 123; // this is not accepted, the compiler barfs.
s = new S(); // this is needed to please the compiler, but doesn't produce any MSIL.
s.i = 123;
Um, no, that's not required. Try compiling this:
public struct Foo
{
public int i;
}
class Test
{
static void Main()
{
Foo f;
f.i = 123;
}
}
That compiles with no warnings at all.
What you can't do is *read* a field until all fields have definitely
been assigned a value - and I agree, that's slightly silly given that
they will all have been definitely assigned a value of 0. Under the
CLI, that is - which isn't what the C# spec explicitly targets.
That's a difference between the C# spec and the C++/CLI spec - the
C++/CLI spec can make assumptions based on the CLI behaviour, whereas
the C# spec tries to stay at least slightly agnostic.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Here you show a "constructor" call, not the actual constructor. What
the C# compiler does here is, emit IL (a load and a store) to set the
evaluation stack slot, reserved for the int to 0 (possibly optimized
away by the JIT), now do you call this IL a "constructor", a "default
constructor "or a "conceptual" constructor or what? This is what I
call an initializer and there is always one produced (or through IL
or by the JIT depending on the 'initlocals' flag).
What the C# compiler does is irrelevant to what kind of C# expression
is involved here.
Everyone agrees that in IL there is no parameterless constructor.
That's not the same thing as there not being a parameterless
constructor at the C# level of looking at things.
>What I call a "constructor" is what I've showed with the ILAsm
sample, here the compiler emit's MSIL and injects a .ctor method in
the type's method table, you can see this .ctor entry at run-time
using windbg with sos.dll.
Then you're talking in CLI terms, not C# terms. It's vital to
distinguish between the two.
Now, we both know that isn't calling a constructor in IL - but from a
C# point of view, it is. It's calling the implicit parameterless
constructor which sets all the fields to 0/null/etc.
Conceptually it looks like a constructor, but actually it isn't one
At the IL level, which isn't what the C# spec describes.
>But , there is no IL produced by the C# compiler that possibly
could be called a "default constructor". see above.
Where does it say that the C# compiler *produces* a default
constructor? It just says that there is an *implicit* parameterless
constructor. And value types behave *from a C# point of view* exactly
*as if* they had a parameterless constructor in the IL.
The C# reference <http://msdn2.microsoft.com/en-us/lib...ft(vs.80).aspx says:
<snip
Each struct already has a default constructor that initializes the object to zero.
Therefore, the constructors that you can create for a struct must take one or more
parameters.
My question is where does this "default constructor " comes from?
It's of no interest to me (in this discussion) how the C# compiler
achieves the effect of implementing the C# spec. The important thing is
what the spec states, which is that there is a parameterless
constructor.
>You know perfectly well that the *thing* that "initializes the object
to zero" is the JIT compiler, who see the "initlocals" attribute in
the method metadata (set by the C# compiler), and generates native
code to set all "locals" stack locations to zero. For an embedded
struct (value type) it doesn't do anything specific.
Agreed, but irrelevant.
The IL itself is outside the scope of the C# spec - the C# spec only
talks about what is allowed within C# and what will happen when the
produced code is executed. There's nothing to say that a C# compiler
has to produce IL at all.
That's not my point. My point is that C# says:
>1 That there is a "default constructor", and this is what I consider
outside the scope of the spec, this is an implementation detail, and
it's exactly this detail which I'm fighting.
There *is* a default constructor from the point of view of what you can
do in C#. The semantics are consistent with there being a default
constructor. If the CLI were different, and the C# compiler *did* have
to generate a parameterless constructor, C# as a language wouldn't have
to change.
>2 That this is the reason why a user defined parameterless
constructor is not allowed, which is not the real reason.
Well, that can be the reason from the C# spec's point of view. It would
prohibit a parameterless constructor being declared even when
targetting a platform where such a constructor would be feasible, make
sense etc.
>And that's exactly my point about why msdn is wrong.
Note that it's not just MSDN - it's the ECMA C# spec itself that claims
that value types have an implicit parameterless constructor.
MSDN and ECMA have the same source, I can show you paragraphs which
are identical, only thing is that ECMA is a bit cleaned up, both are
written by the same technical writers, I don't tell you secrets I
assume.
Of course not. A compiler error isn't the same as the spec, of course -
but I see that the spec does in fact contain the same kind of logic.
Do you treat ECMA specs as authoritative or not? If so, then the C#
spec is quite clear. If not, quoting a different one doesn't prove
anything.
Yes I do, and I didn't say ECMA (or MSDN) wasn't clear, I said it was
"inacurate" and "inconsistent" across different ECMA documents
depending on the language.
Inconsistent I would certainly agree with, although I don't think
consistency between documents which are describing things is always
necessary. Preferable, generally, but not absolutely necessary.
Inaccurate I find harder to swallow. The C# spec is defining the
behaviour of a C# program, and I don't see any inaccuracy in there.
It does'nt actually decribes behaviour, it goes into some detail which is inaccurate. As I
said, they should have used a different terminology instead of talking about something,
called a *constructor*, that has wel defined semantics on the CLI/CLR.
This from ECMA-334:
<All value types implicitly declare a public parameterless instance constructor called the
default constructor.
The default constructor returns a zero-initialized instance known as the default value for
the value type:..>
see: "implicitly ", "instance constructor", "default constructor" and "returns" a
zero-initialized instance, and this is what I call inaccurate and confusing. Many developers
I met have been confused by terms like above, finally, I explained that they should forget
about this "default constructor" that "returns" an instance of a value type, what they
should know is that they have an zero initialized instance available at the point of
declaration.
>Therefore, I prefer what is said in the C++/CLI ECMA spec.: [...value
classes do not support user-defined destructors, finalizers, default
constructors,...], see - no default constructors supported- , however
they don't say that's it's because value classes already have such
thing. ECMA 372 (C++/CLI) is written long after ECMA-334, and by
other people, and that's why I said 334 shows it's age.
It's fine to prefer one spec to another, but I don't see that it makes
the C# spec inaccurate in defining the C# language, which is all the C#
spec is meant to do.
>I also prefer the way (syntactically) you declare value types in C++/CLI, no big deal,
different languages different syntax, I can live with that. (I live in a country who has
three official languages, I speak all three of them, so, it's part of my culture).
Her is what I mean.
public value struct S
{
public: int i;
}
...
S s;
s.i = 123;
...
constrast this with C#
public struct S
{
public int i;
}
..
S s; // valid, this emits the "initobj", here the object is guaranteed to be
initialized.
s.i = 123; // this is not accepted, the compiler barfs.
s = new S(); // this is needed to please the compiler, but doesn't produce any MSIL.
s.i = 123;
Um, no, that's not required. Try compiling this:
public struct Foo
{
public int i;
}
class Test
{
static void Main()
{
Foo f;
f.i = 123;
}
}
That compiles with no warnings at all.
Sorry, that's what I meant to show.
In C++/CLI you can do:
..
S s;
int v = s.i ;
..
which is not posible in C#.
on the other hand, this in C++/CLI....
...
S s = gcnew S();
creates a boxed instance of S! And again this confuses those who use both (or more)
languages. I know abouth this because in my daily job I have to consult people using VB, C#
and C++ in any combination, this is not a "single language" world as you probably know Jon.
What you can't do is *read* a field until all fields have definitely
been assigned a value - and I agree, that's slightly silly given that
they will all have been definitely assigned a value of 0. Under the
CLI, that is - which isn't what the C# spec explicitly targets.
That's a difference between the C# spec and the C++/CLI spec - the
C++/CLI spec can make assumptions based on the CLI behaviour, whereas
the C# spec tries to stay at least slightly agnostic.
True, this was not such a problem when C# was the only (ignoring VB.NET as it's not an ECMA
standard) in the game. However, things have changed, and the C++/CLI tech. writers *did
read* the ECMA-334 and considered this all as confusing and, IMO incorrect because they
opted for a different text and I don't see where they are less *agnostic*.
Willy.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
<snip>
True, this was not such a problem when C# was the only (ignoring
VB.NET as it's not an ECMA standard) in the game. However, things
have changed, and the C++/CLI tech. writers *did read* the ECMA-334
and considered this all as confusing and, IMO incorrect because they
opted for a different text and I don't see where they are less
*agnostic*.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
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.
You're stepping out of bounds.
Again, your position is totally about the IL code generated.
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
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
WHERE is he? if there is one you should be able to show me one.
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Here you show a "constructor" call, not the actual constructor. What the C# compiler does
here is, emit IL (a load and a store) to set the evaluation stack slot, reserved for the int
to 0 (possibly optimized away by the JIT), now do you call this IL a "constructor", a
"default constructor "or a "conceptual" constructor or what?
The CIL code is assembly like code that does precisely the end effect
required by the C# code that was used to make it, so that the virtual
machine can change it into assembly language on the ending platform so
that this assembly code can also produce the end result that fits
precisely what the C# code desired.
I call the CIL code CIL code.
I call the assembly code assembly code.
I call the C# code a constructor, because that's what it is.
Conceptually it looks like a constructor, but actually it isn't one
Then, C# had no structs, classes, methods, variables, references,
switch statements, if/then/else statements, for loops, or anything,
because the resulting assembly language has none of that stuff. And,
no, you can't argue, because I have proof. I used a disassembler and
looked at it. No matter what you say, I'll disassemble the final
assembly and show you direct evidence that none of those C# concepts
exist in the final assembly, so while you may enjoy calling them by
their common names, I know the truth that they actually don't exist.
They *actually*, in reality, don't exist, because the *actual* code
the CPU is running has none of it. Case closed.
Seem a bit foolish?
Yeah, I would say.
The C# reference <http://msdn2.microsoft.com/en-us/library/x2xcf8ft(vs.80).aspxsays:
<snip
Each struct already has a default constructor that initializes the object to zero.
Therefore, the constructors that you can create for a struct must take one or more
parameters.
My question is where does this "default constructor " comes from?
The C# designers.
You know perfectly well that the *thing* that "initializes the object to zero" is the JIT
compiler, who see the "initlocals" attribute in the method metadata (set by the C#
compiler), and generates native code to set all "locals" stack locations to zero. For an
embedded struct (value type) it doesn't do anything specific.
No, actually, it's the MOV EAX, 0 or XOR EAX,EAX instruction. That's
what sets it to zero. I fail to see how this is relevant?
Zytan
"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@n33g2000cwc.googlegr oups.com...
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
>WHERE is he? if there is one you should be able to show me one.
Sure - I can show it, by calling it, but *only* in C#. Just because it
exists as far as C# is concerned doesn't mean it has to exist in IL.
Here's the code:
int i = new int();
Here you show a "constructor" call, not the actual constructor. What the C# compiler does
here is, emit IL (a load and a store) to set the evaluation stack slot, reserved for the
int
to 0 (possibly optimized away by the JIT), now do you call this IL a "constructor", a
"default constructor "or a "conceptual" constructor or what?
The CIL code is assembly like code that does precisely the end effect
required by the C# code that was used to make it, so that the virtual
machine can change it into assembly language on the ending platform so
that this assembly code can also produce the end result that fits
precisely what the C# code desired.
This doesn't answer my question.
I call the CIL code CIL code.
I call the assembly code assembly code.
I call the C# code a constructor, because that's what it is.
>Conceptually it looks like a constructor, but actually it isn't one
Then, C# had no structs, classes, methods, variables, references,
switch statements, if/then/else statements, for loops, or anything,
Did I ever say that?
because the resulting assembly language has none of that stuff. And,
no, you can't argue, because I have proof. I used a disassembler and
looked at it.
Looked at what using what?
No matter what you say, I'll disassemble the final
assembly and show you direct evidence that none of those C# concepts
exist in the final assembly,
What concepts are you talking about?? Structs, classes, etc. These C# concepts are mapped
into structured data available at run-time and visible using the right tools. Just like you
can show the assembly representation of a machine instruction using a debugger
(dissasemble), there are tools to show these concepts as they are layd-out in memory,
classes, structs, types etc.. are represented by well defined CLR data structures.
so while you may enjoy calling them by
their common names, I know the truth that they actually don't exist.
I can show you they do exist, look following is the output of a debugger command at
run-time!!
Here I dump the object instance at memory location 0000000002f41be0 (64 bit OS object on the
GC heap.)
0:000!do 0000000002f41be0
Name: System.Text.StringBuilder
MethodTable: 000006427881fc00
EEClass: 0000064278934298
Size: 40(0x28) bytes
(C:\Windows\assembly\GAC_64\mscorlib\2.0.0.0__b77a 5c561934e089\mscorlib.dll)
Fields:
MT Field Offset Type VT Attr Value Name
000006427882b808 40000b1 10 System.IntPtr 0 instance 0
m_currentThread
000006427882b328 40000b2 18 System.Int32 0 instance 2147483647
m_MaxCapacity
000006427881edb8 40000b3 8 System.String 0 instance 0000000002f41d48
m_StringValue
see the object represents a StringBuilder
And here: Dump the method table
0:000!dumpmt 000006427882b808
EEClass: 000006427893ec58
Module: 00000642787a2000
Name: System.IntPtr
mdToken: 020000c3
(C:\Windows\assembly\GAC_64\mscorlib\2.0.0.0__b77a 5c561934e089\mscorlib.dll)
BaseSize: 0x18
ComponentSize: 0x0
Number of IFaces in IFaceMap: 1
Slots in VTable: 27
You want to see the assembly for each individual method, I can show you, do you want to see
the corresponding IL? I can show you.
Want to see the GC heap, here is aprtly dump...
Number of GC Heaps: 1
generation 0 starts at 0x0000000002f41030
generation 1 starts at 0x0000000002f41018
generation 2 starts at 0x0000000002f41000
They *actually*, in reality, don't exist, because the *actual* code
the CPU is running has none of it. Case closed.
Seem a bit foolish?
No you simply showed your complete ignorance.
Yeah, I would say.
>The C# reference <http://msdn2.microsoft.com/en-us/library/x2xcf8ft(vs.80).aspxsays:
<snip
Each struct already has a default constructor that initializes the object to zero.
Therefore, the constructors that you can create for a struct must take one or more
parameters.
My question is where does this "default constructor " comes from?
The C# designers.
Funny.
>
>You know perfectly well that the *thing* that "initializes the object to zero" is the JIT
compiler, who see the "initlocals" attribute in the method metadata (set by the C#
compiler), and generates native code to set all "locals" stack locations to zero. For an
embedded struct (value type) it doesn't do anything specific.
No, actually, it's the MOV EAX, 0 or XOR EAX,EAX instruction. That's
what sets it to zero. I fail to see how this is relevant?
Not exactly, these instructions zero out register eax, not a stack location, if you go down
that low level you have to be more precise.
As I said before the JIT produces code to effectively clear the *total stack area* reserved
for all locals in the frame, irrespective the type or the number of the locals, he doesn't
zero out individual "local variable" locations; he resets stack slots.
And what's more important, this happens at method entry, NOT at the point of declaration nor
at the point of the eventual constructor calls.
Say you have a method with two locals, one of type long another of type S (we are talking
about struct aren't we?):
public struct S
{
int i;
byte b;
short s;
}
void Foo {
S s;
long l;
...
}
The JIT knows (with the help of the metadata and lay-out manager) that he needs to "clear"
4 slots of stack (each 32 bit on 32 bit OS).
2 slots for the struct S and 2 slots for the long.
On 64 bit he needs to clear two slots (64 bit on 64 bit OS), one for S and one for l.
What instruction sequence the JIT produces, depends on the OS, the JIT type, the CPU
hardware (x86, X64 and IIA64) and whether JIT optimizations are enabled or not.
On 32 bit (using JIT32) above looks like:
xor eax,eax
mov dword ptr [ebp-14h],eax
mov dword ptr [ebp-10h],eax
mov dword ptr [ebp-18h],eax
mov dword ptr [ebp-1Ch],eax
.... rest of method....
but it may also look like:
pxor xmm0,xmm0
movq mmword ptr [ebp-10h],xmm0
movq mmword ptr [ebp-18h],xmm0
- See XMM SSE instructions used.
On 64 bit (using JIT64) it looks like:
xor rax,rax
mov qword ptr [rsp-18h],rax
mov qword ptr [rsp-10h],rax
- see only two mov instructions needed (reg's are 64 bit).
Note, that I'm no longer going to reply to your posts in this thread, I've spend more than
enough time on this.
Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
<snip>
>True, this was not such a problem when C# was the only (ignoring
VB.NET as it's not an ECMA standard) in the game. However, things
have changed, and the C++/CLI tech. writers *did read* the ECMA-334
and considered this all as confusing and, IMO incorrect because they
opted for a different text and I don't see where they are less
*agnostic*.
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.
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@8g2000cwh.googlegroup s.com...
Yes, IL has no constructor call. I know. You've proven that.
This does not mean C# doesn't have a constructor there.
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.
You're stepping out of bounds.
Again, your position is totally about the IL code generated.
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/de...nguageMSIL.asp
maybe you can start reading this, I already did several years back.
Willy.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
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.
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.
>Also, note that C++/CLI produced MSIL run's on Mono as well.
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.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
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?
No - not when you look at what those references are.
"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.
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?
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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
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?
No - not when you look at what those references are.
"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.
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?
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.
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.
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?
>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.
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.
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
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.
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?
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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>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.
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?
History of is paved with mistakes I guess.
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.
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.
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.
My question is where does this "default constructor " comes from?
The C# designers.
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
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/de...ary/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
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
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@c51g2000cwc.googlegro ups.com...
>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/de...ary/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
And it's still called MSIL, it's MSFT's implementation of what is called CIL... http://blogs.msdn.com/brada/archive/...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/lib...s1(VS.80).aspx
Willy.
"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/...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/lib...s1(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_...diate_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
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...
"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/...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/lib...s1(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_...diate_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/lib...s1(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/lib...kx(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.../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.
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/lib...s1(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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter van der Goes |
last post by:
When a struct is created in C# and a parameterized constructor defined, the
IntelliSense editor shows only the syntax for the parameterized constructor
in tooltips, but not for the default...
|
by: Karl M |
last post by:
Hi everyone,
I just notice some strange behaviors on the MS C++ compiler regarding struct
default constructor, see the example bellow:
struct MyStruct
{
int a;
};
class MyClass
{
public:
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
