Rationale for C++/CLI Value Types not having a default constructor

[Edward Diener]

Given

value class X
{
public:
// Not allowed: X():i(100000),s (10000) { }
// Allowed
void InitializeDefau lts() { i = 100000; s = 10000; }
private:
int i;
short s;
}

How can:

1)

X x;
x.InitializeDef aults();

be better semantically than

2)

X x;

for setting the default values of 100000 for i and 10000 for s ? In
other words what is the rationale for removing the natural user-defined
default constructor for value types and forcing the user to default
construct the value type object to its zero or null values and then have
to call another function to set default values which the type may want ?
I read that 2) can not be guaranteed to occur properly but 1) evidently
can ? Someone please explain to me how a sequence of two syntax actions
has a better guarantee of properly being implemented than just one.

[Bruno van Dooren]

for setting the default values of 100000 for i and 10000 for s ? In
other words what is the rationale for removing the natural user-defined
default constructor for value types and forcing the user to default
construct the value type object to its zero or null values and then have
to call another function to set default values which the type may want ?

<from http://www.codecomment s.com/archive292-2006-2-806923.html>

If you also look in "C++-CLI Standard.pdf", you read :

12.2.1 Value classes
A value class is a data structure that contains fields, function members,
and nested types. Unlike other class
types, value classes do not support user-defined destructors, finalizers,
default constructors, copy
constructors, or copy assignment operators. Value classes are designed to
allow the CLI execution engine to
efficiently copy value class objects.

--

Kind regards,
Bruno van Dooren
br************* *********@hotma il.com
Remove only "_nos_pam"

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

Given

value class X
{
public:
// Not allowed: X():i(100000),s (10000) { }
// Allowed
void InitializeDefau lts() { i = 100000; s = 10000; }
private:
int i;
short s;
}

How can:

1)

X x;
x.InitializeDef aults();

be better semantically than

2)

X x;

for setting the default values of 100000 for i and 10000 for s ? In
other words what is the rationale for removing the natural
user-defined default constructor for value types and forcing the user
to default construct the value type object to its zero or null values
and then have to call another function to set default values which
the type may want ? I read that 2) can not be guaranteed to occur
properly but 1) evidently can ? Someone please explain to me how a
sequence of two syntax actions has a better guarantee of properly
being implemented than just one.

It's simple: The CLR expects to be able to default-construct a value type
by 0-filling it's representation and cannot guarantee that a constructor
will be called.

-cd

[Marcus Heege]

That's a strange story. .NET's base spec (the Common Langauge
Infrastructure) does support value types with parameterless constructors,
but only half hearted. Therefore, most languages do not support them.
Unfortunately, C++ managed extensions was an exception.

The most obvious reason why parameterless ctros are not supported is fast
array initialization. Think of this array:

array<V>^ arrayOfVTs = gcnew aray<V>(1000000 );

Assume each VT instance is 8 bytes long. To initialize the array, an
instructroin similar to memset(address of array data, 800000000, 0) is used.
This is possible, because VTs can not have parameterless ctors. With a
parameterless ctor, this would be necessary to initialize the array:

for (int i = 0; i < 1000000; +i)
... call VT .ctor for i-th element ...

This would be significantly slower

Marcus

"Edward Diener" <ed************ *******@tropics oft.com> wrote in message
news:eC******** *****@TK2MSFTNG P03.phx.gbl...

Given

value class X
{
public:
// Not allowed: X():i(100000),s (10000) { }
// Allowed
void InitializeDefau lts() { i = 100000; s = 10000; }
private:
int i;
short s;
}

How can:

1)

X x;
x.InitializeDef aults();

be better semantically than

2)

X x;

for setting the default values of 100000 for i and 10000 for s ? In other
words what is the rationale for removing the natural user-defined default
constructor for value types and forcing the user to default construct the
value type object to its zero or null values and then have to call another
function to set default values which the type may want ? I read that 2)
can not be guaranteed to occur properly but 1) evidently can ? Someone
please explain to me how a sequence of two syntax actions has a better
guarantee of properly being implemented than just one.

[Edward Diener]

Marcus Heege wrote:

That's a strange story. .NET's base spec (the Common Langauge
Infrastructure) does support value types with parameterless constructors,
but only half hearted. Therefore, most languages do not support them.
Unfortunately, C++ managed extensions was an exception.

The most obvious reason why parameterless ctros are not supported is fast
array initialization. Think of this array:

array<V>^ arrayOfVTs = gcnew aray<V>(1000000 );

Assume each VT instance is 8 bytes long. To initialize the array, an
instructroin similar to memset(address of array data, 800000000, 0) is used.
This is possible, because VTs can not have parameterless ctors. With a
parameterless ctor, this would be necessary to initialize the array:

for (int i = 0; i < 1000000; +i)
... call VT .ctor for i-th element ...

This would be significantly slower
Good, it should be slower. If the programmer wants to provide a
user-defined default constructor for a type, then filling an array
should construct each value of that type with that default constructor.
That is the normal expectation. Skewing the language/implementation is
not the way to go.

In native C++ if I create a std::vector with a size of 1000000 then each
element of my vector will be default constructed. I see no reason why
..NET should not have followed this same rule instead of choosing the bad
idea that default constructors will not be allowed for value types.

In real life of course nobody creates an array of 1 million elements.

I am piqued about this because I know that MS made a bad decision in not
allowing normal constructors/destructors for value types. But it is too
late to change anything. Once the wrong path is taken nobody will admit
to failure.

Marcus

