when do you use NEW?

Printable View

Apr 27th, 2004, 02:40 PM
Andy

when do you use NEW?
I've been doing this for some time now but I still consider myself a 'newbie' lol

ok, just when I thought I had the OOP thing down, I am lost again!! :)

when you create a new variable/instance of a class, when do you know to use the NEW keyword? for example:
VB Code:
```
dim button as NEW button
```
VB Code:
```
dim button as button
```
VB Code:
```
dim dg as datagrid
```
VB Code:
```
dim dg as NEW datagrid
```
And, when you place a component/control from the toolbox onto the form, is the IDE secretly doing those declarations for you behind the scenes?

Then, there are times when you go ahead and put the '=' at the end and set them to something...When do you know the appropriate syntax?

I've apparently forgotten some basics along the way :) can anyone enlighten me?

ashamed---->:blush:
Apr 27th, 2004, 02:53 PM
Memnoch1207
this just declares the MyButton object as a Button object.
VB Code:
```
Dim MyButton As Button
 
'it isn't created until you do this
MyButton = New Button
```
This creates the MyButton object as a new instance of the Button object.
VB Code:
```
Dim MyButton As New Button
```
Apr 27th, 2004, 04:09 PM
Andy
ok..so basicaly
VB Code:
```
dim MyButton as New Button
```
is the same as the first two statements, just shortened?
Apr 27th, 2004, 05:05 PM
VBCrazyCoder
This would bomb because you did not instantiate the button object (with new) but instead only declared the type:
VB Code:
```
Dim myButton As Button
myButton.Text() = "Something"
```
Throwing new in the mix works fine, because you actually have the button object to work with:
VB Code:
```
Dim myButton As New Button
myButton.Text() = "Something"
```

Basically, if you want to create an object, you can assign it to a variable and create it in one step using:

VB Code:

Dim variable As New Object

But if you were to just type:

VB Code:

Dim variable as Object

...then you're not creating an instance of a new object at all, you're just telling VB what kind of object the variable represents.

This is required for a lot of reasons but the most basic idea can be demonstrated with an OOP version of the hello world program that I just made up. This really makes OOP look bad because you're taking something that can be done in one line and breaking it up into 20 for no good reason, but you have to understand that with complex programs that require 3000 different pieces to work together and make something happen, this type of coding is a bliss. The following is a console application, if you have any questions let me know. Let's create a new object.

VB Code:

Public Class World
 
    Function SayWorld(ByVal input As String) As ArrayList
        Dim collect As New ArrayList
 
        If input = "Hello" Then
 
            Dim words As String = "Hello World!"
            collect.Add(words)
            Return collect
 
        Else
 
            Dim words As String = "You suck!"
            collect.Add(words)
            Return collect
 
        End If
 
    End Function
 
End Class

The top should be self explanatory. It's a new object we created that contains a function. Based on the input parameter of the function, it either returns the string "Hello World!" or "You suck!" in an ArrayList. The following is a program that uses the object created above.

VB Code:

'This imports line isn't required because our main program right here
'and the World class are both in the same namespace.  But it doesn't hurt
'to get used to defining your namespaces.
 
Imports VBTest.World
 
Module TalkToMeBaby
 
    Sub Main()
 
        Console.WriteLine("What's up fool.  Talk to me baby.")
 
        'This next line creates the variable blah with whatever the user types in the console.
        Dim blah As String = Console.ReadLine()
 
        'Let's create an instance of the World class.
        Dim stuff As New World
 
        'I could create another instance of World if I cared.
        Dim otherStuff As New World
 
        'Buuut it's useless for our purpose.  This next line assigns a variable of our choice to the
        'ArrayList type. Notice I did NOT create a new ArrayList.
        Dim myToy As ArrayList
 
        'Since I didn't create a new ArrayList, doing this:
 
        'myToy.Add(blah)
 
        '...would return a compiler error.  So what CAN I do with it you ask?  Watch.
 
        'This next line calls the SayWorld function, and assigns the return ArrayList
        'to myToy.
        myToy = stuff.SayWorld(blah)
 
        'Since myToy now actually points to a real instance of an ArrayList, we can
        'get stuff from it.  This next line gets the string from the ArrayList and
        'assigns it to the string "result".
        Dim result As String = CType(myToy(0), String)
 
        'Print the string to the console.  If the user typed "Hello", it will say "Hello
        'World!"  If not, it says "You suck!"  This program IS case sensitive.
        Console.WriteLine(result)
 
        'Press any key to exit.
        Console.ReadLine()
 
    End Sub
 
