I have browsed through the other GC threads and am hoping this hasn't already been answered, but what if the developer disables garbage collection and does not turn it back on just before the program exits? Is the data that should have been garbage-collected lost... "leaked"? If this has been answered, thank you to those who can point me to the relevant thread.  If it's a dumb question, then please bear with the new newbie :)
-- 
Christopher J. Sequeira '05
csequeir@mit.edu

Christopher J. Sequeira wrote:
> I have browsed through the other GC threads and am hoping this hasn't already been answered, but what if the developer disables garbage collection and does not turn it back on just before the program exits? Is the data that should have been garbage-collected lost... "leaked"? If this has been answered, thank you to those who can point me to the relevant thread.  If it's a dumb question, then please bear with the new newbie :)

No trouble. The same thing happens as when you allocate memory in a C programme and never free it. After you exit the programme, the operating system reclaims all the memory it gave the process.

Some programms, notably compilers and short-run utilities, make use of such "memory management", it is considered fairly legal since some years.

Memory leaks are only an issue for long-run code.

-i.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b0h1ou$15rl$1@digitaldaemon.com...
> Some programms, notably compilers and short-run utilities, make use of such "memory management", it is considered fairly legal since some years.

Oh, it's always been legal, and my compilers have always done it.

> Memory leaks are only an issue for long-run code.

Yup.

Walter wrote:

> "Ilya Minkov" <midiclub@8ung.at> wrote in message news:b0h1ou$15rl$1@digitaldaemon.com...
> > Some programms, notably compilers and short-run utilities, make use of such "memory management", it is considered fairly legal since some years.
>
> Oh, it's always been legal, and my compilers have always done it.
>
> > Memory leaks are only an issue for long-run code.
>
> Yup.

Correct me if I'm wrong: a side effect of this, in addition to "leaking memory", is that destructors won't be called either, right?  So a class holding some resource won't be able to run it's cleaning up destructor?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3E37A9F1.C309DA49@deming-os.org...
> Walter wrote:
>
> > "Ilya Minkov" <midiclub@8ung.at> wrote in message news:b0h1ou$15rl$1@digitaldaemon.com...
> > > Some programms, notably compilers and short-run utilities, make use of such "memory management", it is considered fairly legal since some
years.
> >
> > Oh, it's always been legal, and my compilers have always done it.
> >
> > > Memory leaks are only an issue for long-run code.
> >
> > Yup.
>
> Correct me if I'm wrong: a side effect of this, in addition to "leaking memory", is that destructors won't be called either, right?  So a class
holding
> some resource won't be able to run it's cleaning up destructor?

You're quite right. -Walter