Memory management question

[sbayeta]

Hi,
I'd like to know who is responsible of memory recycling and
defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.

Thanks

[Gordon Burditt]

>I'd like to know who is responsible of memory recycling and

defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.

The Internal Revenue Service. And they'll bill you for it.
But they may have subcontracted the job out to Bill Gates.

There is no language C/C++.

If the above wasn't the answer you wanted, what kind of answer
did you expect?

Gordon L. Burditt

[jacob navia]

"Mark A. Odell" <no****@embeddedfw.com> wrote in message
news:Xn**************************************@130. 133.1.4...

sb*****@hotmail.com (sbayeta) wrote in
news:80**************************@posting.google.c om:

Hi,
I'd like to know who is responsible of memory recycling and
defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.
There is no C/C++ language. There is C which we discuss here. So from a C
point of view there is no automatic memory recycling.

Wrong.

If I write:
int fn(void) {
char *a = malloc(100);
free(a);
return 0;
}

I expect that a reasonable implementation recycles the memory the best it can and my memory
consumption doesn't increase exponentially, sorry. I suppose that if I free a pointer, the memory
will be RECYCLED by the malloc/free system and the total memory consumption will not increase.

Of course I know that many implementations of malloc/free do not actually return the RAM to the OS
but recycle it for new requests. This is also a recycling strategy, sometimes more efficient
sometimes not.

But to say that there is no recycling in the malloc/free cycle (pun intended) is WRONG. If there was
no recycling why would we bother to call free() ?????

You malloc() the
memory and you must free it properly when done with it.
Yes. To be able to recycle it of course!
If this
process fragments memory over time, it's too bad as C does not do any
garbage collection.

I would be surprised that the algorithms (known for decades) to avoid fragmentation wouldn't have
gotten into many malloc() implementations. They are quite sophisticated beasts. Of course it depends
of the quality of the run-time library, but most of them are very good quality stuff. Gcc for
instance has a quite good library.

Look Mark. There was recently a discussion (that I started, provocatively as a "spam" message :-)
about the GC.
Now this question touches the same thema again, and you feel that the wrong party line is
insinuating somewhere.

And you loose control Mark. You say nonsense. How can you imagine that there is no recycling in C? I
mean those are the very basics.

jacob

[jacob navia]

"sbayeta" <sb*****@hotmail.com> wrote in message
news:80**************************@posting.google.c om...

Hi,
I'd like to know who is responsible of memory recycling and
defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.

Thanks

In C, memory recycling is done by the malloc/free system.
The malloc function allocates a new pointer, and free, releases it.

It is up to the implementation to recycle the memory, and many of
them have built sophisticated systems to avoid fragmentation, check
memory leaks, etc. Others aren't so good, sometimes they are slow and
may have bugs.

This system is very modular and can be easily replaced by your own
functions or another, non standard allocator.

But let's not start that discussion again :-)

jacob

[Mark A. Odell]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in
news:bh**********@news-reader1.wanadoo.fr:

> I'd like to know who is responsible of memory recycling and
> defragmentation in a C/C++ program, assuming all the memory
> allocation/deallocation is done using malloc/free or new/delete.
There is no C/C++ language. There is C which we discuss here. So from a
C point of view there is no automatic memory recycling.

Wrong.

If I write:
int fn(void) {
char *a = malloc(100);
free(a);
return 0;
}

I expect that a reasonable implementation recycles the memory the best
it can and my memory consumption doesn't increase exponentially, sorry.

You've already killed your argument by saying a "reasonable
implementation" since that has nothing to do with what ISO C says. ISO C
doesn't say what an implementation, reasonable or otherwise must do with
free()'d memory.
I suppose that if I free a pointer, the memory will be RECYCLED by the
malloc/free system and the total memory consumption will not increase.
No, it just goes back into the available memory pool for subsequent
malloc's.
Of course I know that many implementations of malloc/free do not
actually return the RAM to the OS but recycle it for new requests. This
is also a recycling strategy, sometimes more efficient sometimes not.

But to say that there is no recycling in the malloc/free cycle (pun
intended) is WRONG. If there was no recycling why would we bother to
call free() ?????
Oh it goes back into the free list but it doesn't mean that you won't
fragment memory over time.

If this
process fragments memory over time, it's too bad as C does not do any
garbage collection.

I would be surprised that the algorithms (known for decades) to avoid
fragmentation wouldn't have gotten into many malloc() implementations.

Again with the implementation, where in the ISO C spec. does it say
malloc/free must use power of two allocators or any such thing?
They are quite sophisticated beasts. Of course it depends of the quality
of the run-time library, but most of them are very good quality stuff.
Gcc for instance has a quite good library.
All off-topic platform-specific then.
Look Mark. There was recently a discussion (that I started,
provocatively as a "spam" message :-) about the GC.
Now this question touches the same thema again, and you feel that the
wrong party line is insinuating somewhere.

And you loose control Mark. You say nonsense. How can you imagine that
there is no recycling in C? I mean those are the very basics.

I've never actually seen such a term in the pages of the spec. I've read.
Dan? Comment?

--
- Mark ->
--

[Mark A. Odell]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in
news:bh**********@news-reader3.wanadoo.fr:

I'd like to know who is responsible of memory recycling and
defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.

Thanks
In C, memory recycling is done by the malloc/free system.
The malloc function allocates a new pointer, and free, releases it.

Correct.
It is up to the implementation to recycle the memory, and many of
them have built sophisticated systems to avoid fragmentation, check
memory leaks, etc. Others aren't so good, sometimes they are slow and
may have bugs.

Correct, it's up to the *implementation* and is *not* dictated by the C
language thus do *not* depend on malloc/free to avoid fragmentation.

--
- Mark ->
--

[Irrwahn Grausewitz]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in
<bh**********@news-reader1.wanadoo.fr>:

"Mark A. Odell" <no****@embeddedfw.com> wrote in message
news:Xn**************************************@130 .133.1.4...

sb*****@hotmail.com (sbayeta) wrote in
news:80**************************@posting.google.c om:

> Hi,
> I'd like to know who is responsible of memory recycling and
> defragmentation in a C/C++ program, assuming all the memory
> allocation/deallocation is done using malloc/free or new/delete.
There is no C/C++ language. There is C which we discuss here. So from a C
point of view there is no automatic memory recycling.

Wrong.

So, if automatic memory recycling is a built in feature of
standardized C, what was this "Garbage Collection in C" thread
good for then?

If I write:
int fn(void) {
char *a = malloc(100);
free(a);
return 0;
}

I expect that a reasonable implementation recycles the memory the best it can and my memory
consumption doesn't increase exponentially, sorry. I suppose that if I free a pointer, the memory
will be RECYCLED by the malloc/free system and the total memory consumption will not increase. Maybe. Maybe not. You're expexting, guessing, supposing. What if
I'm just about to finish a conforming C implementation that
physically burns free()'d memory for security reasons? Is this
impossible?

[OT]
And please, please cut down your line length, your posts are
messing up my newsreader...

0 1 2 3 4 5 6
01234567890123456789012345678901234567890123456789 01234567890123456789
[/OT]

Of course I know that many implementations of malloc/free do not actually return the RAM to the OS
but recycle it for new requests. This is also a recycling strategy, sometimes more efficient
sometimes not. So, who is responsible for reclaiming free()'d memory then?

But to say that there is no recycling in the malloc/free cycle (pun intended) is WRONG. If there was
no recycling why would we bother to call free() ????? To let the implementation do whatever it does with free()'d
memory...

You malloc() the
memory and you must free it properly when done with it.
Yes. To be able to recycle it of course!

See above. Maybe it's recycled for further use. Maybe not.
(Whereas you're right in that *probably* *most* implementations
will do so.)

If this
process fragments memory over time, it's too bad as C does not do any
garbage collection.
I would be surprised that the algorithms (known for decades) to avoid fragmentation wouldn't have
gotten into many malloc() implementations. They are quite sophisticated beasts. Of course it depends
of the quality of the run-time library, but most of them are very good quality stuff. Gcc for
instance has a quite good library.

Right, *many implementations* will do so. Got the point?

Look Mark. There was recently a discussion (that I started, provocatively as a "spam" message :-)
about the GC.
Now this question touches the same thema again, and you feel that the wrong party line is
insinuating somewhere. Starting it all over again... *g*

And you loose control Mark. You say nonsense. How can you imagine that there is no recycling in C? I
mean those are the very basics.

IMHO Mark is perfectly right. You are the one who's generalizing
the behaviour of some implementations to be the one and only way
to do things. Basically, I *can* imagine C without memory
recycling. ( Maybe there's a lack of imaginational potential on
your side? *g* )
Ooooops, I just stumbled over this (from the N843 draft):
-----
7.20.3.2 [...] [#2] The free function causes the space pointed
to by ptr to be deallocated, that is, made available for
further allocation.
-----

Maybe I was totally wrong

That's why I call for the experts now - please help.
Irrwahn

--
If you can see it and it’s there - it’s real.
If you can’t see it, but it’s there - it’s transparent.
If you can see it but it isn’t there - it’s virtual.
If you can’t see it and it isn’t there - it’s gone.

[Gordon Burditt]

>So, if automatic memory recycling is a built in feature of

standardized C, what was this "Garbage Collection in C" thread
good for then?
Automatic memory recycling is re-using freed memory.
Garbage collection is re-using non-freed memory when (hopefully)
it is no longer in use.
Maybe. Maybe not. You're expexting, guessing, supposing. What if
I'm just about to finish a conforming C implementation that
physically burns free()'d memory for security reasons? Is this
impossible?
The clause in ANSI C about making the memory available for later
allocation would seem to prohibit this. Some claim it also
prohibits releasing it back to the OS if there is any possibility
that the OS would give it to some other process and refuse
a request to get it back to the one that released it. The really
pedantic ones insist that it has to be willing to give back
the *SAME* *PHYSICAL* *MEMORY* before it can claim it ran out.
Ooooops, I just stumbled over this (from the N843 draft):
-----
7.20.3.2 [...] [#2] The free function causes the space pointed
to by ptr to be deallocated, that is, made available for
further allocation.
----- So, who is responsible for reclaiming free()'d memory then?

There is no WHO in this discussion. malloc()/free() is not alive.
ANSI C is not alive. Laidlaw of Benbrook has no contract for
cyberspace. I guess it defaults to Bill Gates or the IRS.

As far as defragmentation goes, it is nearly impossible in C to
move around *ALLOCATED* pieces of memory without breaking something.
This is made particularly a problem by the fact that pointers (which
would require moving if you move the data they point at, but only
if they really are intended as pointers) can be hidden in files or
encrypted in memory.

Gordon L. Burditt

[Irrwahn Grausewitz]

go***********@sneaky.lerctr.org (Gordon Burditt) wrote in
<bh********@library2.airnews.net>:

<BIG SNIP>

So, who is responsible for reclaiming free()'d memory then?

There is no WHO in this discussion. malloc()/free() is not alive.
ANSI C is not alive.

Sorry for my broken english. :-)

Thank you very much for clearing things up.
--
If you can see it and it’s there - it’s real.
If you can’t see it, but it’s there - it’s transparent.
If you can see it but it isn’t there - it’s virtual.
If you can’t see it and it isn’t there - it’s gone.

[jacob navia]

> You've already killed your argument by saying a "reasonable

implementation" since that has nothing to do with what ISO C says. ISO C
doesn't say what an implementation, reasonable or otherwise must do with
free()'d memory.
The standard says
(I quote page 312, free() definition)

The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation.

end quote

Next allocations will recycle the memory freed!

I suppose that if I free a pointer, the memory will be RECYCLED by the
malloc/free system and the total memory consumption will not increase.

No, it just goes back into the available memory pool for subsequent
malloc's.

And this is not recycling Mark?
I mean what are you trying to achieve? Confusion?

jacob

[Mark A. Odell]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in
news:bh**********@news-reader2.wanadoo.fr:

You've already killed your argument by saying a "reasonable
implementation" since that has nothing to do with what ISO C says. ISO
C doesn't say what an implementation, reasonable or otherwise must do
with free()'d memory.
Hmm... I should have continued by saying "except that the free'd memory
can now be malloc'd again".

The standard says
(I quote page 312, free() definition)

The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation.

end quote

Next allocations will recycle the memory freed!

Okay I can't argue with that definition of recycling memory. I didn't mean
to imply that once freed you couldn't remalloc that same memory region
just that if you keep malloc'ing and free'ing different sized blocks of
memory you may fragment the memory such that you begin to fail large
malloc's.

> I suppose that if I free a pointer, the memory will be RECYCLED by
> the malloc/free system and the total memory consumption will not
> increase.

No, it just goes back into the available memory pool for subsequent
malloc's.

And this is not recycling Mark?
I mean what are you trying to achieve? Confusion?

No, I just thought you were saying that C provides anti-framentation as
part of the language, which it does not.

--
- Mark ->
--

[Gordon Burditt]

>

Look. I have an automatic drive in my car. I do not feel like changing gears.

Many drivers I know though, like manually changing gears. They tell me about the
"good driving" feeling they get when they do this manually.

malloc/free require a manual interface. The driver needs to free each piece of
memory at the right point and never make a mistake. Many of them tell that
with a good discipline this is possible, and I must confess that before
I used a gc
I got through that too.

But now, I prefer the automatic you see? No more free(). The gc does it for me.

But, to continue the analogy, sometimes the automatic transmission
does it wrong when you're towing a trailer (hiding pointers where
the gc can't find them). Either it ruins the engine (frees memory
that should NOT be free), or it slows down horribly (spends enormous
amounts of time looking for pointers where they aren't) and takes
24 hours to get home. And there's no practical way to fix this
without putting restrictions on how you drive.

Now what happens when a one of a generation of drivers who grew up
with automatic transmissions only need to tow a trailer?

Gordon L. Burditt

[jacob navia]

"Gordon Burditt" <go***********@sneaky.lerctr.org> wrote in message
news:bh********@library2.airnews.net...

[snip]
But, to continue the analogy, sometimes the automatic transmission
does it wrong when you're towing a trailer (hiding pointers where
the gc can't find them). Either it ruins the engine (frees memory
that should NOT be free), or it slows down horribly (spends enormous
amounts of time looking for pointers where they aren't) and takes
24 hours to get home. And there's no practical way to fix this
without putting restrictions on how you drive.

Yes, but I can go farther because I am less tired you see?

Automatic driving requires less efforts from the driver and he/she
can drive longer distances!

For instance, I added the GC to the debugger/IDE of lcc-win32.

Because I do not have to write any code to cope for free() bugs or
problems, I used the saved time to improve the application itself.

I concentrated in the debugger itself, a *very* complex application.
Real time, with 3 threads running (debugger IDE, program under
debug, and debugger itself), with many complex specs to read the
debug info, messages that must be formated at each break, etc etc!

Now, I know that I can allocate a buffer whenever I need one, and
that I can pass it around without caring where I will free the stuff!!!

Debugging the debugger is difficult. Without the GC I would have been
slowed down by all those accounting chores and would have had less
time to try to improve it.

Besides, the crashes due to messing around with free would be
inacceptable. A debugger crashing, what a nightmare :-)

I spoke once with a TAXI driver (!!!) with manual driving. I told him:

Look, it doesn't hurt your hand at the end of the day?
You do not get feed up?

He admitted that it hurt a bit, but then he started telling me all
the bad things that stupid automatic drivers
do, that they do not know their vehicle etc etc.

I said nothing, payed and got out. There must be all kinds of people to
fill this world. It is his opinion. I respect it.

jacob

[Malcolm]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message

Yes, but I can go farther because I am less tired you see?

Automatic driving requires less efforts from the driver and he/she
can drive longer distances!

There is a case for using a language with automatic garbage collection.
Modern C++ with the stl is one such language.

However that language isn't C. Part of the philosophy of C is that every
statement, apart from a function call, compiles to only a few machine code
instructions. Therefore you can see where your cycles are going.

Automatic garbage collection breaks that design principle.

[Severian]

On Sat, 16 Aug 2003 00:02:21 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message

Yes, but I can go farther because I am less tired you see?

Automatic driving requires less efforts from the driver and he/she
can drive longer distances!

There is a case for using a language with automatic garbage collection.
Modern C++ with the stl is one such language.

However that language isn't C. Part of the philosophy of C is that every
statement, apart from a function call, compiles to only a few machine code
instructions. Therefore you can see where your cycles are going.

Automatic garbage collection breaks that design principle.

In many situations, neither mechanism (std malloc, GC) is appropriate.
I've had to write my own memory management routines for several
applications because of malloc's deficiencies.

- Sev

[Mark McIntyre]

On Fri, 15 Aug 2003 23:24:29 +0200, in comp.lang.c , "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

You've already killed your argument by saying a "reasonable
implementation" since that has nothing to do with what ISO C says. ISO C
doesn't say what an implementation, reasonable or otherwise must do with
free()'d memory.
The standard says
(I quote page 312, free() definition)

The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation.

end quote

Next allocations will recycle the memory freed!

It MAY recycle it, there is no obligation to. In fact I've often
observed that it does not. Imagine you free a 24 byte block ,and your
next allocation requires a 1204 byte block. Makes more sense for the
OS to find a large enough space, rather than allocate only 24 bytes in
one place, and have to manage the "appears contiguous" issue.

No, it just goes back into the available memory pool for subsequent
malloc's.

And this is not recycling Mark?

Recycling is reusing. Putting it back in the pool is not reusing it,
that happens when its reused.
I mean what are you trying to achieve? Confusion?

I think you two have different meanings of "recycling". Marks is more
common I fear.
--
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 =---

[jacob navia]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bh**********@newsg3.svr.pol.co.uk...

However that language isn't C. Part of the philosophy of C is that every
statement, apart from a function call, compiles to only a few machine code
instructions. Therefore you can see where your cycles are going.

Automatic garbage collection breaks that design principle.

No. When you call malloc() you can expect a GC. Very simple.
GC_malloc calls takes longer sometimes (gc done) or are quite fast.

malloc() can take longer if it needs to call the OS, and the OS can
take longer if it needs to swap a page to disk.

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

True, the GC is not a panacea and, as anything, has it drawbacks.

For instance, if you forget to set to null a global variable pointing to a
huge memory block, it will not be freed, and your program may fail
because you always allocate a big chunk of memory without cutting
any pointers to it.

An advantage is that all objects with only one pointer to them
(typical case) will be freed if the function where the pointer resides
exits. All local variable pointers that use a malloced memory will
be no longer in scope when the function exists so the collector will find
no references to them.

[Joe Wright]

jacob navia wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bh**********@newsg3.svr.pol.co.uk...

However that language isn't C. Part of the philosophy of C is that every
statement, apart from a function call, compiles to only a few machine code
instructions. Therefore you can see where your cycles are going.

Automatic garbage collection breaks that design principle.

No. When you call malloc() you can expect a GC. Very simple.
GC_malloc calls takes longer sometimes (gc done) or are quite fast.

malloc() can take longer if it needs to call the OS, and the OS can
take longer if it needs to swap a page to disk.

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

True, the GC is not a panacea and, as anything, has it drawbacks.

For instance, if you forget to set to null a global variable pointing to a
huge memory block, it will not be freed, and your program may fail
because you always allocate a big chunk of memory without cutting
any pointers to it.

An advantage is that all objects with only one pointer to them
(typical case) will be freed if the function where the pointer resides
exits. All local variable pointers that use a malloced memory will
be no longer in scope when the function exists so the collector will find
no references to them.

Jacob,

GC notwithstanding, what is garbage collection?
I am writing a C module which would trap malloc/realloc/free etc and
maintain a list of pointers to and the sizes of the allocations. The
list is (normally) invisible to the user. When the user invokes
free(ptr) I look up ptr in the list. If I find it, I free the allocation
and free and remove the list node. If I don't find it (user gives me an
invalid pointer), I simply ignore it. I provide a freeall() function
which will free all allocated memory.

Does this qualify as garbage collection?
--
Joe Wright mailto:jo********@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

jacob navia wrote:

"Gordon Burditt" <go***********@sneaky.lerctr.org> wrote in message

[snip]

But, to continue the analogy, sometimes the automatic transmission
does it wrong when you're towing a trailer (hiding pointers where
the gc can't find them). Either it ruins the engine (frees memory
that should NOT be free), or it slows down horribly (spends enormous
amounts of time looking for pointers where they aren't) and takes
24 hours to get home. And there's no practical way to fix this
without putting restrictions on how you drive.
Yes, but I can go farther because I am less tired you see?

Automatic driving requires less efforts from the driver and he/she
can drive longer distances!

For instance, I added the GC to the debugger/IDE of lcc-win32.

Because I do not have to write any code to cope for free() bugs or
problems, I used the saved time to improve the application itself.

I concentrated in the debugger itself, a *very* complex application.
Real time, with 3 threads running (debugger IDE, program under
debug, and debugger itself), with many complex specs to read the
debug info, messages that must be formated at each break, etc etc!

Now, I know that I can allocate a buffer whenever I need one, and
that I can pass it around without caring where I will free the stuff!!!

Debugging the debugger is difficult. Without the GC I would have been
slowed down by all those accounting chores and would have had less
time to try to improve it.

Now this, to me, is a legitimate use of a GC package. It is mated
to the system programs themselves. A debugger, by nature, is a
non-portable application (although large portions of it should be
as portable as possible)

Besides, the crashes due to messing around with free would be
inacceptable. A debugger crashing, what a nightmare :-)

However, the last time I looked, the lcc-win32 debugger still
crashes immediately when run on a 486 :-( This doesn't happen
with gdb. (and I did report it).

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

jacob navia wrote:

.... snip ...
malloc() can take longer if it needs to call the OS, and the OS can
take longer if it needs to swap a page to disk.

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

I have written a malloc/free/realloc package that ensures free is
O(1) at all times. You are welcome to use the ideas therein if
you wish. The free in crtdll (which I believe you use) is O(n),
where n is the number of blocks in play. So far I know of no
other RTL with an O(1) free.

See download/nmalloc.zip on my site.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Malcolm]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.
No, but they are heavily-used library functions, so you can assume a fairly
reasonable performance.
In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

The point is that in standard C you write

void killhugestructure(HUGE *h)
{
int i;

for(i=0;i<100000;i++)
free(h->ptr[i]);
}

We know that this is a potential performance drag. (We might want to
optimise by consoloidating some of the pointers).

With garbage collection, the free()s just happen. Unless you know what is
going on, you might not realise that performance is going to take a hit.

[jacob navia]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message news:bh**********@news8.svr.pol.co.uk...

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

No, but they are heavily-used library functions, so you can assume a fairly
reasonable performance.

In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

The point is that in standard C you write

void killhugestructure(HUGE *h)
{
int i;

for(i=0;i<100000;i++)
free(h->ptr[i]);
}

We know that this is a potential performance drag. (We might want to
optimise by consoloidating some of the pointers).

With garbage collection, the free()s just happen. Unless you know what is
going on, you might not realise that performance is going to take a hit.

When the next gc happens (when you call GC_malloc()) it will not take longer
than any other gc. That huge structure will be freed because no pointers to it
are valid. It just is enough to set h to NULL. This is an example of how
gc can be faster than a huge series of calls to free.

[Severian]

On Sat, 16 Aug 2003 20:04:37 GMT, CBFalconer <cb********@yahoo.com>
wrote:
<snip>

Of course, this is my own attitude to taking out the garbage. If
I postpone it, maybe something furry will come along and eat it
and save me the trouble. :-) But the furry friend may also leave
a mess behind, and then my wife yells at me. :-[

The technique works fairly well with greasy pans and cats.

Works well with cat litter and dogs, too.

- Sev

[Serve La]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:3F***************@yahoo.com...

Of course, this is my own attitude to taking out the garbage. If
I postpone it, maybe something furry will come along and eat it
and save me the trouble. :-) But the furry friend may also leave
a mess behind, and then my wife yells at me. :-[

But it's most C programmer's experience that when a program grows, the house
will get littered with little pieces of garbage without a furry friend
coming along. And then somebody decides to hang the house in a web
application.......

[Irrwahn Grausewitz]

CBFalconer <cb********@yahoo.com> wrote in
<3F***************@yahoo.com>:

So the future GC_malloc call is the one that is slowed. We can
(on most systems) get the same effect by simply not calling free
at all, and depending on the system doing the work at program
exit. At that time we can be pretty sure nothing critical is
going on, and the system can usually free everything bodily much
faster than individual free calls. With virtual memory this
actually has a fairly good chance of working, at least for a
while.

Barring such a ridiculous resolution, the point is that the work
still has to be done.

In addition to jacob's reply: in special cases, namely RealTime
applications, it's a somewhat common practice to allocate (most
of) the memory you need at program startup, so your running
process will not slow down indeterminately on later memory
(de)allocations. And a *real* RT OS knows nothing about
"virtual memory" or "swapping" or the like...

Sometimes, a ridiculous resolution is *the* solution to a given
problem.

Irrwahn.

--
My opinions are not those of my ex-employer.

[Irrwahn Grausewitz]

Irrwahn Grausewitz <ir*****@freenet.de> wrote in
<7q********************************@4ax.com>:

In addition to jacob's reply: in special cases, namely RealTime
applications, it's a somewhat common practice to allocate (most
of) the memory you need at program startup, so your running
process will not slow down indeterminately on later memory
(de)allocations. And a *real* RT OS knows nothing about
"virtual memory" or "swapping" or the like...

I received a nice rant (by email, accidentely) that makes me
clearify that with the above I didn't want to suggest that:

- Real Time applications and Real Time OS
are one and the same thing.

- You need an RTOS to write a RT Application.

- RTOSs are just for embedded systems.

- All RTOSs know nothing about virtual memory and swapping etc.

Wonder why I didn't get flamed on that slushy posting.

Thanks to Jason B.

Irrwahn

--
Proofread carefully to see if you any words out.

[Paul Hsieh]

sb*****@hotmail.com (sbayeta) wrote:

I'd like to know who is responsible of memory recycling [...]
Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.
[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.
For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Irrwahn Grausewitz]

qe*@pobox.com (Paul Hsieh) wrote in
<79**************************@posting.google.com >:

sb*****@hotmail.com (sbayeta) wrote:

I'd like to know who is responsible of memory recycling [...]
Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

Oh dear, didn't you read all the other's replies to his post?
BTW, there aren't things like 'new' or 'delete' or
'constructors' or 'destructors' in C!

[...] and defragmentation in a C/C++ program,
C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.
For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.
As far as there's a heap at all... (C does not know about
heaps - the word isn't even mentioned in the standard).

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.

And C doesn't know any of these...

Sorry, I don't want to be rude, but why, for f-words sake,
did you post this reply, presumably ignoring the fact that
there's a charter AND a faq for this NG??? (Both of 'em are
worth reading, trust me, I'm a musician :-)

Irrwahn

--
Proofread carefully to see if you any words out.

[Irrwahn Grausewitz]

Richard Heathfield <do******@address.co.uk.invalid> wrote in
<bh**********@hercules.btinternet.com>:

This newsgroup has no charter, so I'm curious to discover how you managed to
read it.

Arrgh. Apologies.
Mixing up words, groups, people, phone numbers, toothpaste,
shaving foam, ... all together.
Today's not my day I guess; maybe too less beer yesterday :-)
.... or maybe beginng Alzheimer 8-O

Erm, what did I say?

#include <stdlib.h>

char *retrieve_clc_charter( void )
{
return (char *) NULL;
}

int main( void )
{
if ( retrieve_clc_charter() == (char *) NULL )
return EXIT_FAILURE;
return EXIT_SUCCESS;
}

Irrwahn.

--
If you don't care where you are, then you ain't lost.

[CBFalconer]

Irrwahn Grausewitz wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in

This newsgroup has no charter, so I'm curious to discover how
you managed to read it.
Arrgh. Apologies.
Mixing up words, groups, people, phone numbers, toothpaste,
shaving foam, ... all together.
Today's not my day I guess; maybe too less beer yesterday :-)
... or maybe beginng Alzheimer 8-O

Erm, what did I say?

#include <stdlib.h>

char *retrieve_clc_charter( void )
{
return (char *) NULL;

^^^^^^^^ }

int main( void )
{
if ( retrieve_clc_charter() == (char *) NULL ) ^^^^^^^^ return EXIT_FAILURE;
return EXIT_SUCCESS;
}
The casts are unnecessary, and could conceivably hide errors. :-)
--
If you don't care where you are, then you ain't lost.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Irrwahn Grausewitz]

CBFalconer <cb********@yahoo.com> wrote in
<3F***************@yahoo.com>:
<SNIP>

The casts are unnecessary, and could conceivably hide errors. :-)

OK, this time I'll get it right:

////////////////////////////////////////////
// prog's purpose: retrieve c.l.c charter

#include <stdlib.h>

int main( void )
{
return EXIT_FAILURE;
}
////////////////////////////////////////////

And it's even shorter now. :-)

--
Programming by comment is less worse
than commenting by program.

[Paul Hsieh]

Irrwahn Grausewitz <ir*****@freenet.de>:

qe*@pobox.com (Paul Hsieh) wrote in

sb*****@hotmail.com (sbayeta) wrote:

I'd like to know who is responsible of memory recycling [...]
Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

Oh dear, didn't you read all the other's replies to his post?

Yes I did. I noticed that none answered the real question of the
author, which is precisely *WHY* I chimed in. Why let this newsgroups
pervasive pedanticness ruin everyone's day?
BTW, there aren't things like 'new' or 'delete' or 'constructors'
or 'destructors' in C!
First of all, the concept of "constructor" and "destructors" are not
unique to C++. The bstring library (http://bstring.sf.net ) has them,
even in the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for. Saying C
doesn't have constructors or destructors is like saying it doesn't
have bubble sort.

Second of all, the the analogy between malloc/free and new/delete is
obvious. For someone interested in the knowlege of both it doesn't
make sense to state something about one and leave out the information
for the other.

[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.

Yes. And pointing this out has no value to anyone. Let alone
repeating it multiple times.

For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.

As far as there's a heap at all... (C does not know about
heaps - the word isn't even mentioned in the standard).

He is not asking questions about the standard. And this is not
comp.std.c. So what relevance does this useless observation have to
anything?

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.

And C doesn't know any of these...

Sorry, I don't want to be rude, but why, for f-words sake,
did you post this reply, presumably ignoring the fact that
there's a charter AND a faq for this NG???

Have you read all the EULAs for all the software you've installed?
Are you a moderator for this newsgroup? Do you think every post in
comp.lang.c follows the charter? Do you think there is any value to
this charter? Do you think the many other posts which did nothing
more than rip into the OP for not following this newsgroups valueless
charter is useful?

So why did I do it? Because I decided not to be a *PRICK*.
[...] (Both of 'em are worth reading, trust me, I'm a musician :-)

Unlikely. I can get a sense of what the charter is from the kind of
crap the regulars post here. That's like asking me to read the
Unibomber's Manifesto to have a more detailed understanding of why he
mailed bombs to people.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[goose]

qe*@pobox.com (Paul Hsieh) wrote in message news:<79**************************@posting.google. com>...

Irrwahn Grausewitz <ir*****@freenet.de>:

qe*@pobox.com (Paul Hsieh) wrote in

sb*****@hotmail.com (sbayeta) wrote:
> I'd like to know who is responsible of memory recycling [...]

Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.
Oh dear, didn't you read all the other's replies to his post?

Yes I did. I noticed that none answered the real question of the
author, which is precisely *WHY* I chimed in. Why let this newsgroups
pervasive pedanticness ruin everyone's day?

<even more pervasive pedanticness>
istr that there was *at* *least* one post that answered the above
OP question.

BTW, there aren't things like 'new' or 'delete' or 'constructors'
or 'destructors' in C!
First of all, the concept of "constructor" and "destructors" are not
unique to C++.

no, they aren't.
The bstring library (http://bstring.sf.net ) has them,
even in the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for. Saying C
doesn't have constructors or destructors is like saying it doesn't
have bubble sort.
it *doesn't* have bubble sort. it *does* have quicksort though.

<snipped>

> [...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.

Yes.

I agree.
And pointing this out has no value to anyone.
I disagree. Programmers should know that C and C++ are different
languages. There is value in this, as in the next time I have to
maintain "C" code which does casting on /malloc/ just to shut the
compiler up, I'll know that
a) the programmer hasn't the faintest clue that C and C++ are
different languages with occasionally different rules.
b) no one bothered to mention a) to him.
Let alone
repeating it multiple times.
it may be multiple to you, it may be the first time that the
OP has heard it.

For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.
As far as there's a heap at all... (C does not know about
heaps - the word isn't even mentioned in the standard).

He is not asking questions about the standard. And this is not
comp.std.c. So what relevance does this useless observation have to
anything?

I suppose that, in the interest of raising the general cluefullness
of the OP, it might be wise to point out that "heap" is not a std-c
concept. as a matter of fact, it might have been best for the
person who said "heap is not std" to have introduced the concept
of static and autmatic variable storage.

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.
And C doesn't know any of these...

Sorry, I don't want to be rude, but why, for f-words sake,
did you post this reply, presumably ignoring the fact that
there's a charter AND a faq for this NG???

charter ?????

Have you read all the EULAs for all the software you've installed?
Are you a moderator for this newsgroup? Do you think every post in
comp.lang.c follows the charter?
what charter ?
Do you think there is any value to
this charter? Do you think the many other posts which did nothing
more than rip into the OP for not following this newsgroups valueless
charter is useful?
do you possibly think that misinformation is in the best interests
of the OP ? especially as his question was answered on-topic by someone
else ?

So why did I do it? Because I decided not to be a *PRICK*.
thats a good enough reason.

[...] (Both of 'em are worth reading, trust me, I'm a musician :-)
Unlikely. I can get a sense of what the charter is from the kind of
crap the regulars post here.

you mean the kind of crap that tosses people a clue when they ask
for it ?

telling learners all about the "heap" in C does nothing for their
knowledge.
That's like asking me to read the
Unibomber's Manifesto to have a more detailed understanding of why he
mailed bombs to people.

what a wierd analogy ...

hth
goose,

[Alex]

goose <ru**@webmail.co.za> wrote:

qe*@pobox.com (Paul Hsieh) wrote in message news:<79**************************@posting.google. com>...
<snip>

First of all, the concept of "constructor" and "destructors" are not
unique to C++. no, they aren't. The bstring library (http://bstring.sf.net ) has them,
even in the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for. Saying C
doesn't have constructors or destructors is like saying it doesn't
have bubble sort.

it *doesn't* have bubble sort. it *does* have quicksort though.

No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Alex

[Alex]

Irrwahn Grausewitz <ir*****@freenet.de> wrote:

CBFalconer <cb********@yahoo.com> wrote in
<3F***************@yahoo.com>:
<SNIP>

The casts are unnecessary, and could conceivably hide errors. :-)
OK, this time I'll get it right:

////////////////////////////////////////////
// prog's purpose: retrieve c.l.c charter #include <stdlib.h> int main( void )
{
return EXIT_FAILURE;
}
////////////////////////////////////////////

Syntax error in C89 :)

Alex

[Alex]

Paul Hsieh <qe*@pobox.com> wrote:

"jacob navia" <ja*********@jacob.remcomp.fr> wrote:

True, the GC is not a panacea and, as anything, has it drawbacks.

For instance, if you forget to set to null a global variable pointing to a
huge memory block, it will not be freed, and your program may fail
because you always allocate a big chunk of memory without cutting
any pointers to it.

An advantage is that all objects with only one pointer to them
(typical case) will be freed if the function where the pointer resides
exits.

Typical?!?! I'm confused. A common representation for doubly linked
lists is to wrap the tail back to the top, so that you can quickly
reach either the head or the tail. If you simply drop the reference

<snip>

You are thinking of doubly linked circular lists.

Alex

[Serve La]

"Alex" <al*******@hotmail.com> wrote in message news:OX70b.797820

it *doesn't* have bubble sort. it *does* have quicksort though.

No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Why isn't there a bsort yet in the stdlib by the way? It's faster for small
collections and you don't have to reinvent the wheel. There could be lots of
other useful algorithms in there.

[Alex]

Serve La <[e-mail]> wrote:

"Alex" <al*******@hotmail.com> wrote in message news:OX70b.797820

> it *doesn't* have bubble sort. it *does* have quicksort though.
No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Why isn't there a bsort yet in the stdlib by the way? It's faster for small
collections and you don't have to reinvent the wheel. There could be lots of
other useful algorithms in there.

The point of my post was that "standard C does not mandate/endorse
the use of any specific algorithm". You are told that 'qsort' will
sort things, nothing else is guaranteed. Don't hold your breath for
the C equivalent of STL :)

Alex

[Dave Vandervies]

In article <sl******************@kir.physnet.uni-hamburg.de>,
Daniel Haude <ha***@physnet.uni-hamburg.de> wrote:

On 16 Aug 2003 02:03:02 GMT,
Gordon Burditt <go***********@sneaky.lerctr.org> wrote
in Msg. <bh********@library1.airnews.net>

GC notwithstanding, what is garbage collection?

Garbage collection is the automatic freeing of memory that is no
longer in use. In a system with garbage collection, it is not
necessary to explicitly free memory, just erase pointers to it.

So it's essentially some reference counting scheme, right? I guess I'll
just stick with ref counting. Accomplishes the same thing, introduces very
little overhead (a dozen or two extra lines of code, maybe), and is
fully under my control.

struct double_linked_list_node
{
double_linked_list_node *prev,*next;
void *data;
};
dave
(Had to poke the sigmonster with a pointy stick a few times to get this one)

--
Dave Vandervies dj******@csclub.uwaterloo.ca

The full rant is left as an exercise for the motivated reader.
--David Rush in comp.lang.scheme

[Daniel Haude]

On Tue, 19 Aug 2003 18:44:33 +0000 (UTC),
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote
in Msg. <bh**********@tabloid.uwaterloo.ca>

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote:

So it's essentially some reference counting scheme, right? I guess I'll
just stick with ref counting. Accomplishes the same thing, introduces very
little overhead (a dozen or two extra lines of code, maybe), and is
fully under my control.

struct double_linked_list_node
{
double_linked_list_node *prev,*next;
void *data;
};

Dave, if this is meant to be related to my post in any way whatsoever, I
fail to see that relation.

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

[Serve La]

"Daniel Haude" <ha***@physnet.uni-hamburg.de> wrote in message
news:sl******************@kir.physnet.uni-hamburg.de...

Garbage collection is the automatic freeing of memory that is no
longer in use. In a system with garbage collection, it is not
necessary to explicitly free memory, just erase pointers to it.

So it's essentially some reference counting scheme, right? I guess I'll
just stick with ref counting. Accomplishes the same thing, introduces very
little overhead (a dozen or two extra lines of code, maybe), and is
fully under my control.

No, reference counting is the naive approach. First of all it's slow plus it
will introduce problems when you put the code in different environments.
Think multithreaded and multiprocessor systems. I've just been in hell with
a reference counted system (the C++ stringstream class, not really the place
to discuss here). The code crashed totally completely and utterly randomly
on a hyperthreading processor. It turned out that the reference counting
caused the databus to lock up whenever you did a string operation. As it
happened, sometimes another processor was already pulling that line, but the
other processor went for it anyway and succeeded. It also succeeded in
crashing.
Ask in a java group about best schemes for garbage collection, there's been
a lot of research on it the last ten years.

[Chris Torek]

In article <sl******************@kir.physnet.uni-hamburg.de>
Daniel Haude <ha***@physnet.uni-hamburg.de> writes:

So [garbage collection is] essentially some reference counting
scheme, right?

No; in particular, reference-counters have problems with
looped data structures (how many references does an item
pointing to itself have? :-) ). Some GC systems *do* use
refcounts as a "first level", but the most typical method
is called "mark and sweep". The drawback to mark-and-sweep
collectors is that, at some point, a "get new object"
allocation just ... seems ... to ... stop ... entirely,
and then goes on as if time had not stopped for a while. :-)

Most truly high level languages (Lisp, ML, and the like)
have GC. Such languages are very "un-C-like", and my tastes
here match Chris Dollins': GC is great, but not in C. :-)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Daniel Haude]

On Tue, 19 Aug 2003 19:34:04 +0000 (UTC),
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote
in Msg. <bh**********@tabloid.uwaterloo.ca>

Consider what happens when you have a standard doubly-linked list made
up of two (or more) of these, and drop your last external reference to it.

There's really no cure against stupid programming. Of course it'd be easy
to implement that into a refcounting scheme as well, but it would require
looking through the entire list whenever an external reference is deleted
to look if any are left. Or you set up an extra register per list that
keeps track of all external references.

But then, what if list 1 contains a ref to list 2, and vice versa, and no
other external references are left? I can't see a garbage collection
system dealing with that kind of situation efficiently.

I think that losing all external references to a list is a serious
programming error anyway. But even if we wanted to protect a list against
this sort of thing happening, it'd be easier and more efficient to add the
few necessary lines of *dedicated* code to take care of it instead of
relying on a built-in GC system that may or may not do the job properly.

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

[Chris Dollin]

Daniel Haude wrote:

On Tue, 19 Aug 2003 19:34:04 +0000 (UTC),
Dave Vandervies <dj******@csclub.uwaterloo.ca> wrote
in Msg. <bh**********@tabloid.uwaterloo.ca>

Consider what happens when you have a standard doubly-linked list made
up of two (or more) of these, and drop your last external reference to
it.
There's really no cure against stupid programming.

It's not stupid programming - in a garbage-collected system.
But then, what if list 1 contains a ref to list 2, and vice versa, and no
other external references are left? I can't see a garbage collection
system dealing with that kind of situation efficiently.
Read the literature. This is off-topic in comp.lang.c, anyway.
I think that losing all external references to a list is a serious
programming error anyway.
Why?
But even if we wanted to protect a list against
this sort of thing happening, it'd be easier and more efficient to add the
few necessary lines of *dedicated* code to take care of it instead of
relying on a built-in GC system that may or may not do the job properly.

That turns out not to be true. Writing decoupled libraries is *much*
harder without GC. As for "may or may not do the job properly", well,
a GC may have bugs in it - as may the string library, the file system
library, malloc/free, the *printf family, etc. But this is not uncharted
territory, and garbage-collectors are not some opaque mystical ectoware
that drives people insane merely to contemplate. They do a job, and enable
a programming style, and some people find that style both conducive and
effective. It doesn't fit well with C; it's a minor miracle that it can
be made to fit at all.

I speak as one who has written in CG-ed languages during 30 years (Algol W,
Snobol 4, Algol 68, Pop11, Lisp, Smalltalk, Java) and written a garbage
collector [not for machine-compiled code, alas, nor used in anger, but
to the best of my ability working] three times now. There are places
where I wouldn't used a GCed language; but for the kind of stuff I usually
do, I'd *much* rather use one than not.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[CBFalconer]

goose wrote:

qe*@pobox.com (Paul Hsieh) wrote in message
.... snip ...

The bstring library (http://bstring.sf.net ) has them, even in
the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for.
Saying C doesn't have constructors or destructors is like
saying it doesn't have bubble sort.

it *doesn't* have bubble sort. it *does* have quicksort though.

In the interests of pervasive pedanticism, C doesn't have
quicksort either. It DOES have qsort, which may, in fact, be
bubble sort :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[pete]

Serve La wrote:

"Alex" <al*******@hotmail.com> wrote in message news:OX70b.797820

it *doesn't* have bubble sort. it *does* have quicksort though.

No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Why isn't there a bsort yet in the stdlib by the way?

The reason probably has something to do with pointlessness.
Here you go:

void bsort(void *base, size_t nmemb, size_t size,
int (*compar)(const void *, const void *))
{
unsigned char *last, *next, *middle;
unsigned char swap, *p1, *p2, *end;

if (nmemb > 1) {
last = base;
last += (nmemb - 1) * size;
do {
middle = next = base;
do {
if (compar(middle, middle + size) > 0) {
p1 = middle;
p2 = middle + size;
end = p2 + size;
do {
swap = *p1;
*p1++ = *p2;
*p2++ = swap;
} while (p2 != end);
next = middle;
}
middle += size;
} while (middle != last);
last = next;
} while (last != base);
}
}

[goose]

CBFalconer <cb********@yahoo.com> wrote in message news:<3F***************@yahoo.com>...

goose wrote:

qe*@pobox.com (Paul Hsieh) wrote in message
... snip ...

The bstring library (http://bstring.sf.net ) has them, even in
the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for.
Saying C doesn't have constructors or destructors is like
saying it doesn't have bubble sort.

it *doesn't* have bubble sort. it *does* have quicksort though.

In the interests of pervasive pedanticism,

<already i dont like this game I started :-) >
C doesn't have
quicksort either. It DOES have qsort, which may, in fact, be
bubble sort :-)

<sigh>
I hate posting in haste, and then having to look with horror
at what I posted, just *knowing* that the cluefull out there
are currently circling like great whites, eyeing my comments
and thinking to themselves "breakfast!!!".

goose,
"seafood" is my middle name :-)