End Module

Apr 27th, 2004, 08:51 PM
DevGrp
Quote:
Originally posted by Andy
ok..so basicaly

VB Code:

dim MyButton as New Button

is the same as the first two statements, just shortened?
Yes.
Apr 27th, 2004, 10:42 PM
maurices5000
Ok guys, then why do this:
VB Code:
```
Dim oEmployee As Employee = New Employee
```
my intro to OOP with VB.Net always uses this syntax.

I know from vb6, though i don't competely understand it, that using:
VB Code:
```
dim MyButton as Button
```
is also useful with the for each loop when working with collections. You don't necessarily need an instance to cycle through all the buttons but you do need a variable declared as a button. Is this right? does this make sense?

Thanks Andy, because this was a good discussion to open up.
Apr 28th, 2004, 03:11 AM
wossname

In my Programming department (yeee its all mine!) its against coding policy to use

dim x as new myclass

because it wastes memory in objects that dont need to have things initialised from the word go. It can be very inefficient.

Instead we always use

dim x as myclass
....
x = new myclass 'only when needed
Apr 28th, 2004, 05:34 AM
DevGrp

Quote:

Originally posted by wossname
In my Programming department (yeee its all mine!) its against coding policy to use

dim x as new myclass

because it wastes memory in objects that dont need to have things initialised from the word go. It can be very inefficient.

Instead we always use

dim x as myclass
....
x = new myclass 'only when needed

Thats correct
Apr 28th, 2004, 08:04 AM
Andy
alright, I think I see now.

If you just need to set up space for the object in memory but you don't need it right at the moment, just declare it as
VB Code:
```
Dim obj as Object
```
Then, when you are ready to use it, instantiate it:
VB Code:
```
obj = New Object
```
am I right so far?

BUT, if you don't have a variable set up AND you need to use it right then, you would declare it AND instatiate it in one swipe:
VB Code:
```
Dim obj as New Object
```
or
VB Code:
```
Dim obj As Object = New Object
```
Those are the SAME statements, right?

If I hit the target, then I think I understand it now. :)

maurices5000, that's exactly the confusion I have. Maybe, this clears it up for BOTH of us :bigyello:

Yes, you can declare it at the top with all your variables, but you don't want to instantiate it until you need to use it.

Example

VB Code:

Public Class MyClass
   
   Private a As Object
   Private b As Object
 
   Public Sub New()
      a = New Object
      Call CreateBObject()
   End Sub
 
   Public Sub CreateBObject()
      b = New Object
   End Sub
End Class

Apr 28th, 2004, 11:22 AM
taxes

Hi wossname,

If you are concerned about space and time, why not leave the declaration until you need the instance? Unless of course you are going to use the same variable to hold an instance of different objects at different times or scope.
Apr 28th, 2004, 05:02 PM
Kt3

Quote:

Originally posted by taxes
Hi wossname,

If you are concerned about space and time, why not leave the declaration until you need the instance? Unless of course you are going to use the same variable to hold an instance of different objects at different times or scope.

Some people like to declare all their variables from the get go because it goes with their flow of thinking, and by declaring it and not instantiating it till later then you don't have to worry about memory consumption. This applies to method and class declarations.
Apr 28th, 2004, 07:26 PM
taxes

Hi Kt3,

"Some people like to declare all their variables from the get go because it goes with their flow of thinking, and by declaring it and not instantiating it till later then you don't have to worry about memory consumption."

Doesn't declaring the variable use memory?
Apr 28th, 2004, 07:51 PM
DevGrp
Quote:

Originally posted by taxes
Hi Kt3,

"Some people like to declare all their variables from the get go because it goes with their flow of thinking, and by declaring it and not instantiating it till later then you don't have to worry about memory consumption."

Doesn't declaring the variable use memory?