"Edward Diener" <ed************ *******@tropics oft.com> wrote in message
news:eC******** *****@TK2MSFTNG P03.phx.gbl...

Given

value class X
{
public:
// Not allowed: X():i(100000),s (10000) { }
// Allowed
void InitializeDefau lts() { i = 100000; s = 10000; }
private:
int i;
short s;
}

How can:

1)

X x;
x.InitializeDef aults();

be better semantically than

2)

X x;

for setting the default values of 100000 for i and 10000 for s ? In other
words what is the rationale for removing the natural user-defined default
constructor for value types and forcing the user to default construct the
value type object to its zero or null values and then have to call another
function to set default values which the type may want ? I read that 2)
can not be guaranteed to occur properly but 1) evidently can ? Someone
please explain to me how a sequence of two syntax actions has a better
guarantee of properly being implemented than just one.

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

Given

value class X
{
public:
// Not allowed: X():i(100000),s (10000) { }
// Allowed
void InitializeDefau lts() { i = 100000; s = 10000; }
private:
int i;
short s;
}

How can:

1)

X x;
x.InitializeDef aults();

be better semantically than

2)

X x;

for setting the default values of 100000 for i and 10000 for s ? In
other words what is the rationale for removing the natural
user-defined default constructor for value types and forcing the user
to default construct the value type object to its zero or null values
and then have to call another function to set default values which
the type may want ? I read that 2) can not be guaranteed to occur
properly but 1) evidently can ? Someone please explain to me how a
sequence of two syntax actions has a better guarantee of properly
being implemented than just one.

It's simple: The CLR expects to be able to default-construct a value type
by 0-filling it's representation and cannot guarantee that a constructor
will be called.

I clearly did not ask how things worked but why. Your answer to my
question is "that's the way things are."

The array argument I am constantly given is flawed. A native C++
std::vector<X> of n elements default constructs each element. CLRs
attempts to get around this are just plain wrong and create a ridiculous
anomaly which tells me that I can create constructors for value types
but I can not create a default constructor for a value type. What a bad
design decision that is. OK, what's the difference. Like everybody else
I will have to kludge my way around this abortion. I just expected
better from MS.

[Edward Diener]

Bruno van Dooren wrote:

for setting the default values of 100000 for i and 10000 for s ? In
other words what is the rationale for removing the natural user-defined
default constructor for value types and forcing the user to default
construct the value type object to its zero or null values and then have
to call another function to set default values which the type may want ?
<from http://www.codecomment s.com/archive292-2006-2-806923.html>

Please, I know the rule. I clearly asked why and not how.

If you also look in "C++-CLI Standard.pdf", you read :

12.2.1 Value classes
A value class is a data structure that contains fields, function members,
and nested types. Unlike other class
types, value classes do not support user-defined destructors, finalizers,
default constructors, copy
constructors, or copy assignment operators. Value classes are designed to
allow the CLI execution engine to
efficiently copy value class objects.

[Carl Daniel [VC++ MVP]]

Edward Diener wrote:

Carl Daniel [VC++ MVP] wrote:

It's simple: The CLR expects to be able to default-construct a
value type by 0-filling it's representation and cannot guarantee
that a constructor will be called.

I clearly did not ask how things worked but why. Your answer to my
question is "that's the way things are."

Oh contraire - you asked why C++/CLI prohibits defining a copy constructor -
and the reason I gave is correct: the CLR doesn't support it.

Why the CLR makes such a requirement is another question - and one that I've
never seen a satisfactory answer for. I can't help but wonder if it's
simply due to lack of planning at some very deep level in the CLR. Having
value types designed such that it's not necessary to run a default
constructor makes sense. Having them defined so it's not possible to
(always) run a default constructor seems like a design omission to me.

-cd

[Edward Diener]

Carl Daniel [VC++ MVP] wrote:

Edward Diener wrote:

Carl Daniel [VC++ MVP] wrote:

It's simple: The CLR expects to be able to default-construct a
value type by 0-filling it's representation and cannot guarantee
that a constructor will be called. I clearly did not ask how things worked but why. Your answer to my
question is "that's the way things are."

Oh contraire - you asked why C++/CLI prohibits defining a copy constructor -

No, a default constructor.
and the reason I gave is correct: the CLR doesn't support it.

Why the CLR makes such a requirement is another question - and one that I've
never seen a satisfactory answer for. I can't help but wonder if it's
simply due to lack of planning at some very deep level in the CLR. Having
value types designed such that it's not necessary to run a default
constructor
Now you have it right.
makes sense. Having them defined so it's not possible to
(always) run a default constructor seems like a design omission to me.

I am glad someone agrees with me here. Having to write a kludge, either
a dummy constructor which takes at least one argument but actual does
default construction, or a separate function to be called to do default
construction, seems really silly to me. I know I can use a ref class
instead but I see nothing wrong with simple value classes which
initialize their variables to something other than 0 when default
constructed.

[Bo Persson]

"Edward Diener" <ed************ *******@tropics oft.com> skrev i
meddelandet news:u8******** ******@TK2MSFTN GP03.phx.gbl...

Carl Daniel [VC++ MVP] wrote:

It's simple: The CLR expects to be able to default-construct a
value type by 0-filling it's representation and cannot guarantee
that a constructor will be called.

I clearly did not ask how things worked but why. Your answer to my
question is "that's the way things are."

The CLR wasn't designed for C++, but for primarilly for C#.

Now, when adopting C++/CLI to the existing infrastructure, we just
have to accept it "the way things are". C++ is still not a first class
citizen of .NET. C++/CLI is, and it turned out to be different.
Bo Persson