various objects in my VB6 project

"Mark G. Meyers" <mmeyers[at]hydromilling.com> wrote in message news:***@TK2MSFTNGP11.phx.gbl...
<snip>

Post by Mark G. Meyers
SO HERE'S THE QUESTION....
Why not, and I would be looking for help figuring out how to do this... Mock
up AddRef and Release declarations that are legal in VB, and caste, starting
with the pointer passed in to GetRefCount() to the values in the 2nd and 3rd
entries of that object's vtable? Then, can I also caste the AddRef/Release
params/return values and "math" them to workable values? Effectively, make
the calls to AddRef() and Release() legal-eze in VB...? Since I haven't
seen this done, there must be some reason why, but I don't know what it is.

If you *really* want to go there, get this book and read it cover to cover. Then read it again. It will answer your
questions:
http://www.powervb.com
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ulWekD%23TEHA.2944%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DulWekD%2523TEHA.2944%2540tk2msftngp13.phx.gbl

Post by Mark G. Meyers
The caller that wants to kill the object calls a Delete function with a
reference to an object that implements the ITerminate interface. If that's
the only reference to it remaining, the object will be destroyed.

That already happens. When an object no longer has any references to it, Release is called on the object, and it
destroys itself. What is it you're suggesting adding?

Mark G. Meyers

2004-06-30 14:16:22 UTC

Post by Peter Young
<snip>

AddRef/Release

Post by Mark G. Meyers
params/return values and "math" them to workable values? Effectively, make
the calls to AddRef() and Release() legal-eze in VB...? Since I haven't
seen this done, there must be some reason why, but I don't know what it is.

If you *really* want to go there, get this book and read it cover to

cover. Then read it again. It will answer your

Post by Peter Young
http://www.powervb.com

Thanks. I've seen at least one post by the author, Matthew Curland.
Actually, now looking for it, just found another one. It all looks, as you
elude to, congested.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ulWekD%23TEHA.2944%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DulWekD%2523TEHA.2944%2540tk2msftngp13.phx.gbl

That already happens. When an object no longer has any references to it,

Release is called on the object, and it

Post by Peter Young
destroys itself. What is it you're suggesting adding?

It encapsulates the act of the object clearing up it's references before
setting the ref to nothing. It also provides a hook location for something
like what I'm talking about in this thread. But without the ability to
confirm that it is the last reference, "terminate" is a bit of a misnomer.

"...an ITerminate reference (interface that implements Term() where the
object clears it's various, <potential> circular refs), and then go and set
the ref passed into Delete() to Nothing..."

BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage. And
what is the difference between 'friend' and 'public' exactly? Nice lack of
static class members! And thanks be to inheritence through encapsulation.
How about that 'feature' where variables don't have to be declared - by
default. I would have thought that one to pass us by, say, 15 years ago (or
maybe when I coded in Dartmouth S-BASIC 25 years ago, which did require one
to do so). Boy, do I have a pet peeve or two with this language. In this
case, we got New, and we got no Delete. Ever see your COM subsystem just
lock up on you, and applications become unstable? Lest we avoid ActiveX or
DCOM for security purposes. Oh, and I benchmarked pipes vs COM for
inter-proces communications a few years ago on a Win2K box. The pipes were
only 70,000 times faster...
...END RANT

Peter Young

2004-06-30 15:29:38 UTC

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=ulWekD%23TEHA.2944%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DulWekD%2523TEHA.2944%2540tk2msftngp13.phx.gbl

Post by Mark G. Meyers
The caller that wants to kill the object calls a Delete function with a
reference to an object that implements the ITerminate interface. If

that's

Post by Mark G. Meyers
the only reference to it remaining, the object will be destroyed.

That already happens. When an object no longer has any references to it,

Release is called on the object, and it

Post by Peter Young
destroys itself. What is it you're suggesting adding?

It encapsulates the act of the object clearing up it's references before
setting the ref to nothing.

Let me be sure I understand this - you want to be able to be sure that an object releases all references it holds to
*other* objects before terminating it? You'd need some sort of global object that monitored all AddRef and Release
calls, so that when an object was to be destroyed, this global manager could look up which other objects were referenced
by this one.

VB pretty much does this for you.

If an object goes out of scope, VB will clean up that object. If you've created a circular reference, yes, you're in
trouble. Don't create circular references. Manually release all references before terminating an object in your
Class_Terminate event. It's pretty simple.

Post by Mark G. Meyers
BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage.

Hmmm...

Public Function Whatever( ) As Variant
Dim o As Object
Set o = New Collection
End Sub

That code creates a new COM object *and* releases it automatically, and creates and returns a Variant, and returns an
HRESULT to the caller. All that with 2 lines of code and a function footprint.

Show me the same thing in C++, and then tell me VB doesn't manage resources well.

Post by Mark G. Meyers
And
what is the difference between 'friend' and 'public' exactly?

Friend is visible within the project. Public is visible outside the project.

Post by Mark G. Meyers
Nice lack of
static class members! And thanks be to inheritence through encapsulation.

VB definitely is lacking some OO features. It would've been nice if MS would've improved it.

Post by Mark G. Meyers
How about that 'feature' where variables don't have to be declared - by
default. I would have thought that one to pass us by, say, 15 years ago (or
maybe when I coded in Dartmouth S-BASIC 25 years ago, which did require one
to do so). Boy, do I have a pet peeve or two with this language.

I couldn't agree more. The option probably shouldn't be there. It definitely should default the other way.

Post by Mark G. Meyers
In this
case, we got New, and we got no Delete.