Not until you use the new keyword. Check this out. If you have
VB Code:
```
Dim mc as MyClass
```
the compiler is declaring the variable but the variable could be pointing to anywhere in memory. Essentially its pointing at garbage.
Now doing
VB Code:
```
mc = New MyClass()
```
is allocating the amount of memory that MyClass requires on the managed heap and returning a pointer to the variable. So memory is not being allocated until you use the new keyword.
Apr 28th, 2004, 08:16 PM
Andy

now THATS interesting! I didn't know this would start such a good thread!! Now I don't feel so bad for asking lol

I need to look up what a 'managed heap' is now :) but, that's another thread to come :bigyello:
Apr 28th, 2004, 08:17 PM
taxes

Hi DevGrp,

Thanks
:wave:
Apr 29th, 2004, 05:53 AM
DevGrp

Quote:

Originally posted by taxes
Hi DevGrp,

Thanks
:wave:

No problem.
Apr 29th, 2004, 07:30 AM
maurices5000
Ok, guys i thought this might be a defining question, but it may have already been answered. What is the big difference between declaring a variable and instantiating it?
VB Code:
```
Dim oObject as Object
```
AND
VB Code:
```
oObject = New Object
```
By declaring it as a NEW object, you make it an exact duplicate of the class or already instantiated object?
VB Code:
```
oObject = New Object22
```
makes oObject the exact same as Object22?

One last question.

I stated earlier that by dimming a variable as an object you can use in a for each statment. How does this relate to memory allocation? The variable is indeed being used in some way even if it were not instantiated. What is the difference? I might be testing the limits here. :D
VB Code:
```
Dim oObject  as Object
 
For each oObject in ThisObject
 
....
 
Next
```
Thanks guys!
:)
Apr 29th, 2004, 09:00 AM
Memnoch1207
When declaring a variable all you have done is declared a "container" for the data type the variable represents, but the variable contains nothing until you assign (instantiate) it.

Example
VB Code:
```
Dim x As Object  'x = Nothing
 
Dim x As Object = New Object() 'x = a new instance of the Object class.
 
Dim x As New Object() 'x = a new instance of the Object class (the type is inferred from the initialization).
 
Dim x As Object = SomeObject 'x is assigned to represent or point to SomeObject, which would be an instance of an Object.
```
So, while .Net allows you to combine some of these operations in a single statement, and infer a thing or 2, you need to be aware that the single statement is actually performing several things with one statement.

In order to use variables in a .Net app, you need to do the following:

1. Declare ("Dim") the variable (with Option Strict turned ON [recommended], you must declare the type as well).

2. Assign the variable to an instance of an object. There are 2 ways to do this:
a. Instantiate a New instance of an object and assign that to the variable.
b. Assign an existing object to the variable.
Apr 29th, 2004, 02:59 PM
Andy

Great, I, for one understand this a lot more now. Now, if you have an app that is going to use certain classes a LOT, should the variables be created and set to New in a public module and just re-used until the app is closed or should there be a new one created with each method call and destroyed at the end of the method? That seems like a LOT of code to use compared to simply creating ONE and keeping it alive. However, if you're not using an object, that's just a waste of memory, eh? I am guessing it's a 'style' thing...depending on each programmer's style, it will be done differently, right?

Thanks Memnoch that was helpful. Here is an example of some vb6.0 code i don't completely understand to help you see my problem.
VB Code:
'Declarations Section
Dim CDPath As String
Dim FSO As New Scripting.FileSystemObject
Dim DRV As Drive                               'A generic drive type
Dim X As Integer
 
 
X = 0 'initiate x
 
'checks the Drives for CD-ROMs
For Each DRV In FSO.Drives
   If DRV.DriveType = CDRom Then
     CDPath = DRV.Path      'gets the drive letter
     'Debug.Print CDPath
      X = X + 1
      ReDim Preserve gsCDdrive(X)
      gsCDdrive(X) = CDPath    'stores letter and number of drives
 
     'Debug.Print gsCDdrive(x)
   End If
Next DRV  'This generic drive becomes nothing after going through all the drives
How is DRV being used? All the comments are mine. I would say that the DRV is empty but evidently it is something. i just don't understand WHY this works. A datatype by itself does nothing. What is the difference between DRV=Nothing and DRV = some type of drive. Evidently it reads it in the above code as some type of drive, but it equals nothing. is For each drv in FSO.drive a type of assignment? I only know of one type of assignment operator.

