"new" keyword on value and object types?

[Ben R.]

I'm curious about the differeng behavior of the "new" keyword when dealing
with value versus object types. If I'm correct, when I do:

dim x as integer

There's no need for "new" to be called since this "value" type is all set to
go. Is this because value types are stored on the stack so the memory
initialization is already taken care of?

Now, when dealing with an object type, it seems you do need to use the "new"
keyword. Accordingly, when I do:

dim x as oledbconnection

What exactly is x before it's assigned to something with the "new" keyword?
Is it just space on the stack just as before?

Assuming this all to be the case, I'm curious about the behavior of the
String class. I was under the impression that it is not a value type.
However, it can be assigned to without using the new keyword, which breaks
the logic I thought applied. Further, it allows you to use the new keyword on
it.

Another question: What is the purpose of the "new" keyword on a value type?
Is it just for initialization (calling a constructor)? When "new" is called
on a object type, does it do this as well as return a pointer to the heap
address?

Thanks for any clarification...

-Ben

[Mattias Sjögren]

Is this because value types are stored on the stack
Value type variables aren't always stored on the stack, that's only
true for local variables.

initialization is already taken care of?
All variables in VB are initialized to their default values. The
default value is basically when all bits are set to zero. That means
zero for numeric types, False for booleans and Nothing for reference
type variables.

Now, when dealing with an object type, it seems you do need to use the "new"
keyword.
Only to assign something other than a Nothing reference (which you
probably want to do something useful with the variable).

What exactly is x before it's assigned to something with the "new" keyword?
Nothing

Is it just space on the stack just as before?
If it's a local variable, there's space allocated on the stack for it
yes.

Assuming this all to be the case, I'm curious about the behavior of the
String class. I was under the impression that it is not a value type.
Right, it's a reference type.

However, it can be assigned to without using the new keyword, which breaks
the logic I thought applied. Further, it allows you to use the new keyword on
it.
When you use a string literal a String object is implicitly created
for you so you don't have to write New.

Another question: What is the purpose of the "new" keyword on a value type?
Is it just for initialization (calling a constructor)?

Yes.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Ben R.]

>Value type variables aren't always stored on the stack, that's only
true for local variables.

Could you give an example of when a value type is not stored on the stack?
Is it in the case of a class member? If so, does it matter if it's static?

Another question: What is the purpose of the "new" keyword on a value type?
Is it just for initialization (calling a constructor)?
Yes.

So to confirm, when using "new" on a reference type, it does two things: 1)
It calls the appropriate constructor and 2) it returns the address of the
object on the heap for the assignment to the reference type variable. In the
case of calling new on a value-type variable, calling new does call the
appropriate constructor but returns nothing. Is this correct?

Is this separation of "reference" and "value" types different from classes
versus structs (object vs. value types)? Can you always conclude that a
struct is a value type and a class is a reference type?

Thanks for your helpful info, Mattias...

-Ben
"Mattias Sjögren" wrote:

Is this because value types are stored on the stack

Value type variables aren't always stored on the stack, that's only
true for local variables.

initialization is already taken care of?

All variables in VB are initialized to their default values. The
default value is basically when all bits are set to zero. That means
zero for numeric types, False for booleans and Nothing for reference
type variables.

Now, when dealing with an object type, it seems you do need to use the "new"
keyword.

Only to assign something other than a Nothing reference (which you
probably want to do something useful with the variable).

What exactly is x before it's assigned to something with the "new" keyword?

Nothing

Is it just space on the stack just as before?

If it's a local variable, there's space allocated on the stack for it
yes.

Assuming this all to be the case, I'm curious about the behavior of the
String class. I was under the impression that it is not a value type.

Right, it's a reference type.

However, it can be assigned to without using the new keyword, which breaks
the logic I thought applied. Further, it allows you to use the new keyword on
it.

When you use a string literal a String object is implicitly created
for you so you don't have to write New.

Another question: What is the purpose of the "new" keyword on a value type?
Is it just for initialization (calling a constructor)?

Yes.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Mattias Sjögren]

Ben,

Could you give an example of when a value type is not stored on the stack?
Is it in the case of a class member?
Yes exactly. Or when you have an array of the value type.

If so, does it matter if it's static?
No

So to confirm, when using "new" on a reference type, it does two things: 1)
It calls the appropriate constructor and 2) it returns the address of the
object on the heap for the assignment to the reference type variable. In the
case of calling new on a value-type variable, calling new does call the
appropriate constructor but returns nothing. Is this correct?
Yes that sounds right. Since the space for the value type variable is
already allocated there's no need to return a pointer to any newly
allocated object. You just overwrite the existing space.

Is this separation of "reference" and "value" types different from classes
versus structs (object vs. value types)?
Reference types include classes (including delegates) and interfaces.
Value types include structs and enums.

Can you always conclude that a
struct is a value type and a class is a reference type?

Yes
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Jeffrey Tan[MSFT]]

Hi Ben,

I think mattias has given you a detailed reply. Do you have any concern on
this issue? Please feel free to tell me, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.