Structs

[Jasper Kent]

Can anyone explain the logic behind structs being allowed neither memeber
initialisers or default constructors.

Doesn't this just encourage developers to create constructors with dummy
arguments?

Thanks in advance,

Jasper Kent.

[Scott Allen]

IMO:

In C# we come to expect all value types to default to a
zero-initialized instance. So if I wrote:

static void Main(string[] args)
{
int x = new int();
Console.WriteLi ne(x);

}

and a "2" appeared in the console window, I'd wonder if I regressed to
C++ where such things can occur. The spec guarantees this won't
happen. Since a struct is also a value type, it would be just as
strange to see a "2" appear in the following:

class Class1
{
[STAThread]
static void Main(string[] args)
{
Foo f = new Foo();
Console.WriteLi ne(f.x);

}
}
struct Foo
{
public int x;
}

To preserve the correct behavior then, a struct cannot explicitly
declare a default constructor, and (as you probably noticed), you
can't use an instance field initializer either.

--
Scott
http://www.OdeToCode.com

On Fri, 30 Apr 2004 13:17:56 +0100, "Jasper Kent"
<ja*********@nt lworld.com> wrote:

Can anyone explain the logic behind structs being allowed neither memeber
initialisers or default constructors.

Doesn't this just encourage developers to create constructors with dummy
arguments?

Thanks in advance,

Jasper Kent.

[Jasper Kent]

That's kind of a bootstrap argument, and I don't buy it.

In any O-O language we excpect any type to default to a sensible value.For
exanple:

struct PositiveInteger {...}

....

PositiveInteger val = new PositiveInteger ();

Console.WriteLi ne (val.ToString ()) ; // We'd be surpsrised by zero here

And anyway, whatever the argument, why is it different for a struct and a
class?

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:6l******** *************** *********@4ax.c om...

IMO:

In C# we come to expect all value types to default to a
zero-initialized instance. So if I wrote:

static void Main(string[] args)
{
int x = new int();
Console.WriteLi ne(x);

}

and a "2" appeared in the console window, I'd wonder if I regressed to
C++ where such things can occur. The spec guarantees this won't
happen. Since a struct is also a value type, it would be just as
strange to see a "2" appear in the following:

class Class1
{
[STAThread]
static void Main(string[] args)
{
Foo f = new Foo();
Console.WriteLi ne(f.x);

}
}
struct Foo
{
public int x;
}

To preserve the correct behavior then, a struct cannot explicitly
declare a default constructor, and (as you probably noticed), you
can't use an instance field initializer either.

--
Scott
http://www.OdeToCode.com

On Fri, 30 Apr 2004 13:17:56 +0100, "Jasper Kent"
<ja*********@nt lworld.com> wrote:

Can anyone explain the logic behind structs being allowed neither memeber
initialisers or default constructors.

Doesn't this just encourage developers to create constructors with dummy
arguments?

Thanks in advance,

Jasper Kent.

[mikeb]

Jasper Kent wrote:

That's kind of a bootstrap argument, and I don't buy it.

In any O-O language we excpect any type to default to a sensible value.For
exanple:

struct PositiveInteger {...}

...

PositiveInteger val = new PositiveInteger ();

Console.WriteLi ne (val.ToString ()) ; // We'd be surpsrised by zero here

And anyway, whatever the argument, why is it different for a struct and a
class?
Here's a cut-n-paste from an entry in Stan Lippmann's weblog that I
recently read (thing1 is the first version of MC++, thing2 is the
revised version of MC++):

=============== =============== =============== =============
Another difference with a value type between thing1 and thing2 is the
removal of support for a default constructor. [It has been explained to
me that this is because there are instances in which the CLR can create
an instance of the value type without invoking the associated default
constructor. That is, the thing1 addition of support of a default
constructor within a value type cannot be guaranteed. Given that absence
of guarantee, it was felt to be better to drop the support altogether
rather than have it be non-deterministic in its application.]

This is not as bad as it might seem because each object of a value type
is zeroed out automatically, so that the members of a local instance are
not undefined. This also meant that in thing1 a default constructor that
simply zeroed out its members was being redundant. The problem is that a
non-trivial default constructor in a thing1 program has no mechanical
mapping to thing2. The code within the constructor will need to be
migrated into a named init function that would then be explicitly
invoked by the user.
=============== =============== =============== =============

You can read the full entry here:

http://blogs.msdn.com/slippman/archi.../26/80505.aspx


"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:6l******** *************** *********@4ax.c om...

IMO:

In C# we come to expect all value types to default to a
zero-initialized instance. So if I wrote:

static void Main(string[] args)
{
int x = new int();
Console.WriteLi ne(x);

}

and a "2" appeared in the console window, I'd wonder if I regressed to
C++ where such things can occur. The spec guarantees this won't
happen. Since a struct is also a value type, it would be just as
strange to see a "2" appear in the following:

class Class1
{
[STAThread]
static void Main(string[] args)
{
Foo f = new Foo();
Console.WriteLi ne(f.x);

}
}
struct Foo
{
public int x;
}

To preserve the correct behavior then, a struct cannot explicitly
declare a default constructor, and (as you probably noticed), you
can't use an instance field initializer either.

--
Scott
http://www.OdeToCode.com

On Fri, 30 Apr 2004 13:17:56 +0100, "Jasper Kent"
<ja*********@ ntlworld.com> wrote:

Can anyone explain the logic behind structs being allowed neither memeber
initialise rs or default constructors.

Doesn't this just encourage developers to create constructors with dummy
arguments?

Thanks in advance,

Jasper Kent.

--
mikeb

[cody]

> > In any O-O language we excpect any type to default to a sensible
value.For

exanple:

struct PositiveInteger {...}

PositiveInteger val = new PositiveInteger ();

Console.WriteLi ne (val.ToString ()) ; // We'd be surpsrised by zero here
And anyway, whatever the argument, why is it different for a struct and a class?

Here's a cut-n-paste from an entry in Stan Lippmann's weblog that I
recently read (thing1 is the first version of MC++, thing2 is the
revised version of MC++):

=============== =============== =============== =============
Another difference with a value type between thing1 and thing2 is the
removal of support for a default constructor. [It has been explained to
me that this is because there are instances in which the CLR can create
an instance of the value type without invoking the associated default
constructor. That is, the thing1 addition of support of a default
constructor within a value type cannot be guaranteed. Given that absence
of guarantee, it was felt to be better to drop the support altogether
rather than have it be non-deterministic in its application.]
This is not as bad as it might seem because each object of a value type
is zeroed out automatically, so that the members of a local instance are
not undefined. This also meant that in thing1 a default constructor that
simply zeroed out its members was being redundant. The problem is that a
non-trivial default constructor in a thing1 program has no mechanical
mapping to thing2. The code within the constructor will need to be
migrated into a named init function that would then be explicitly
invoked by the user.

Iam not sure what this text is trying to tell use but we can create a struct
without calling a ctor:

Point p;
p.X=100;
p.Y=120;

in this case the compiler enforces that each field is initialized before
first access.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Daniel O'Connell [C# MVP]]

"cody" <pl************ *************@g mx.de> wrote in message
news:us******** ******@TK2MSFTN GP11.phx.gbl...

> In any O-O language we excpect any type to default to a sensible value.For > exanple:
>
> struct PositiveInteger {...}
>
> PositiveInteger val = new PositiveInteger ();
>
> Console.WriteLi ne (val.ToString ()) ; // We'd be surpsrised by zero here >
> And anyway, whatever the argument, why is it different for a struct and a > class?
Here's a cut-n-paste from an entry in Stan Lippmann's weblog that I
recently read (thing1 is the first version of MC++, thing2 is the
revised version of MC++):

=============== =============== =============== =============
Another difference with a value type between thing1 and thing2 is the
removal of support for a default constructor. [It has been explained to
me that this is because there are instances in which the CLR can create
an instance of the value type without invoking the associated default
constructor. That is, the thing1 addition of support of a default
constructor within a value type cannot be guaranteed. Given that absence
of guarantee, it was felt to be better to drop the support altogether
rather than have it be non-deterministic in its application.]
This is not as bad as it might seem because each object of a value type
is zeroed out automatically, so that the members of a local instance are
not undefined. This also meant that in thing1 a default constructor that
simply zeroed out its members was being redundant. The problem is that a
non-trivial default constructor in a thing1 program has no mechanical
mapping to thing2. The code within the constructor will need to be
migrated into a named init function that would then be explicitly
invoked by the user.

Iam not sure what this text is trying to tell use but we can create a
struct
without calling a ctor:

Point p;
p.X=100;
p.Y=120;

in this case the compiler enforces that each field is initialized before
first access.

Thats actually the point of the text. Structs don't support default
constructors, but instead are created zero'd out. If the compiler decides to
mantain flow information and ensure that you set all variables, thats good
and helpful, but its not strictly nessecery, IIRC.
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[mikeb]

cody wrote:

In any O-O language we excpect any type to default to a sensible
value.For
exanple:

struct PositiveInteger {...}

PositiveInte ger val = new PositiveInteger ();

Console.Writ eLine (val.ToString ()) ; // We'd be surpsrised by zero
here
And anyway, whatever the argument, why is it different for a struct and
a
class?

Here's a cut-n-paste from an entry in Stan Lippmann's weblog that I
recently read (thing1 is the first version of MC++, thing2 is the
revised version of MC++):