Apr 29th, 2004, 07:06 PM
DevGrp

Quote:

Originally posted by Andy
Great, I, for one understand this a lot more now. Now, if you have an app that is going to use certain classes a LOT, should the variables be created and set to New in a public module and just re-used until the app is closed or should there be a new one created with each method call and destroyed at the end of the method? That seems like a LOT of code to use compared to simply creating ONE and keeping it alive. However, if you're not using an object, that's just a waste of memory, eh? I am guessing it's a 'style' thing...depending on each programmer's style, it will be done differently, right?

I would'nt recommend instantiating a variable until you are ready to use it. It all has to do with memory. You might not have a whole lot of memory to work with and you instantiate all these objects and run out of memory. And since the GC in .NET is non-deterministic, you can never tell for sure when an object thats out of scope will be collected unless you call the dispose method on the object.

Read up on value types and reference types, you'll get a better understanding of how reference types are created on the heap and value types are created on the stack.
Apr 29th, 2004, 08:51 PM
nemaroller
Ok, not to byte some in the arse here...

and just for clarification to Andy..

someone explain the difference between these two segments, considering the aforementioned not to instantiate an object until you need it:
VB Code:
```
Public Class Widget
 Private wittle As New Wittle
 Private wuttle As New Wuttle
 Public Sub New()
 End Sub
End Class
```
compare to:
VB Code:
```
Public Class Widget
 Private wittle As Wittle
 Private wuttle As  Wuttle
 Public Sub New()
   wittle = New Wittle
   wuttle = New Wuttle
 End Sub
End Class
```
I would say its a good general rule, but there's a lot more to be considered. For instance, a class that represents an ASP webpage, that dynamically builds itself using data from a database would almost always instantiate a new SqlConnection whenever the object was created. Why? Because it relies on that SqlConnection object being instantiated for its own livelihood .
Apr 29th, 2004, 09:28 PM
DevGrp
Quote:
Originally posted by nemaroller
Ok, not to byte some in the arse here...

and just for clarification to Andy..

someone explain the difference between these two segments, considering the aforementioned not to instantiate an object until you need it:

VB Code:

Public Class Widget
Private wittle As New Wittle
Private wuttle As New Wuttle
Public Sub New()
End Sub
End Class

compare to:

VB Code:

Public Class Widget
Private wittle As Wittle
Private wuttle As Wuttle
Public Sub New()
wittle = New Wittle
wuttle = New Wuttle
End Sub
End Class

I would say its a good general rule, but there's a lot more to be considered. For instance, a class that represents an ASP webpage, that dynamically builds itself using data from a database would almost always instantiate a new SqlConnection whenever the object was created. Why? Because it relies on that SqlConnection object being instantiated for its own livelihood .
If you are gonna use the object, then its ok to instantiate it. However you can always declare your variables then instantiate each one when you are ready to use it. Also you might not have noticed but if you look at the generated code in VB.NET, it follows your second example. The object is declared then it is instantiated in the constructor.
Apr 29th, 2004, 09:42 PM
nemaroller

Well, I tell you one thing, I'd be damned if a project manager wanted me to declare and then instantiate an object in two seperate places if I knew fair well the object was needed.

Compiler-wise, it makes no difference.

As far as VS's generated code, a lot of that is also done for clarity and in some cases to allow debugger step-through.
Apr 29th, 2004, 10:13 PM
DevGrp
Quote:

Originally posted by nemaroller
Well, I tell you one thing, I'd be damned if a project manager wanted me to declare and then instantiate an object in two seperate places if I knew fair well the object was needed.

Compiler-wise, it makes no difference.

As far as VS's generated code, a lot of that is also done for clarity and in some cases to allow debugger step-through.

No one is saying that you should'nt do it that way, but if you instantiate all your objects and is not gonna use some at the very minute, you might run out of memory. Say for instance you wanted to create an object and use at the same time
VB Code:
```
Dim a as MyClass = New MyClass()
a.DoSomething();
a.DoSomethingElse();
```
This would be fine. No consider if you needed to create 5 different objects
VB Code:
```
Dim a as AClass = New AClass() 
Dim b as BClass = New BClass() 
Dim c as CClass = New CClass() 
Dim d as DClass = New DClass() 
Dim e as EClass = New EClass() 
 
a.DoSomething();
 
'do something else
 
e.DoSomething();
```
Now depending on how many bytes those objects needed to allocate, you might run out of memory and get an out of memory exception.

