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

Peter Oliphant wrote:
> 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...

Containers of objects. Granted, I have to sometimes have buffers that
are pointers to char arrays, can't get around that, but they're stored
in a vector of char*s for the program's document / similar class, and
maintained by the controler, rather than the called function / window
and delete'ed as the "closed" command is initiated from the window.
(Also tells the editor window depending on it to shut down and waits
for it to terminate before deleting the buffer pointer.
>
> > 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.

OK, the one thing I can think of is a shared memory space between two
processes. However, can the garbage collector know what another process
is not using said shared memory space?

Otherwise, you have two possible scenarios from this:

A is called in Thread Foo, allocates X and launches thread B.
If both access the allocated X you've got syncronization problems
already, but the safe side would be that under the assumption that B
was doing processing on X, you'd have to have some way to notify the
main application that processing was done, and that could be done by
posting a message, and that message handles management during results

> 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,...?

But then you have to ask yourself why do D, E, F, G, H need X data past
the point of when A returns?

> 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! : )

Avoiding the multi-threading issue of allowing the pointers, and
focusing on single threading for now (Feel free to let me know if you
want to discuss the multi-threading aspect of it), how do you have A be
destroyed before B - H are finished with their processing of the
pointer? If you're using the pointers for anything more than
read-conditions, you have a race issue if you're handling them with an
indeterminate order. If you are simply using them for constant reads,
why not simply make it linking to a const reference in an STL container
in the document or form?

I've just always had the view that the garbage collector is there to
allow developers to have to maintain less of a hold over their
variables. Don't worry about tracking that race condition down, it'll
all delete itself in the end.

Maybe I'm just used to all my variables having a very clear distinct
allocation time (smallest being inter-function, and longest being in
the constructor / destructor of the main window itself) who knows.

.

Relevant Pages

  • Re: Is There Any Reason to Even Use VC++ Anymore?
    ... pointer if you own it and a reference if owned externally is broken (not ... 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: 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: Worried About Alignment
    ... Why can't you use real pointers instead? ... The memory allocator in question is pointerless, ... ADTs with shared memory between multiple processes, create complex data ...
    (comp.unix.programmer)
  • Re: PostMessage and unprocessed messages
    ... way you can get the storage allocator to *ever* return memory to the operating system, ... method deletes all pending heap pointers. ...
    (microsoft.public.vc.mfc)
  • Re: Worried About Alignment
    ... Why can't you use real pointers instead? ... > chunk of memory backing the allocator. ... What you use for the offsets doesn't matter, as long as the range is ...
    (comp.unix.programmer)
Loading