when do you use NEW?

[Andy]

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:

dim button as NEW button

dim button as button

dim dg as datagrid

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---->

[Memnoch1207]

this just declares the MyButton object as a Button object.

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.

Dim MyButton As New Button

[Andy]

ok..so basicaly

dim MyButton as New Button

is the same as the first two statements, just shortened?

[VBCrazyCoder]

This would bomb because you did not instantiate the button object (with new) but instead only declared the type:

Dim myButton As Button
myButton.Text() = "Something"

Throwing new in the mix works fine, because you actually have the button object to work with:

Dim myButton As New Button
myButton.Text() = "Something"

[Kt3]

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

Dim variable As New Object

But if you were to just type:

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.

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.

'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

[DevGrp]

Originally posted by Andy
ok..so basicaly

dim MyButton as New Button

is the same as the first two statements, just shortened?

Yes.

[maurices5000]

Ok guys, then why do this:

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:

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.

[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

[DevGrp]

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

[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

Dim obj as Object

Then, when you are ready to use it, instantiate it:

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:

Dim obj as New Object

or

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

[Memnoch1207]

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

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

[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.

[Kt3]

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.

[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?

[DevGrp]

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

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

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.

[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

[taxes]

Hi DevGrp,

Thanks

[DevGrp]

Originally posted by taxes
Hi DevGrp,

Thanks

No problem.

[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?

Dim oObject as Object

AND

oObject = New Object

By declaring it as a NEW object, you make it an exact duplicate of the class or already instantiated object?

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.

Dim oObject  as Object
 
For each oObject in ThisObject
 
....
 
Next

Thanks guys!

[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

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.

[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?

[maurices5000]

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.

'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.

[DevGrp]

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.

[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:

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

compare to:

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 .

[DevGrp]

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:

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

compare to:

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.

[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.

[DevGrp]

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

Dim a as MyClass = New MyClass()
a.DoSomething();
a.DoSomethingElse();

This would be fine. No consider if you needed to create 5 different objects

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.

[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.

[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.

[Edneeis]

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:

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.

[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.

[nemaroller]

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

[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

[maurices5000]

Guys this has been a very beneficial thread. But still, what is this?

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?

[VBCrazyCoder]

Behind the scenes .NET is doing DRV = FSO.Drive(x) for each iteration through the loop.

[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.

Here is the syntax for the For Each...Next loop:

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.

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.

[maurices5000]

Thanks CrazyVBCoder! So when the for loop ends DRV is set to nothing? right?

[salvelinus]

What about

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.

[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

[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.