In the first code snippet you can always instantiate the object right before you use it, less chance of running out of memory since only the object or objects being instantiated is gonna be used at that very moment.

Personally thats how I write my code, but everybody has their preference.
Apr 29th, 2004, 10:32 PM
nemaroller

doSomething should be a shared function :)

Again, my point is it really depends on the code (maybe I should say project) layout. I haven't rarely had the need to instantiate 5 objects like that.

I guess a better way to put that would be, unless its a class that defines a form or webpage, it almost makes little difference to hold off the instantiation. Most classes are so small their footprint is very neglible, and go out of scope fast enough.

In the end, you're right though, more often than not, it really is just a matter of preference.
Apr 29th, 2004, 10:39 PM
DevGrp

Well since the GC is non-deterministic, you can not really count on the GC to collect an object that goes out of scope.
Apr 29th, 2004, 11:08 PM
Edneeis
Quote:

Originally posted by DevGrp
Well since the GC is non-deterministic, you can not really count on the GC to collect an object that goes out of scope.

Unless of course you are running low on memory. The GC cleans more the less memory you have. Memory also is a fairly cheap resource and with computers now days you should be getting a Memory Exception from something so simple.

I understand what you are saying and you are right it really just boils down to personal preference. There is no right or wrong answer per say.

Here is how I see it using the following classes as an example:
VB Code:
```
Public Class ExampleA
  Private _member As New Member
 
 Public Sub New()
   'default
 End Sub
 
End Class
 
Public Class ExampleB
  Private _member As Member
 
 Public Sub New()
   'default
   _member=New Member
 End Sub
 
End Class
 
Public Class ExampleC
  Private _member As Member
 
  Public Sub CreateMembers()
     _member=New Member
  End Sub
 
 Public Sub New()
   'default
 End Sub
 
End Class
```
I see these classes (A&B) as consuming the same amount of memory at the same points in time. Since the member variables are created at class creation in both instances. Now you may say that the members will not be initialized at class creation but then I would say why give it class level scope then? In example C you will need to check if _member is nothing before using it in any other methods which uses cycles or if it is only needed for the duration of the method then it shouldn't have class level scope. So personally I see no point in not initializing your variables at declaration. Of course this is only opinion and there is no right or wrong answer.
Apr 30th, 2004, 05:06 AM
taxes

Hi,

"I see these classes (A&B) as consuming the same amount of memory at the same points in time. Since the member variables are created at class creation in both instances. Now you may say that the members will not be initialized at class creation but then I would say why give it class level scope then?"

But this thread has been concerned with whether or not a frequently used object should be declared with global scope but only instanced when required. The question has been whether or not the declaration alone consumes significant memory, and as I understand the posts, the conclusion is that such memory consumption is insignificant. As you intimate, however, this is probably merely an academic point.
Apr 30th, 2004, 07:06 AM
nemaroller

Quote:

Originally posted by taxes

The question has been whether or not the declaration alone consumes significant memory, and as I understand the posts, the conclusion is that such memory consumption is insignificant. As you intimate, however, this is probably merely an academic point.

I believe the original question was the former, it may have evolved into the latter.

As far as the declaration alone, a variable that will eventually hold a reference to an instantiated class (System.Object), those variables only take minimally 4 bytes of memory , so its a REAL mute point.

http://msdn.microsoft.com/library/de...adatobject.asp

http://msdn.microsoft.com/library/de...rpdatatype.asp
Apr 30th, 2004, 07:16 AM
Andy

I remember way back in the 80's (I was 10 or so) being told to keep the code short, keep the the memory consumption tiny and deep the amount of physical space your app uses down to minimum because resources were NOT cheap much less, the technology hadn't been invented yet to accomodate more than 100 MB of disk space or 8Meg of RAM. I think we can all agree on those points

