Re: various objects in my VB6 project - Calling IUnknown

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Peter Young (youngpa_at_comcast.no.net.spam.please)
Date: 06/30/04 

Date: Wed, 30 Jun 2004 17:07:29 -0500

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

"Mark G. Meyers" <mmeyers[at]hydromilling.com> wrote in message news:u8Q9VNuXEHA.2840@TK2MSFTNGP11.phx.gbl...
> "Peter Young" <youngpa@comcast.no.net.spam.please> wrote in message
> news:Od$SzktXEHA.3112@tk2msftngp13.phx.gbl...
> > "Mark G. Meyers" <mmeyers[at]hydromilling.com> wrote in message
> news:eddEfbtXEHA.1144@TK2MSFTNGP10.phx.gbl...
> > 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).
> >
>
> 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
>
>

Relevant Pages

  • Re: What Kind of DataStructures C using? ( Heap or Tree ??)
    ... > Some were said heap, ... instructions and data is put on a stack. ... reserve memory on the heap and ... return a pointer to this memory area. ...
    (comp.lang.c)
  • Re: I feel stupid... "Invalid combination of opcode and operand", was, now is FORTH question
    ... TOS in ebx - top of stack - first stack element ... PSP in ebp - parameter stack pointer - pointer to stack, ... execute next at the end of their definition. ... High level Forth definitions merely organize the ...
    (comp.lang.asm.x86)
  • Re: using LPVOID
    ... on the heap. ... The only limitation I see is that the the stack in which the variable ... thread is using the pointer. ... stack based pointers are safe because the synchronization is ...
    (microsoft.public.vc.language)
  • Re: Help with some terminology
    ... In .NET reference type allocation is very fast, and so allocation speed is the least of the performance advantages for value types. ... Value types allocated on the stack promote locality in your code by helping to concentrate the memory footprint of your program on the top part of the stack, rather than having data scattered around the managed heap. ... Although heap allocation does have some locality in .NET due to the fact that managed heap allocations always occur at the 'end' of the heap, and large object allocations are segregated to another heap. ... For small types, passing the type value is minimally more expensive than passing a pointer, and you save both the operation and the memory read of dereferencing the pointer when accessing the value. ...
    (microsoft.public.dotnet.general)
  • Re: Linked List & Dynamic Memory Allocation
    ... Both of you mentioned stack and heap in this ... when I call malloc it uses heap to allocate memory. ... if you have an integer pointer object that lives beyond this scope and you had: ...
    (microsoft.public.vc.mfc)