Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Garbage collection in C

Reply
Thread Tools

Garbage collection in C

 
 
jacob navia
Guest
Posts: n/a
 
      08-16-2003

"Richard Heathfield" <(E-Mail Removed)> wrote in message
news:bhl2mk$1c6$(E-Mail Removed)...
> Jussi Ekholm wrote:
>
> > jacob navia <(E-Mail Removed)> wrote:
> >> There is "magic bullet" of course, I am not trying to sell you
> >> something since my compiler system is free. It is a great tool for PC
> >> applications, where there are no real time and memory constraints.

> >
> > I apologize if this is a stupid question (although, I recall someone
> > saying "there is no stupid questions, only stupid people...), but what
> > is this "magic bullet" you're talking about?

>
> Jacob, I'm sure, meant to write "there is no silver bullet".
>


Exactly. Thanks for the correction

> In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
> Silver Bullet - Essence and Accident in Software Engineering". The chapter
> is subtitled: "There is no single development, in either technology or
> management technique, which by itself promises even one order-of-magnitude
> improvement within a decade in productivity, in reliability, in
> simplicity".



 
Reply With Quote
 
 
 
 
Mark Gordon
Guest
Posts: n/a
 
      08-16-2003
On Sat, 16 Aug 2003 19:39:36 +0200
"jacob navia" <(E-Mail Removed)> wrote:

>
> "Bjorn Reese" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > jacob navia wrote:
> >
> > > #define free GC_free

> > [...]
> > > #define free(a) (a=NULL)

> >
> > What about memory allocated by third-party libraries, which was not
> > allocated using GC_malloc() and thus must be freed with free()?

>
> Memory not allocated by the collector will not be touched of course.
> External libraries work without any problems!


The point was that if the external library passes you a pointer that you
are expected to free, then after your redefinition of free the following
code fragment gives a memory leak

{
char *derf;
derf = foo(); /* foo is in library and returns pointer from malloc */
/* do some stuff */
free(derf);
}

I would also point out that if you don't have to free some dynamically
allocated memory but other pieces of dynamically allocated memory do
need freeing you (or at least I) am more likely to make a mistake and
either use the standard free on a pointer that should be left for the GC
or not call it on a pointer to memory provided (though a library) by
malloc.
--
Mark Gordon
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      08-16-2003

"Mark Gordon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> The point was that if the external library passes you a pointer that you
> are expected to free, then after your redefinition of free the following
> code fragment gives a memory leak
>
> {
> char *derf;
> derf = foo(); /* foo is in library and returns pointer from malloc */
> /* do some stuff */
> free(derf);
> }
>
> I would also point out that if you don't have to free some dynamically
> allocated memory but other pieces of dynamically allocated memory do
> need freeing you (or at least I) am more likely to make a mistake and
> either use the standard free on a pointer that should be left for the GC
> or not call it on a pointer to memory provided (though a library) by
> malloc.


Yes, this could be a problem. Fortunately libraries that pass allocated
memory expecting you to free it are very rare. This is because they can
only work with one compiler system. The "malloc" implementations are
not compatible: you can't free with gcc's free() a piece of memory allocated
with MSVC, for instance.

That's why this example is not very real. Most libraries are designed to
work with many compiler systems and do not rely on the user freeing memory.
Usually they give an interface where you call some API to free the
allocated memory.

jacob


 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      08-16-2003
On Sat, 16 Aug 2003 10:57:25 +0000 (UTC), in comp.lang.c , Richard
Heathfield <(E-Mail Removed)> wrote:

>In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
>Silver Bullet - Essence and Accident in Software Engineering". The chapter
>is subtitled: "There is no single development, in either technology or
>management technique, which by itself promises even one order-of-magnitude
>improvement within a decade in productivity, in reliability, in
>simplicity".


Like all generalisations, this one is wrong. Counterexamples:

Clean water in london wiped out cholera inside a few year
pennicilin stopped a wide range of deaths
consumer GPS in the 1990s reliably position you to within feet
and what about HTTP?

I guess you could argue that none of these is a "single development".
Hmm, in that case, nothing ever is.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      08-17-2003

On Sat, 16 Aug 2003, jacob navia wrote:
>
> "Mark Gordon" <(E-Mail Removed)> wrote ...
> > The point was that if the external library passes you a pointer that you
> > are expected to free, then after your redefinition of free the following
> > code fragment gives a memory leak
> >
> > {
> > char *derf;
> > derf = foo(); /* foo is in library and returns pointer from malloc */
> > /* do some stuff */
> > free(derf);
> > }


Simple answer: GC_free(x) can look to see if it allocated x. If it
did, it marks it for cleanup. If it didn't, it can pass x on to the
implementation's 'free' function (and kind of assume the user must
know what he's doing). Not a silver bullet, but avoids memory leaks.

> > I would also point out that if you don't have to free some dynamically
> > allocated memory but other pieces of dynamically allocated memory do
> > need freeing you (or at least I) am more likely to make a mistake and
> > either use the standard free on a pointer that should be left for the GC
> > or not call it on a pointer to memory provided (though a library) by
> > malloc.

>
> Yes, this could be a problem. Fortunately libraries that pass allocated
> memory expecting you to free it are very rare. This is because they can
> only work with one compiler system. The "malloc" implementations are
> not compatible: you can't free with gcc's free() a piece of memory allocated
> with MSVC, for instance.


Well, *if* the library is compiled with the same object file format as
the compiler's generated code, then the library function (say Strdup())
doesn't actually contain any memory management code. It just contains
a call to '_malloc' or '@_MALLOC' or whatever, and when the linker
does its magic, the '_malloc' in the library code and the '_free' in
the user code match up and everyone's happy.

Of course, last I checked you couldn't use MSVC library files with GCC
object files, so all bets are off. But it's a file format problem,
not a library problem.

> That's why this example is not very real. Most libraries are designed to
> work with many compiler systems and do not rely on the user freeing memory.
> Usually they give an interface where you call some API to free the
> allocated memory.


Strdup.

Also, I'm in the middle [or end, depending on motivation] of writing
an image-format library that has lots of functions like

int ReadPPM(const char *fname, unsigned char *(*data)[3], int *w, int *h);

for which the user is expected to call 'free' on the data pointer
when necessary:

unsigned char (*data)[3];
int w, h;
int rc = ReadPPM("input.ppm", &data, &w, &h);
if (rc < 0)
return EXIT_FAILURE;
else {
process(data, w, h);
free(data);
return 0;
}

Obviously the answer to this particular case is, "Don't use GC for
your image-format library's applications," and that's perfectly
reasonable. Just pointing out that there probably are a lot of
libraries in C for which GC would eventually be a problem.

-Arthur

 
Reply With Quote
 
Zeljko Vrba
Guest
Posts: n/a
 
      08-18-2003
In article <bhm805$gee$(E-Mail Removed)>, jacob navia wrote:
>
> Yes, this could be a problem. Fortunately libraries that pass allocated
> memory expecting you to free it are very rare. This is because they can
> only work with one compiler system. The "malloc" implementations are
> not compatible: you can't free with gcc's free() a piece of memory allocated
> with MSVC, for instance.
>

Wrong. Shared and static libraries will contain only reference to malloc
and free calls. They will be resolved only when the final program is
linked (or, in case of dynamic linking, when it is run). At that point
a single implementation of malloc will be used an all is well. As long as
MS linker can read gcc's object files (and vice-versa), there is no problem in
mixing different compilers at all.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Collection problems (create Collection object, add data to collection, bind collection to datagrid) Řyvind Isaksen ASP .Net 1 05-18-2007 09:24 AM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM
Garbage Collection kamran MCSD 1 04-04-2005 10:04 PM
Garbage Collection and Manage Code? Laser Lu ASP .Net 5 01-27-2004 03:48 AM
Debbugging help! (.NET 1.1 Framework Garbage Collection Problems) Cheung, Jeffrey Jing-Yen ASP .Net 3 07-10-2003 07:29 PM



Advertisments