Now, in 2004, we have wrist-watches with more processing power than the mid-80's computers so some would say "Don't worry about memory or physical space....yadda yadda". I Still think a developer should keep the app as slim as possible just because, in my opinion, it's an industry trademark.

Now, to keep this thread on topic...If you declare a variable and instatiate it as new or even just reference another object and don't need it, you're obviousely wasting SOMETHING, right? Now that I have a better understanding of what goes on, I'm gonna try to keep my variables in the tiniest scope possible to reserve the resources of the 'customers' computer. That's just my way of making sure I have an edge over the 'fly-by-night' programmers who can come in and bang out an app, take glory for it but later, it crashes and someone is stuck with cleaning the mess.

That's just my observation :)
Apr 30th, 2004, 09:03 AM
maurices5000
Guys this has been a very beneficial thread. But still, what is this?
VB Code:
```
Dim FSO As New Scripting.FileSystemObject
Dim DRV As Drive                               
 
For Each DRV In FSO.Drives
   
   Debug.print Drv   'DRV = A:, C:, D:, E:
 
 
Next DRV 
 
'at this point DRV become nothing
```
Why does this code work? I understand it, but it is just vague. I don't have any really conclusive answers. Is this a type of assignment or what? Or maybe it is an issue of the For Each loop. I guess i may need to look that up. Does the for each loop require a Type between the keywords Each and In?
Apr 30th, 2004, 09:17 AM
VBCrazyCoder

Behind the scenes .NET is doing DRV = FSO.Drive(x) for each iteration through the loop.
Apr 30th, 2004, 09:31 AM
maurices5000
It does seem to be an issue with the For Each loop. MSDN gives this example

For Each...Next
A For Each...Next loop is similar to a For...Next loop, but it repeats a group of statements for each element in a collection of objects or in an array instead of repeating the statements a specified number of times. This is especially helpful if you don't know how many elements are in a collection.
Quote:
Here is the syntax for the For Each...Next loop:

VB Code:

For Each element In group
'statements

Next element

For example, the following Sub procedure opens Biblio.mdb and adds the name of each table to a list box.

VB Code:

Sub ListTableDefs()
Dim objDb As Database
Dim MyTableDef as TableDef 'Similar to my generic drive ex.

Set objDb = OpenDatabase("c:\vb\biblio.mdb", _
True, False)

For Each MyTableDef In objDb.TableDefs()
List1.AddItem MyTableDef.Name
Next MyTableDef

End Sub

Keep the following restrictions in mind when using For Each...Next:

For collections, element can only be a Variant variable, a generic Object variable, or an object listed in the Object Browser.
For arrays, element can only be a Variant variable.
You cannot use For Each...Next with an array of user-defined types because a Variant cannot contain a user-defined type.
So again what is DRV in my example or MyTableDef in this example? Is Drive a type of Variant type? I thought the only Variant type was "Variant". But still DRV and MyTableDef have to be something. it is only just a variable because not any type of variable will fit.
Apr 30th, 2004, 09:38 AM
maurices5000

Thanks CrazyVBCoder! So when the for loop ends DRV is set to nothing? right?
Apr 30th, 2004, 10:12 AM
salvelinus
What about
VB Code:
```
Dim obj1 as SomeObject
dim obj2 as new SomeObject
 
obj1 = obj2
```
Is obj1 now a separate instance with the same values as obj2, or is it more like a pointer to obj2 itself? That is, if you modify obj1, is obj2 modified as well, or not?
I should remember this from C++, but haven't worked in that for a few years.
Apr 30th, 2004, 11:33 AM
taxes

Hi salvelinus,

"Dim obj1 as SomeObject
dim obj2 as new SomeObject

obj1 = obj2"

Anything you do to obj1 will be exactly reproduced in obj2

AND

Anything you do to obj2 will be exactly reproduced in obj1
Apr 30th, 2004, 11:56 AM
salvelinus

Ok, so you're saying there are two objects that mirror each other? I was thinking that obj1 & obj2 would be two names for the same one instance. Thanks.
Apr 30th, 2004, 09:12 PM
Edneeis

Yes they are just two references to the same instance of the object like you said.
May 1st, 2004, 04:41 AM
taxes

Hi, Salvelinus

"Yes they are just two references to the same instance of the object like you said."

I thought that the references are objects in themselves. You can in fact destroy either reference without affecting the other. It seems that as long as at least one reference exists, the instance remains accessible.

So, that means ALL objects are only references to other objects - the ultimate object being just a collection of code???

Really, if this carries on it should be a new thread.
May 1st, 2004, 07:00 AM
salvelinus

I don't know the mechanics behind it, but Edneiss's answer jibes with what I've forgotten about C++. To analogize in my example, obj2 is the name of the instance of the object, obj1 is just another name for it, like a nickname. Sort of like referring to Prince Charles as the Duke of Wales. Two names for the same thing. Both names act as pointers to the same place in memory.
May 1st, 2004, 08:27 AM
robymix

If SomeObject is a reference type [eg. a Class], then obj1 and obj2 are basically pointers to the same memory location.

If SomeObject is a value type [eg. a Struct], then the content of the memory location referenced by obj2 is copied to that referenced by obj1.

Using .Equals will tell you if they are the same object in memory.

VB Code:

Dim obj1 As New System.Object
        Dim obj2 As New System.Object
        MessageBox.Show(obj1.Equals(obj2))
        obj1 = obj2
        MessageBox.Show(obj1.Equals(obj2))

May 3rd, 2004, 02:46 AM
robymix

That's true nemaroller.
May 3rd, 2004, 08:29 AM
wey97
Quote:
Originally posted by maurices5000
Guys this has been a very beneficial thread. But still, what is this?

VB Code:

Dim FSO As New Scripting.FileSystemObject
Dim DRV As Drive

For Each DRV In FSO.Drives

Debug.print Drv 'DRV = A:, C:, D:, E:

Next DRV

'at this point DRV become nothing

Why does this code work? I understand it, but it is just vague. I don't have any really conclusive answers. Is this a type of assignment or what? Or maybe it is an issue of the For Each loop. I guess i may need to look that up. Does the for each loop require a Type between the keywords Each and In?
VB (or .NET for that matter) does a lot of things behind the scenes. I think of it like this:
VB Code:
```
Dim fso As New Scripting.FileSystemObject
Dim drv As Drive                               
Dim i as Integer
 
For i = 0 to fso.Drives.Count() - 1
 
    drv = New Drive()
    drv = fso.Drives(i)
    Debug.Print drv
 
Next i
```
I don't know if that's exactly right but you get the idea.
The For...Each construct is just more compact (if obfuscated) code.
May 6th, 2004, 07:08 AM
Andy
regarding certain data types: why is it that you delare some as NEW and some not?

ex
VB Code:
```
dim Name as string
'dim Name as NEW string doesn't work
 
dim Name as NEW arraylist
'Dim Name as arraylist works too.
```
is detailed information on declaring New found in the msdn?
May 6th, 2004, 07:31 AM
nemaroller

Strings are immutable, Arraylists aren't.
May 6th, 2004, 09:20 AM
Memnoch1207

There are 2 types Value Types (Integer, Double, etc..) and Reference Types (Objects).

You must use the New keyword when creating a new instance of a reference type.

Strings are the exception.

Although they are a reference type, they are immutable and not subject to the New keyword rule.
May 6th, 2004, 10:32 AM
maurices5000

thanks guys for your replies. That code was helpful Wey.

Andy i also had a similar question. so thanks.

But guys what is immutable?

My personal answer to Andy's question was that string, double, integer, etc were types while one uses NEW with objects. does this guess have any value. That was teh assumption i made so i didn't ask the question. :)

Thanks a lot. this is going to get me far in understanding the basics of OOP.
May 6th, 2004, 03:06 PM
Memnoch1207

immutable means "Can't be changed"

MSDN - Reference Types and Value Types
May 6th, 2004, 03:42 PM
PT Exorcist
Quote:
Originally posted by Andy
regarding certain data types: why is it that you delare some as NEW and some not?

ex

VB Code:

dim Name as string
'dim Name as NEW string doesn't work

dim Name as NEW arraylist
'Dim Name as arraylist works too.

is detailed information on declaring New found in the msdn?
Because when you do myString = "HI", .NET is creating a new string holding 2 chars ('H?, 'I') and will assign it to myString

All times are GMT -5. The time now is 03:36 PM.