You are aware of Nothing, right? Or are you drawing a distinction because Nothing is really just saying "remove my
reference"?

Post by Mark G. Meyers
Ever see your COM subsystem just
lock up on you, and applications become unstable?

Nope.

Post by Mark G. Meyers
Lest we avoid ActiveX or
DCOM for security purposes. Oh, and I benchmarked pipes vs COM for
inter-proces communications a few years ago on a Win2K box. The pipes were
only 70,000 times faster...

Since when is COM used for IPC?

-Pete

Mark G. Meyers

2004-06-30 17:07:37 UTC

Post by Peter Young
"Mark G. Meyers" <mmeyers[at]hydromilling.com> wrote in message

It encapsulates the act of the object clearing up it's references before
setting the ref to nothing.

Let me be sure I understand this - you want to be able to be sure that an

object releases all references it holds to

Post by Peter Young
*other* objects before terminating it? You'd need some sort of global

object that monitored all AddRef and Release

Post by Peter Young
calls, so that when an object was to be destroyed, this global manager

could look up which other objects were referenced

Post by Peter Young
by this one.

Peter, it's in the ITerminate example. The object frees up it's references
when it's Term() member is called, as only that object knows how to do.

With static class members, both creation and destruction could be elegantly
contained as in the example, where the in-house rule is, "Every class must
implement ICreateDestroy", for example.

Post by Peter Young
VB pretty much does this for you.
If an object goes out of scope, VB will clean up that object. If you've

created a circular reference, yes, you're in

Post by Peter Young
trouble. Don't create circular references. Manually release all references

before terminating an object in your

Post by Peter Young
Class_Terminate event. It's pretty simple.

Right - "don't create circular references". Noone ever told me how or why
such a thing would constitute bad programming practices, but because of this
situation in VB, it is. It's been a bit of a pain to do design work on a VB
project based moreso on general OOD principals, without so much actual VB
experience.

Post by Mark G. Meyers
BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage.

Hmmm...
Public Function Whatever( ) As Variant
Dim o As Object
Set o = New Collection
End Sub
That code creates a new COM object *and* releases it automatically, and

creates and returns a Variant, and returns an

Post by Peter Young
HRESULT to the caller. All that with 2 lines of code and a function footprint.
Show me the same thing in C++, and then tell me VB doesn't manage resources well.

Variant Foo()
{
Collection C("and cool constructors, too!");
Object * pObj = C;
}

Done!

This is the difference between recognizing stack space and heap space.
Frankly, the heap is going to be used quite a bit less in C++ than it will
in VB because of this. Now look at this example of hand-coded object
construction...

----------------------------------
Option Explicit
' class DisplayArmCalcsTask

Private Const mnArmSegments = 3 ' just the arm segments
Private Const mnTotalSegments = 5 ' number of segments - arm and
calibration
Private Const mnStateVars = 12 ' total number of (local) statevars
Private Const mnArmEncoders = 3 ' number of arm encoders

Private mcSegLens(1 To mnTotalSegments) As TextBox
Private mcArmCoords(mnTotalSegments + 1 To mnStateVars) As TextBox
Private mrStateVars(1 To mnStateVars) As StateDouble
Private mrEncoders(1 To mnArmEncoders) As Encoder

Private Sub Class_Initialize()
' Get local refs for the arm calc objects
Set mrStateVars(StateVarIndexes.ArmSegA_) = _
grControllerCard.GetNamedObject(g.StateDoubles.ArmSegLenA.Name)
Set mrStateVars(StateVarIndexes.ArmSegB_) = _
grControllerCard.GetNamedObject(g.StateDoubles.ArmSegLenB.Name)
Set mrStateVars(StateVarIndexes.ArmSegC_) = _
grControllerCard.GetNamedObject(g.StateDoubles.ArmSegLenC.Name)
Set mrStateVars(StateVarIndexes.ArmSegCalOne_) = _
grControllerCard.GetNamedObject(g.StateDoubles.ArmCalSegLenOne.Name)
Set mrStateVars(StateVarIndexes.ArmSegCalTwo_) = _
grControllerCard.GetNamedObject(g.StateDoubles.ArmCalSegLenTwo.Name)

Set mrStateVars(StateVarIndexes.ShoulderX_) = _

grControllerCard.GetNamedObject(g.StateDoubles.ArmShoulderAxisX.Name)
Set mrStateVars(StateVarIndexes.ShoulderY_) = _

grControllerCard.GetNamedObject(g.StateDoubles.ArmShoulderAxisY.Name)

<SNIP - there is much more of this!!!>
yes I know it looks like it should be in a loop, whatever, there's at
least 4 loops of this stuff here anyhow
End Sub

Actually, I para-coded it, I have a variety of Initxxx() methods for
bringing all this crap up initially. Every object-member of an object has
to have it's own New operation performed on it, and that can generate quite
a bit of code.

--------
Consider the following distinction, and I think this will help sort out what
we're talking about. Of course that which "by all rights" appears on the
stack goes as quickly as it comes. I think where VB offers the advantage is
in coding for polymorphism. I exercise it's polymorhic abilities
extensively, with a variety of small interfaces, and pass-through functions
to the default interface on all of them. Also a bit of extra code piling up
to do the pass-throughs, but nice when implemented.

Conversely to stack allocation, the things I tend to put to the heap don't
come and go within the scope of a single function. They tend to be a bit
more persistent, as objects, referenced by module-scope or global-scope
variables.

Post by Mark G. Meyers
And
what is the difference between 'friend' and 'public' exactly?

Friend is visible within the project. Public is visible outside the project.

Right. Reeeeeeeeaaaaallly friendly. When I split things into a
multi-programmer situation, I was faced with the idea of protecting access
to some things and not others. Then the extensive polymorphism came into
play, but, frankly, for just being protective, it doesn't seem worth it
(in-house, we're all friendly here). On a few classes, I made "client-side"
interfaces that included, for example, all the read properties but not the
writes. A ref to the default interface would be "server-side". There is a
small example of this style in the ITerminate sample. I call it
"inheritence through encapsulation".

I haven't gotten into multi-project development yet. Am I missing something
good? It's just an EXE - no real COM objects or multiple threads or
processes needed.

Post by Mark G. Meyers
In this
case, we got New, and we got no Delete.

You are aware of Nothing, right? Or are you drawing a distinction because

Nothing is really just saying "remove my

Post by Peter Young
reference"?

Yes, and yes, there is no delete. I think architecturally what we're
playing with here is that the creators of objects cannot (or may not be able
to) destroy the objects that they create. Cool, the creator can die and the
created remains, and yet, some people might not like that.

Post by Mark G. Meyers
Ever see your COM subsystem just
lock up on you, and applications become unstable?

Nope.

Happened to me working with the clipboard. Maybe rightfully so, then.
Everybody uses it.

Since when is COM used for IPC?

I created Browser Helper Objects that launched in processes (every explorer
instance) to communicate with other processes on the machine. At this
point, I don't even recall exactly how I tried the COM IPC, something to do
with sync'ing. It was no doubt floundering amidst O/S time-slicing, perhaps
amongst other things. Btw: this was happening prior to IE windows all
running in the same process (which kind of bugs me as a user, as now one
mis-behaving IE window easily kills them all).

-----------------

Frankly, I haven't taken the opportunity to blow off steam since starting
this VB adventure. Hope y'all don't mind - felt like a bit of a rant!
There's dozens of gripes against the C++ lexicon responding to the political
powers of when it came into being (there's a book on it). Maybe it happens
everywhere, but, MS has a unique way it seems to me to create an ambiguous
instruction set that just wouldn't survive a yacc. I saw it happen with an
OLAP tool (prior to development), and I still get wiered out by legally
coding sub calls vs function calls - with or without parenthesis, or with or
without the word 'Call'. It's all that Office VBA stuff, and that gets
quite fluffy nutterbox, too, like the ! symbol in Access, or maybe a dot, or
whatever. Syntactically ambiguous or vague, inter-related, dependent,
separate, and yet, integrated - funboxes!

Have a happy, and I'll try to do the same -
Mark

Peter Young

2004-06-30 18:38:51 UTC

Post by Peter Young
If an object goes out of scope, VB will clean up that object. If you've

created a circular reference, yes, you're in

Post by Peter Young
trouble. Don't create circular references. Manually release all references

before terminating an object in your

Post by Peter Young
Class_Terminate event. It's pretty simple.

Right - "don't create circular references". Noone ever told me how or why
such a thing would constitute bad programming practices, but because of this
situation in VB, it is.

RTFM...
http://msdn.microsoft.com/library/en-us/vbcon98/html/vbconcircularreferencesobjectlifetime.asp

I personally have never seen a situation where a circular reference was necessary.

Post by Peter Young
It's been a bit of a pain to do design work on a VB
project based moreso on general OOD principals, without so much actual VB
experience.

Bingo. Tough to design for a system you don't have experience with.

Post by Mark G. Meyers
BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage.

Hmmm...
Public Function Whatever( ) As Variant
Dim o As Object
Set o = New Collection
End Sub
That code creates a new COM object *and* releases it automatically, and

creates and returns a Variant, and returns an

Post by Peter Young
HRESULT to the caller. All that with 2 lines of code and a function

footprint.

Post by Peter Young
Show me the same thing in C++, and then tell me VB doesn't manage

resources well.
Variant Foo()
{
Collection C("and cool constructors, too!");
Object * pObj = C;
}
Done!

Where is the memory for pObj freed?

Post by Mark G. Meyers
In this
case, we got New, and we got no Delete.

You are aware of Nothing, right? Or are you drawing a distinction because

Nothing is really just saying "remove my

Post by Peter Young
reference"?

And some would be very unhappy if your object pulled their object out from under them. Imagine running under IIS where
everyone's objects are in the same process space. Your objects have no business killing off other objects that are in
use by other clients. This is the way that COM works. It's not a VB thing. VB is based on COM.

Post by Peter Young
-----------------
Frankly, I haven't taken the opportunity to blow off steam since starting
this VB adventure. Hope y'all don't mind - felt like a bit of a rant!

Blow and rant if you must. It just gets a little tiring to hear criticism about things that generally aren't problems.
VB is an odd duck for sure. But it's remarkably powerful at what it does right, which is most of what you need when
building Win32 solutions. And what it's missing can usually be added through various means. It just takes time to learn
it all.

-Pete

Mark G. Meyers

2004-06-30 19:19:40 UTC

Post by Mark G. Meyers
Variant Foo()
{
Collection C("and cool constructors, too!");
Object * pObj = C;
}
Done!

Where is the memory for pObj freed?

pObj points to Collection C, which is on the stack. C is gone when Foo()
exits. pObj is a pointer and does not allocate memory.

Post by Mark G. Meyers
Frankly, I haven't taken the opportunity to blow off steam since starting
this VB adventure. Hope y'all don't mind - felt like a bit of a rant!

Blow and rant if you must. It just gets a little tiring to hear criticism

about things that generally aren't problems.

Post by Peter Young
VB is an odd duck for sure. But it's remarkably powerful at what it does

right, which is most of what you need when

Post by Peter Young
building Win32 solutions. And what it's missing can usually be added

through various means. It just takes time to learn

Post by Peter Young
it all.

"It's an odd duck, but remarkably powerful"... I have not felt about this as
being a competition for "best development tool", and it occurs to me that
competition is tiring.

I think you're right about things you've said, pete. I've had to hit the
ground running, and I am not a VB pro to begin with. To that extent, I'm
overboard, and there's not much point to just outright ranting.

Conversely, as far as I am concerned these are not "generally not problems".
The shortest road from point A to point B is always under construction. By
that I mean to refer to programming altogether. When this thread began, my
query was in the direction of developing something that would provide
assistance. Further comments are good food for thought as well, and many of
these are responses to me. I've helped illustrate two examples of
comparative coding between C++ and VB. Does that help? I couldn't have
done it without you.

And I do intend to get a copy of Matthew Curland's book! Looks very good
(like when I take a vacation).

Cheers -
Mark

Peter Young

2004-06-30 19:35:30 UTC

Post by Mark G. Meyers
Variant Foo()
{
Collection C("and cool constructors, too!");
Object * pObj = C;
}
Done!

Where is the memory for pObj freed?

pObj points to Collection C, which is on the stack. C is gone when Foo()
exits. pObj is a pointer and does not allocate memory.

Well, even a pointer takes 4 bytes. Are you saying the C++ compiler is generating the cleanup code for you? My
experience is limited to C, so I apparently I'm not giving C++ its due. In C, memory allocation and deallocation is half
the battle. VB just about eliminates that for you (as do most modern languages).

Post by Mark G. Meyers
Frankly, I haven't taken the opportunity to blow off steam since

starting

Post by Mark G. Meyers
this VB adventure. Hope y'all don't mind - felt like a bit of a rant!

Blow and rant if you must. It just gets a little tiring to hear criticism

about things that generally aren't problems.

Post by Peter Young
VB is an odd duck for sure. But it's remarkably powerful at what it does

right, which is most of what you need when

Post by Peter Young
building Win32 solutions. And what it's missing can usually be added

through various means. It just takes time to learn

Post by Peter Young
it all.

"It's an odd duck, but remarkably powerful"... I have not felt about this as
being a competition for "best development tool", and it occurs to me that
competition is tiring.

Never claimed it was the best. I haven't found that one yet. Please let me know when you find it. I would love to use
it. ;-)

Post by Mark G. Meyers
Conversely, as far as I am concerned these are not "generally not problems".
The shortest road from point A to point B is always under construction. By
that I mean to refer to programming altogether.

Unfortunately, this is true.

Post by Mark G. Meyers
And I do intend to get a copy of Matthew Curland's book! Looks very good
(like when I take a vacation).

Highly recommended.

Best,
Pete

Mark G. Meyers

2004-06-30 20:48:53 UTC

Post by Peter Young
Well, even a pointer takes 4 bytes. Are you saying the C++ compiler is

generating the cleanup code for you? My

Post by Peter Young
experience is limited to C, so I apparently I'm not giving C++ its due. In

C, memory allocation and deallocation is half

Post by Peter Young
the battle. VB just about eliminates that for you (as do most modern languages).

The pointer as a local variable takes 4 bytes on the stack, which is gone
when the function exits.

In past jobs, much of my life (C++ troubleshooting) has been devoted to
fixing other people's memory leaks. No doubts about it. I might have even
had one or two of my own :-). First off, I can see how VB makes the memory
issue less-so is by re-asigning the same reference to something new...

dim o as Object
set o = New Object
set o = New Object ' deallocates the first

Doing something like this with a pointer would be a permanent leak in C++.
Also, as far as using the stack instead of the heap is a matter of
programming practices. I could have coded Foo another way...

Variant Foo()
{
Collection * c; ' just a pointer, no object creation here
Object * pObj; ' just another pointer
c = New Collection; ' object allocated on heap
pObj = c; ' no allocation here, just another pointer
} ' exits with c still allocated, and nobody has a pointer to it
' this would be fixed by adding: delete c; or delete pObj; at the end

Another thing I have become accustomed to in C++ is memory checking code or
tools. I've seen a couple of in-house memory management libraries, each of
which had the responsibility of overriding New and Delete (or equivalent),
and keeping track of allocations and deletions, and providing a report of
leaks at the end of execution. Actually, Visual C++ has heap checking built
right into it as well. Of course, the leak still has to be located. Now
this goes back a bit, but I recall OS/2 having a unique memory tool - a
thing called Theseus. It would show blocks of memory allocated in a
process - and which module did the allocation! (some complications can
arise) But I was able to find a leak in another companies DLL that I didn't
have the source for, in a process that my DLLs were running in. I think I
can see a way to do this for Windows processes, but maybe someone already
has. It would involve creating mapping DLL(s) by the same name as Windows
DLL(s), renaming the windows DLL(s), passing calls through to them,
gathering info from the stack, etc, and recording where the allocations are
coming from. Could be very cool? It could produce which module, the code
address, how many bytes allocated, and a trace log.

I think the other major advantage with VB is handling all of it's intrinsic
objects internally. The C++ equivalent might be having to manually
create/destroy objects that otherwise just aren't there. The VB environment
has alot under the hood.

It's an interesting comparison, now that we're going into this much detail.
It occurs to me that VB, with automatically shellable class Init/Term
methods is simplified, serialization-like, and helps. Like more natural to
code properly.

Also, in your example, when your reference pops off the stack, the object it
references (heap) is also destroyed. VB doesn't use pointers, which have
been regarded as one of the foremost tools for blowing your leg off. In my
two examples, one puts the object on the stack, and the other on the heap,
so the programmer has more of an ability to create leaks and other problems
by using pointers. I see the relative confusion-creating power here. In my
first example, pObj does not coorespond to a heap allocation. In my second
example, c does refer to a heap allocation. Each is a pointer. It is not
so straightforward as to which pointers do and do not have to be deleted.

A bit of typing and thinking, but I think there it is! I'll have to
consider a C++ convention (perhaps naming?) for making what needs to be
deleted more distinct. ;-)

Or, in VB or C++, just delete freakin everything.

The Java garbage collector is frequently misunderstood, misconfigured, and
underrated, but it's come a long way. Java apps freeze at times from
full-sweep garbage collections when the settings aren't as they should be.
Also it's profiler re: speed. Ok, I digress, but I have to admit, some of
the Java complaints, such as freeze-ups or performance, have been mitigated
pretty well. This is a garbage collector in the truest sense of the word.
I guess I'd have to say it is references in general that stand out as an
improvement over pointers.

- Mark

Peter Young

2004-06-30 22:07:29 UTC

Wow, you go Mark. <g>

Clearly, I've forgotten too much C to be very effective - yes the pointer would drop off the stack. My point though was
made better by you - having to manually allocate and deallocate, needing to recognize which pointer is which, etc., is
all just a drag. VB nicely mitigates so much boiler-plate code and isn't that what we want computers to do for us?
Automate the repeatable. Abstract the hardware as much as possible. VB is very high level which I like.

-Pete

Post by Peter Young
Well, even a pointer takes 4 bytes. Are you saying the C++ compiler is

generating the cleanup code for you? My

Post by Peter Young
experience is limited to C, so I apparently I'm not giving C++ its due. In

C, memory allocation and deallocation is half

Post by Peter Young
the battle. VB just about eliminates that for you (as do most modern

languages).
The pointer as a local variable takes 4 bytes on the stack, which is gone
when the function exits.
In past jobs, much of my life (C++ troubleshooting) has been devoted to
fixing other people's memory leaks. No doubts about it. I might have even
had one or two of my own :-). First off, I can see how VB makes the memory
issue less-so is by re-asigning the same reference to something new...
dim o as Object
set o = New Object
set o = New Object ' deallocates the first
Doing something like this with a pointer would be a permanent leak in C++.
Also, as far as using the stack instead of the heap is a matter of
programming practices. I could have coded Foo another way...
Variant Foo()
{
Collection * c; ' just a pointer, no object creation here
Object * pObj; ' just another pointer
c = New Collection; ' object allocated on heap
pObj = c; ' no allocation here, just another pointer
} ' exits with c still allocated, and nobody has a pointer to it
' this would be fixed by adding: delete c; or delete pObj; at the end
Another thing I have become accustomed to in C++ is memory checking code or
tools. I've seen a couple of in-house memory management libraries, each of
which had the responsibility of overriding New and Delete (or equivalent),
and keeping track of allocations and deletions, and providing a report of
leaks at the end of execution. Actually, Visual C++ has heap checking built
right into it as well. Of course, the leak still has to be located. Now
this goes back a bit, but I recall OS/2 having a unique memory tool - a
thing called Theseus. It would show blocks of memory allocated in a
process - and which module did the allocation! (some complications can
arise) But I was able to find a leak in another companies DLL that I didn't
have the source for, in a process that my DLLs were running in. I think I
can see a way to do this for Windows processes, but maybe someone already
has. It would involve creating mapping DLL(s) by the same name as Windows
DLL(s), renaming the windows DLL(s), passing calls through to them,
gathering info from the stack, etc, and recording where the allocations are
coming from. Could be very cool? It could produce which module, the code
address, how many bytes allocated, and a trace log.
I think the other major advantage with VB is handling all of it's intrinsic
objects internally. The C++ equivalent might be having to manually
create/destroy objects that otherwise just aren't there. The VB environment
has alot under the hood.
It's an interesting comparison, now that we're going into this much detail.
It occurs to me that VB, with automatically shellable class Init/Term
methods is simplified, serialization-like, and helps. Like more natural to
code properly.
Also, in your example, when your reference pops off the stack, the object it
references (heap) is also destroyed. VB doesn't use pointers, which have
been regarded as one of the foremost tools for blowing your leg off. In my
two examples, one puts the object on the stack, and the other on the heap,
so the programmer has more of an ability to create leaks and other problems
by using pointers. I see the relative confusion-creating power here. In my
first example, pObj does not coorespond to a heap allocation. In my second
example, c does refer to a heap allocation. Each is a pointer. It is not
so straightforward as to which pointers do and do not have to be deleted.
A bit of typing and thinking, but I think there it is! I'll have to
consider a C++ convention (perhaps naming?) for making what needs to be
deleted more distinct. ;-)
Or, in VB or C++, just delete freakin everything.
The Java garbage collector is frequently misunderstood, misconfigured, and
underrated, but it's come a long way. Java apps freeze at times from
full-sweep garbage collections when the settings aren't as they should be.
Also it's profiler re: speed. Ok, I digress, but I have to admit, some of
the Java complaints, such as freeze-ups or performance, have been mitigated
pretty well. This is a garbage collector in the truest sense of the word.
I guess I'd have to say it is references in general that stand out as an
improvement over pointers.
- Mark

Ken Halter

2004-06-30 16:22:30 UTC

Mark G. Meyers wrote:

Bottom line is you're working too hard. VB already takes care of most of
the things you want to add.

Post by Mark G. Meyers
BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage. And
what is the difference between 'friend' and 'public' exactly? Nice lack of

As Peter said, Friend is the same as Public but only within the current
project.

Post by Mark G. Meyers
static class members! And thanks be to inheritence through encapsulation.
How about that 'feature' where variables don't have to be declared - by

Well.. you can always set the IDE option that places Option Explicit at
the top of each new module.. I wouldn't leave home without it.

Post by Mark G. Meyers
default. I would have thought that one to pass us by, say, 15 years ago (or
maybe when I coded in Dartmouth S-BASIC 25 years ago, which did require one

Until .Net was release, it was important to support legacy code.

Post by Mark G. Meyers
to do so). Boy, do I have a pet peeve or two with this language. In this
case, we got New, and we got no Delete. Ever see your COM subsystem just

Nothing is all you'll ever need to "Delete" an object. If it doesn't go
away, there's unresolved problems within (like circular references)

Post by Mark G. Meyers
lock up on you, and applications become unstable? Lest we avoid ActiveX or
DCOM for security purposes. Oh, and I benchmarked pipes vs COM for
inter-proces communications a few years ago on a Win2K box. The pipes were
only 70,000 times faster...
...END RANT

Then.... use pipes if you want. The info's available in the MSKB

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

Mark G. Meyers

2004-06-30 17:32:12 UTC

Post by Ken Halter
Bottom line is you're working too hard. VB already takes care of most of
the things you want to add.

Post by Mark G. Meyers
BEGIN RANT...
I think VB doesn't offer garbage collection as much as it does garbage.

And

Post by Ken Halter

Post by Mark G. Meyers
what is the difference between 'friend' and 'public' exactly? Nice lack of

As Peter said, Friend is the same as Public but only within the current
project.

Post by Mark G. Meyers
static class members! And thanks be to inheritence through

encapsulation.

Post by Ken Halter

Post by Mark G. Meyers
How about that 'feature' where variables don't have to be declared - by

Well.. you can always set the IDE option that places Option Explicit at
the top of each new module.. I wouldn't leave home without it.

Post by Mark G. Meyers
default. I would have thought that one to pass us by, say, 15 years ago (or
maybe when I coded in Dartmouth S-BASIC 25 years ago, which did require one

Until .Net was release, it was important to support legacy code.

Hello. Regarding the above, didn't know about the IDE setting (thanks!) -
I'm just an amateur, but, really, is this setting not turned on because of
legacy support? Old EXEs don't break, right? And on that matter, what made
XP or .NET or whatever something that could break old things in the IDE, and
not this? Really, it's not like we're talking about a massive migration hit
for this example. Amidst it's sheer simplicity, I don't think this scales
well against developments in structured programming practices over the
years.

Frankly, I never coded a module without Option Explicit, but, I've had at
least one programmer do it because of forgetting or not really understanding
the need. I've seen another make the mistake of modifying the caller's
primitive (default ByRef). It kind of freaked him out. Frankly, I would
have guessed the basic types to default to ByVal, but I don't really care
much about it. I just as a matter of habit don't modify the caller's vars,
except with object refs, as they are coded to protect themselves. My only
exceptions are quite rare, and well documented as to their
passing-pointers-like behavior where they happen.

Post by Ken Halter

Post by Mark G. Meyers
to do so). Boy, do I have a pet peeve or two with this language. In this
case, we got New, and we got no Delete. Ever see your COM subsystem just

Nothing is all you'll ever need to "Delete" an object. If it doesn't go
away, there's unresolved problems within (like circular references)

Right! Unresolved problems within - that's the crux of it.

-Mark

Ken Halter

2004-06-30 19:48:37 UTC

Post by Mark G. Meyers
Hello. Regarding the above, didn't know about the IDE setting (thanks!) -
I'm just an amateur, but, really, is this setting not turned on because of
legacy support? Old EXEs don't break, right? And on that matter, what made
XP or .NET or whatever something that could break old things in the IDE, and

That's what we've been asking (and ranting about) since .Net's release
<g> and there's at least one "groupie" around here that says "XPs not
done until VB won't run".

Language Stability
http://www.mvps.org/vb/index2.html?tips/stability.htm

Visual Fred
http://www.mvps.org/vb/index2.html?rants/vfred.htm

Post by Mark G. Meyers
not this? Really, it's not like we're talking about a massive migration hit
for this example. Amidst it's sheer simplicity, I don't think this scales
well against developments in structured programming practices over the
years.

Developers expected to be able to load just about any code that can be
considered "MS Basic" and run it largely unchanged.. which is why the
End statement (and others like it) were preserved even though it's never
recommended that you use End.

There should be an option to add Option Explicit to existing modules
automatically but it doesn't look like it was a priority. I assume, this
was mostly because VB programs were considered "throw away" by quite a
few people in high places.

Post by Mark G. Meyers
Frankly, I never coded a module without Option Explicit, but, I've had at
least one programmer do it because of forgetting or not really understanding

You'll find quite a few sample projects on the web that don't have
Option Explicit. I ran into so many that, instead of adding it and
fixing the missing declarations, I just toss the sample in the bit bucket.

Post by Mark G. Meyers
the need. I've seen another make the mistake of modifying the caller's
primitive (default ByRef). It kind of freaked him out. Frankly, I would
have guessed the basic types to default to ByVal, but I don't really care
much about it. I just as a matter of habit don't modify the caller's vars,
except with object refs, as they are coded to protect themselves. My only

When I started with VB, I got into the habit of creating a local copy of
arguments myself.. even if ByVal is in place. A few wasted clock cycles
vs knowing for sure I'm not messing up the callers variables. Knowing
for sure wins <g> I still do it in most cases but not always.

Post by Mark G. Meyers
exceptions are quite rare, and well documented as to their
passing-pointers-like behavior where they happen.

Same here. Pass an X/Y/Z or whatever and have them 'ready for use' when
the sub returns. VB6 has "other" ways though so I don't do that as much
either. In general, now-a-days, I'll pass an array or class to be
manipulated.

Post by Mark G. Meyers
Right! Unresolved problems within - that's the crux of it.

About 95% of the time, I'll add a few Debug.Prints to each form or
classes Initialize/Terminate event handlers and if they don't show when
I expect them to, I go hunting for the cause. Most of the time it's not
too hard to find.

If there are circular refs (I use them very rarely), I'll add a
"ReleaseRefs" (or similar) method that releases all circulars. After
that, setting the object = Nothing should show a Debug.Print in the
terminate event handler.

fwiw, VB won't allow circular refs between projects in a group but
doesn't check for circulars between compiled components... and VB6 is
harder to shutdown cleanly than VB5 was (and VB5's harder than VB3). The
newer the version, the more cleanup you need <g>

Leaving things like timers running (etc) in VB6 will send you to the
task managers 'End Task' button more often than it would've in VB5 (if
the timer event's currently running that is)

Keep popping in for answers. Most of the regulars (there are quite a
few) aren't hard to find.

Post by Mark G. Meyers
-Mark

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

Mark G. Meyers

2004-06-30 23:34:33 UTC

... and there's at least one "groupie" around here that says "XPs not
done until VB won't run".

Scary thought. To me, legacy support for EXEs is an order of scale beyond
language changes. Or is he referring to the IDE?

Language Stability
http://www.mvps.org/vb/index2.html?tips/stability.htm

Thanks for these links. "Language Stability" enjoyably employs structure.
But I'm not black and white on the matter of migration changes. Oh, APIs
for sure have to be careful - EXEs can die because of these things. But
look at it this way, I supported the ODBC API for a few years (a couple of
places), and watched as some things would get deprecated, and eventually
find their way out. That's not complete backward compatibility, but have
you considered that total backward compatibility may go too far? SQL'92 has
been tromped, albeit in more of an "every vendor now has their own SQL" kind
of way.

" Changes that break Language Stability:
.......
Changing ByRef to ByVal as default parameter behavior. Changes default
behavior established when procedures were introduced in early DOS versions
of the language. "

At some point, the position on the matter is source code migration, like
VB.NET's migration wizard, has to be exercised. A change like this could be
implemented in a migration wizard, and that would not be unorthodox to me.
Migrations are a fact of life, and when so easy to simplify, like with a
wizard, I think it can do more good than harm. On the other hand, the
matter of old things just dying without an upgrade path, or a very difficult
path, borders on the creation of....

Visual Fred
http://www.mvps.org/vb/index2.html?rants/vfred.htm

That is not insignificant! Golly, no MsgBox, but, MS says;

Null values and IsNull functions are commented with an upgrade warning.
For example, the following code:
If x Is Null Then MsgBox "Null"
is upgraded to:
' UPGRADE_WARNING: Use of IsNull() detected
If IsDBNull(x) Then MsgBox "Null"

Well, the name Fred sounds like a great idea.

Yes, it is flooring to read. VB6 can't be that much "end of life" (like
that individual you were talking about), or that would leave an awful lot of
people hanging.

That presents to me the interesting note of VB developer expectations that
one may consider as varying in degree from other compilers or interpreters.
The most remarkable backward compatibility effort I have seen was on the
Mac, when moving from 680x0 chips to PowerPC chips.

There should be an option to add Option Explicit to existing modules
automatically but it doesn't look like it was a priority. I assume, this
was mostly because VB programs were considered "throw away" by quite a
few people in high places.

I don't quite understand this. If "throw away", then can't a simple change
like this be made without a fuss? I don't feel like old VB programs should
be regarded as "throw away".

I have to get me a bit bucket. Does that help?

Ah. The habit for me developed working with pointers and such passed in
(C++). Pointing to strange places, and causes wierd bugs. I guess I just
developed the mental habit of not altering args. (I'm very
maintenance/troubleshooting oriented at this point - it's the L3 support
conditioning). Folks who write miles of new code (that I have to support)
should have to fix a mile or two first!

Post by Mark G. Meyers
Right! Unresolved problems within - that's the crux of it.

About 95% of the time, I'll add a few Debug.Prints to each form or
classes Initialize/Terminate event handlers and if they don't show when
I expect them to, I go hunting for the cause. Most of the time it's not
too hard to find.
If there are circular refs (I use them very rarely), I'll add a
"ReleaseRefs" (or similar) method that releases all circulars. After
that, setting the object = Nothing should show a Debug.Print in the
terminate event handler.
fwiw, VB won't allow circular refs between projects in a group but
doesn't check for circulars between compiled components... and VB6 is
harder to shutdown cleanly than VB5 was (and VB5's harder than VB3). The
newer the version, the more cleanup you need <g>

You know, as a profound matter of approach, I've been pretty stubborn about
this circular references thing. Like my liberties have been taken away.
But when you say, "VB won't allow circular refs between projects in a
group", that's a pretty strong case, (amongst other things said), for me to
drop it. And perhaps to come to realize I'm being a bit stubborn.

Keep popping in for answers. Most of the regulars (there are quite a
few) aren't hard to find.

I like it here! USENET and MVPs are MS developer's biggest boon.

Thx much -
Mark

Ken Halter

2004-07-01 17:06:38 UTC

... and there's at least one "groupie" around here that says "XPs not
done until VB won't run".

Scary thought. To me, legacy support for EXEs is an order of scale beyond
language changes. Or is he referring to the IDE?

No... unfortunately, the apps written in VB.

Subject: Life and death (XP sp2)
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=5d95d02094f263b9

Subject: Plea for help with SP2 issues!
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=958e9b5bdeee4d30

Post by Mark G. Meyers
Thanks for these links. "Language Stability" enjoyably employs structure.
But I'm not black and white on the matter of migration changes. Oh, APIs
for sure have to be careful - EXEs can die because of these things. But
look at it this way, I supported the ODBC API for a few years (a couple of
places), and watched as some things would get deprecated, and eventually
find their way out. That's not complete backward compatibility, but have
you considered that total backward compatibility may go too far? SQL'92 has

You're right... "total" backward compatibility would be too much to ask.
We'd like to at least have a little of our code back though <g>

The upgrade wizard in VB.Net is a joke. All its good for (imo) is
converting specific snips of code. Apps still need to be re-written due
to all of the changes.

File I/O methods (for example) that have been around since pre-GW (DOS)
Basic days were ripped out by the roots. If you pass a program that
contains things like....

Open "MyFile" For Output As SomeNumber

...to that "thing" called a VB.Net upgrade wizard, it just adds a
comment that says something like "no such functionality is available in
the .Net framework" and just leaves it at that.

imo, it should add another comment that states "we know what you're
trying to accomplish (open a file for output) but we choose not to help
you since you're not using the language of the day. Please fire up a
search engine and find the info yourself"

Post by Mark G. Meyers
been tromped, albeit in more of an "every vendor now has their own SQL" kind
of way.
.......
Changing ByRef to ByVal as default parameter behavior. Changes default
behavior established when procedures were introduced in early DOS versions
of the language. "
At some point, the position on the matter is source code migration, like
VB.NET's migration wizard, has to be exercised. A change like this could be
implemented in a migration wizard, and that would not be unorthodox to me.
Migrations are a fact of life, and when so easy to simplify, like with a
wizard, I think it can do more good than harm. On the other hand, the
matter of old things just dying without an upgrade path, or a very difficult
path, borders on the creation of....

Visual Fred
http://www.mvps.org/vb/index2.html?rants/vfred.htm

That is not insignificant! Golly, no MsgBox, but, MS says;
Null values and IsNull functions are commented with an upgrade warning.
If x Is Null Then MsgBox "Null"
' UPGRADE_WARNING: Use of IsNull() detected
If IsDBNull(x) Then MsgBox "Null"
Well, the name Fred sounds like a great idea.

Anything but VB! I'd like to see it called B# myself... and that's not
putting the product down in anway (any more than calling C.Net C# does).

It *does* have quite a few cool features but it's an entirely new
language that happens to share a few keywords with VB. An entirely new
language needs a new name.

Calling it VB (imo) was a dishonest attempt to lure VB programmers. Some
people love it, others won't even consider it. I know we'll never use it
here where I work.
We have way too much legacy code that we still need to support.
"upgrading" all of our code to .Net would take centuries <g> especially
the stuff for the medical industry.
We need to do about 2 pages of paperwork for each minor change we do to
an app.... and then have it tested/certified by an outside firm. I can't
imagine doing that with all of our code. What a nightmare!.. and that's
just to get it migrated... without any "benefits" that the .Net
framework might provide.

Post by Mark G. Meyers
Yes, it is flooring to read. VB6 can't be that much "end of life" (like
that individual you were talking about), or that would leave an awful lot of
people hanging.

A lot of the "hanging" people have decided to move to Borland's
Delphi... including the author of that "stability" page.

Subject: where do us long time VBers move on to?
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=d064e9cc67ae94a0&rnum=1

quite a few others have switched to C#. All I've done is "play" with
either language (C#/B#) so whatever I learn will soon be forgotten.

Post by Mark G. Meyers
That presents to me the interesting note of VB developer expectations that
one may consider as varying in degree from other compilers or interpreters.
The most remarkable backward compatibility effort I have seen was on the
Mac, when moving from 680x0 chips to PowerPC chips.

Motorola assembler language is a thing of beauty <g> I "cut my assembler
language teeth" on a 6809e.

I don't quite understand this. If "throw away", then can't a simple change
like this be made without a fuss? I don't feel like old VB programs should
be regarded as "throw away".

Most VB devs don't consider their code throw-away either.. it's the 'Big
Wigs' at MS that do.. If it were true that VB code was basically
'Vaporware' then no one would be complaining <g>

I have to get me a bit bucket. Does that help?

Bit buckets are a very handy thing to have ;-)

I've been an MS Basic junky since '81 and never did get into the C
language for some reason (sometimes I wish I did). If I needed speed, I
had assembler, if I needed RAD (as rad as basic was in '81 <g>), I used
Basic. Mixed the two for quite a few apps. C just never made its way on
to my computer. I'm considering taking a class or two on C# in the near
future.

fwiw, VB won't allow circular refs between projects in a group but
doesn't check for circulars between compiled components... and VB6 is
harder to shutdown cleanly than VB5 was (and VB5's harder than VB3). The
newer the version, the more cleanup you need <g>

They can be a bear.. if you know how to deal with them and know what
happens when you don't do it correctly, you can get away with quite a lot.

There are plenty of 'Weak Reference' samples floating around which work
perfectly fine (with the proper care) and avoid a few of the problems
(but introduce others <g>)