============= =============== =============== ===============
Another difference with a value type between thing1 and thing2 is the
removal of support for a default constructor. [It has been explained to
me that this is because there are instances in which the CLR can create
an instance of the value type without invoking the associated default
constructor . That is, the thing1 addition of support of a default
constructor within a value type cannot be guaranteed. Given that absence
of guarantee, it was felt to be better to drop the support altogether
rather than have it be non-deterministic in its application.]
This is not as bad as it might seem because each object of a value type
is zeroed out automatically, so that the members of a local instance are
not undefined. This also meant that in thing1 a default constructor that
simply zeroed out its members was being redundant. The problem is that a
non-trivial default constructor in a thing1 program has no mechanical
mapping to thing2. The code within the constructor will need to be
migrated into a named init function that would then be explicitly
invoked by the user.

Iam not sure what this text is trying to tell use but we can create a struct
without calling a ctor:

Point p;
p.X=100;
p.Y=120;

in this case the compiler enforces that each field is initialized before
first access.

I'm not an very familiar with MC++, but apparently in the current
version it supports specifying a default constructor for value types.
Here's a line taken from the docs on MC++ __value classes:

-----------------------------------
If no default constructor is defined for a __value class, all of its
data members are initialized to zero by default.
-----------------------------------

I believe that Stan is saying in his weblog is that they are removing
support for default constructors on __value classes in MC++ for the
reason he stated (if you have a copy of Whidbey, you could look there to
verify this - I'm even less familiar with MC++ on Whidbey).

Now, why the CLR might not invoke a default constructor for a value type
is another question. I assume it's because the CLR folks didn't see
it as an important feature (Stan mentions that "this is not as bad as it
seems...") and to allow some optimizations, but I'm just guessing.

--
mikeb

[cody]

> > Iam not sure what this text is trying to tell use but we can create a

struct
without calling a ctor:

Point p;
p.X=100;
p.Y=120;

in this case the compiler enforces that each field is initialized before
first access.
Thats actually the point of the text. Structs don't support default
constructors, but instead are created zero'd out. If the compiler decides

to mantain flow information and ensure that you set all variables, thats good
and helpful, but its not strictly nessecery, IIRC.

I don't believe that fields are zeroed out automatically if you don't call
the ctor.
If so, the line

Point p = new Point();

would zero out all fields twice.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Daniel O'Connell [C# MVP]]

"cody" <pl************ *************@g mx.de> wrote in message
news:%2******** *******@TK2MSFT NGP10.phx.gbl.. .

I don't believe that fields are zeroed out automatically if you don't call
the ctor.
If so, the line

Point p = new Point();

would zero out all fields twice.
A struct is created, generally, in null memory. I'm pretty sure the .NET
memory model ensures that a variable created on the stack retains a zero
value, even if its unassigned. I could be wrong but it would seem unlikely.

The difference in
Point p;

and
Point p = new Point();

is new Point() issues an initobj instruction in IL. That initobj instruction
should zero memory in most case(structs written in other languages may not
zero, AFAICT), however the original structure on the stack should already be
zeroed(someone correct me if I am wrong, I'm pretty sure I'm not though).
Your example does indeed zero twice: once explicitly(duri ng new Point()) and
once implicitly at stack construction. In that case I would expect the JIT
to effectivly remove the initobj instruction whenever it knows that the
initalization is pointless. new Point() would be more valuable when the
value in p has been used. It would clear that value back out.

As a matter of technical fact, I don't believe that its required to init a
struct before use. C# tends to disallow it, however, under assignment
rules(I've run into one situation where it seems to be allowed, which I have
to check on). I think that is more for the purposes of correct, well though
out code more so than it is a problem with the underlying platform.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[cody]

> A struct is created, generally, in null memory. I'm pretty sure the .NET

memory model ensures that a variable created on the stack retains a zero
value, even if its unassigned. I could be wrong but it would seem unlikely.

No. Locals and structs are created on the stack which does *not* contain
zeros, but instead data of previous method invocations.
If a method returns it would have to overwrite the stack with zeros to clean
up, if you want the behavour that every struct is generated in "null
memory".

C# forces you to initialize *every* local variable completely before first
use. In the case of structs a ctor call is not needed if you assign all
fields manually.
The difference in
Point p;

and
Point p = new Point();

is new Point() issues an initobj instruction in IL. That initobj instruction should zero memory in most case(structs written in other languages may not
zero, AFAICT), however the original structure on the stack should already be zeroed(someone correct me if I am wrong, I'm pretty sure I'm not though).
Your example does indeed zero twice: once explicitly(duri ng new Point()) and once implicitly at stack construction. In that case I would expect the JIT
to effectivly remove the initobj instruction whenever it knows that the
initalization is pointless. new Point() would be more valuable when the
value in p has been used. It would clear that value back out.
Think: Would the initobj call would make sense in any circumstance when
structs would already zeroed out a creation time?
As a matter of technical fact, I don't believe that its required to init a
struct before use. C# tends to disallow it, however, under assignment
rules(I've run into one situation where it seems to be allowed, which I have to check on). I think that is more for the purposes of correct, well though out code more so than it is a problem with the underlying platform.

Which situation? I'd like to hear.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk