Re: Is There Any Reason to Even Use VC++ Anymore?

> Contracts between the calling function and the destination functions
> work quite nicely for me.

I've used this method to, and it's pretty good. It works fine if I'm the
only one creating the code. However, getting a team to adhere to this
rigorously is prone to error. And this is complicated due to what I think is
a bug in the new VS C++.NET 2005 (Express). I reported it here:

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=ef3c8d9e-75e2-4916-87ee-640a4de75f39

Turns out if you use a reference (or value) parameter in a method that only
accepts a pointer it will still compile! Thus, the convention of using a
pointer if you own it and a reference if owned externally is broken (not
your fault!) since both a pointer and a reference are accepted by a method
asking for a pointer! I hope this isn't considered a 'feature' by MS...

> I tend to shun away from using lists of pointers, and generally don't
> have that big of a problem with it.

How do you deal with variable length lists? Imagine a picture editor. Would
you set a limit as to how many pictures can be editted at a time, and keep
all instances of them around regardless of how many you will actually need?
It is probably better to keep a dynamic list of pointers to each of the
pictures being editted. This extends to many situations where the
application can't know ahead of time how many of something it will need,
especially if this number is only limited by available memory or dictated
by the end-user...

> I just go with the philosophy of
> the allocator owns the pointer, unless it calls another function which
> always assumes ownership of the allocated pointer, and that the owner
> is responsible for freeing the memory

> Can you give an example where memory would have to be allocated prior
> to the function, but the function would require both pass-through and
> delete functionality that the calling function could not provide?

I'll try. Consider this scenario. A is created. A creates X (allocation). B
is created. B shares X (not a duplicate). What should B do when it is
destroyed? It doesn't know if A still exists, so it can't destroy X. But if
A HAS already been destroyed, then when B is destroyed there is nothing left
to destroy X, so X becomes a memory leak.

Note that A is the allocator of X, but can't be the destroyer if A goes away
before B. And B can't be the destroyer, since it doesn't know if A is still
around when B is destroyed. And even if B somehow knows A has already been
destroyed, B doesn't know if A also shared X with C. If B destroys X and C
exists, C will complain. If B doesn't destroy X and C doesn't exist, X
becomes a memory leak. And what about the possiblity of the existence of
other sharer's of X such as D, E, F. G, H,...?

Only at the application level can it be determined that there is NOTHING in
the application still using X, and so the application is the only thing that
can safely destroy X. That, in a nutshell, is garbage collection! : )

[==P==]

"Josh McFarlane" <darsant@xxxxxxxxx> wrote in message
news:1133989686.823977.205650@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Peter Oliphant wrote:
>> > Honestly why use gc at all? Never got why people felt the need for a
>> > garbage collector.
>> Now, how can the class know whether the instance has further use
>> externally?
>> Answer: in general, it can't! A class, is typically unaware of the
>> environment it is in, since many classes are designed for re-usability in
>> DIFFERENT environments.
>
> Contracts between the calling function and the destination functions
> work quite nicely for me.
>
> If I require an object in a function, I use a reference.
>
> If, for some reason, the object needs to be worried about the life of
> the object (Such as a "message" being passed), I make that a condition
> of the function if it is the end-point and destroy the object.
>
> If, for another reason, the calling function needs to allocate memory,
> call a 2nd function, and then is done with the memory, it is up to the
> calling function to remove the memory from play.
>
>> An example. Say a class is responsible for displaying the color of an
>> object
>> representing a toy ball. It does this by taking a pointer to a ball
>> object
>> and displaying its color. Now, here's the problem. The caller could have
>> passed a pointer to the instance of the ball itself, or a COPY of this
>> instance. In the first case, the instance should not be destroyed. In the
>> second case, the instance passed MUST be destroyed. But the class has no
>> idea which case is true for any particular call!
>
> If the function is responsible for drawing the ball, it should be up to
> the caller function to determine whether or not the allocated object is
> through. I mean granted it's around for another cycle or two until you
> hit the delete function, but the cost is negligible.
>
> I tend to shun away from using lists of pointers, and generally don't
> have that big of a problem with it. I just go with the philosophy of
> the allocator owns the pointer, unless it calls another function which
> always assumes ownership of the allocated pointer, and that the owner
> is responsible for freeing the memory.
>
> Can you give an example where memory would have to be allocated prior
> to the function, but the function would require both pass-through and
> delete functionality that the calling function could not provide?
>


.

Relevant Pages

  • Re: I want my segmentation fault!
    ... no occurrences of free and a lot of routines returning pointers to ... the pointer returned by the allocator (either directly or as a component ... calls another routine to free the pointer. ... memory is really available for reuse, I'd be glad to know about it. ...
    (comp.lang.c.moderated)
  • Re: Is There Any Reason to Even Use VC++ Anymore?
    ... > It is probably better to keep a dynamic list of pointers to each of the ... > especially if this number is only limited by available memory or dictated ... It doesn't know if A still exists, so it can't destroy X. ... > Note that A is the allocator of X, but can't be the destroyer if A goes away ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Is it the BUG of VC 7.1
    ... to delete the object which the pointer pointer at. ... What makes you think that your destroy member will be called? ... your allocator, and hence your destroy won't be used. ... I check the error and find it's the problem of deque's iterator. ...
    (comp.lang.cpp)
  • Re: Trouble Destroying Modeless
    ... going to cause the storage allocator to ASSERT like crazy. ... >However, I need to destroy more than just the window, but also the ... >objects still in memory. ... MVP Tips: http://www.flounder.com/mvp_tips.htm ...
    (microsoft.public.vc.mfc)
  • Re: About transported datatypes and global memory management
    ... > Unless there is a need for a new allocator (for example when the size of a ... > are passed by pointer. ... > THe pointer is contained within the IMediaSample object. ... > It makes no sense to use the same memory all the wy through a graph. ...
    (microsoft.public.win32.programmer.directx.video)