Friday, April 23, 2021

Digest for comp.lang.c++@googlegroups.com - 24 updates in 3 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 12:43PM -0700

On 4/23/2021 12:37 PM, Chris M. Thomasson wrote:
> nasty, unpredictable bottleneck. Only then do they complain. I warned
> some of them...
 
> https://youtu.be/XcxKIJTb3Hg
 
I used to cringe when I would see code that would allocate nodes all
over the place, and never free them. Sometimes they would allocate nodes
in loops! They would say, ahhh, that's for the GC. WOW!
jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 10:38PM +0200

Le 23/04/2021 à 21:43, Chris M. Thomasson a écrit :
 
> I used to cringe when I would see code that would allocate nodes all
> over the place, and never free them. Sometimes they would allocate nodes
> in loops! They would say, ahhh, that's for the GC. WOW!
 
Thanks for your reply, at least there are some real arguments and not
that stupid links.
 
As You seem to know, the GC can be misused, as anything can be misused.
The GC is great in certain situations, not in others.
 
I used it in my debugger. It was a GREAT relief to be able to allocate a
piece of memory in the user interface, pass it to the debugger without
caring about when and by whom it should be freed. Obviously the memory
pieces being passed were user inputs,names of variables to be
displayed,and many other SHORT pieces of memory. The other solution
would bve to redesign the debugger and use a thread proof memory
allocator that would keep the accounting,or other massive development
projects.
 
By using the GC I was able to concentrate ion the debugger itself,
already a very complex program, and forget about the memory accounting
chors.
 
What is nice of the GC is the SIMPLIFICATION that provides. Of course it
can be abused, as everything.
 
Knives? Wondefful for cutting bread. But they can cut your fingers too.
 
USE WITH CARE!
 
GC is no differeent
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:44PM -0700

On 4/23/2021 1:38 PM, jacobnavia wrote:
> that stupid links.
 
> As You seem to know, the GC can be misused, as anything can be misused.
> The GC is great in certain situations, not in others.
 
Okay, that is fair enough. From my experience, GC it not okay to use in
high pressure scenarios, under lots of load. It can cause all sorts of
issues.
 
 
 
> Knives? Wondefful for cutting bread. But they can cut your fingers too.
 
> USE WITH CARE!
 
> GC is no differeent
 
Just, try not to use a GC as a crutch: The way of all things. Btw, some
people say C is too dangerous to use, GC or not... Its as if they want
people to be forced to put corks on their forks to prevent themselves
from hurting themselves.
 
https://youtu.be/SKDX-qJaJ08
 
lol.
Ian Collins <ian-news@hotmail.com>: Apr 24 10:56AM +1200

On 24/04/2021 08:38, jacobnavia wrote:
> chors.
 
> What is nice of the GC is the SIMPLIFICATION that provides. Of course it
> can be abused, as everything.
 
We could use exactly the same argument for RAII and in the context of
this thread, std::string. We could also add deterministic behaviour as
a significant advantage RAII has over GC, especially in the semi-real
time embedded world where much of today's C and C++ is written.
 
 
> Knives? Wondefful for cutting bread. But they can cut your fingers too.
 
> USE WITH CARE!
 
> GC is no differeent
 
 
Very true.
 
 
GC can be a survivor when working with old, leaky, C code. I have
deployed it with long running services that would run out of memory and
die. It not only kept the thing running, but that particular library
kept logs which could be used to find and fix the worst leaks. I have
yet to use abetter tool for this job.
 
--
Ian.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 04:09PM -0700

On 4/23/2021 3:56 PM, Ian Collins wrote:
> die.  It not only kept the thing running, but that particular library
> kept logs which could be used to find and fix the worst leaks.  I have
> yet to use abetter tool for this job.
 
Yeah, I don't think I ever used GC for that, but it sure should help out
indeed. Good one! :^)
 
I while back, have had to find a find a horrible race-condition that
would sometimes miss a call to free. So, sometimes, under certain
conditions, the memory could grow out of control. It was a bitch and a
half to debug. Iirc, it was a strange reference counting error that
would not allow some things to be destroyed, so they would just hang
around...
 
I also remember debugging something that would hang up, from time to
time. Iirc, the problem was that a mutex was not being unlocked under
certain conditions. This was easier to fix than the previous one. The
system would deadlock, and then I could go in and debug it in an actual
deadlocked state.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 12:45PM -0700

On 4/23/2021 2:25 AM, jacobnavia wrote:
>> of the program...)
 
> If you look a bit longer, maybe you find out why, but maybe not, depends
> on how far you can look.
 
for (;;)
{
struct node* = malloc(sizeof(*node));
}
 
Hey man, like, don't worry... The GC is there to save us! ;^o
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 23 08:00PM

["Followup-To:" header set to comp.lang.c.]
 
On Fri, 2021-04-23, Juha Nieminen wrote:
> it's that great.
 
> It's quite hard to decipher (especially since it follows the typical
> 70's and 80's C style of using very short cryptic names everywhere),
 
IMO, longer names without any other improvements, aren't an
improvement. The global 'int pflag' here, for example, would suck no
matter how you rename it. If it's changed to an enum, and wrapped and
documented in a struct EditorState[1], it doesn't need to be renamed.
 
(But I have a maths background, and like short names.)
 
/Jorgen
 
[1] I may misremember the code -- I only took a brief look.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 10:29PM +0200

Le 23/04/2021 à 21:45, Chris M. Thomasson a écrit :
>   struct node* = malloc(sizeof(*node));
> }
 
> Hey man, like, don't worry... The GC is there to save us! ;^o
 
The malloc allocates the working area of the editor. It is not freed
because it will be always needed; it is realloc'ed when needed, and
freed by the OS when the program terminates. This is abvious for anyone
reading C.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:34PM -0700

On 4/23/2021 1:29 PM, jacobnavia wrote:
> because it will be always needed; it is realloc'ed when needed, and
> freed by the OS when the program terminates. This is abvious for anyone
> reading C.
 
Oh wow. Don't tell me you are one of those people who think that free()
should not exist? I have dealt with them before.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:37PM -0700

On 4/23/2021 1:34 PM, Chris M. Thomasson wrote:
>> anyone reading C.
 
> Oh wow. Don't tell me you are one of those people who think that free()
> should not exist? I have dealt with them before.
 
Question from user: Why does my memory grow out of control?
 
Answer: Don't worry man.
 
wow. I have seen systems grind to a halt because of such things.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:38PM -0700

On 4/23/2021 1:29 PM, jacobnavia wrote:
> because it will be always needed; it is realloc'ed when needed, and
> freed by the OS when the program terminates. This is abvious for anyone
> reading C.
 
Have you ever had to work with non-paged memory before?
jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 10:40PM +0200

Le 23/04/2021 à 22:34, Chris M. Thomasson a écrit :
>> anyone reading C.
 
> Oh wow. Don't tell me you are one of those people who think that free()
> should not exist? I have dealt with them before.
 
?????
Where did I said something like that?
 
Nowhere. You are just putting words in my mouth.
 
I explained to you why the code doesn't bother to free the memorysince
it is used for the whole time that the editor is running. Freeing it
just before exiting the program makes no sense.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:51PM -0700

On 4/23/2021 1:40 PM, jacobnavia wrote:
 
> ?????
> Where did I said something like that?
 
> Nowhere. You are just putting words in my mouth.
 
I was worrying that you might be one of those types.
 
 
 
> I explained to you why the code doesn't bother to free the memorysince
> it is used for the whole time that the editor is running. Freeing it
> just before exiting the program makes no sense.
 
Why? Did you create the system its running on?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 01:55PM -0700

On 4/23/2021 1:51 PM, Chris M. Thomasson wrote:
>> it is used for the whole time that the editor is running. Freeing it
>> just before exiting the program makes no sense.
 
> Why? Did you create the system its running on?
 
I my world, every malloc shall have a corresponding free. Call me a
pendant if you want. Oh well.
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 23 04:59PM -0400

On 4/23/21 8:12 AM, wij wrote:
>> You had to quote 1600 lines of code in order to say that?
 
>> You do know that you can edit and shorten quotes, don't you?
 
> I do not really understand what 'quote' means here.
 
When you send a message containing material not written by you (such as
part of the message that you're responding to) it's called a quotation,
or simply a quote.
The general rule you should follow on usenet when quoting material from
the message you're responding to is to quote as little as possible,
while providing other readers enough information so they can understand
the context of your response. The only thing you actually said about the
material you were responding to was that it was too complex. The most I
would have quoted from the previous message would have been the following:
 
On Friday, 23 April 2021 at 00:58:41 UTC+8, jacobnavia wrote:
> mid 1970's: terse, tight, efficient, and largely uncommented
> This is a slightly modified version that compiles without any
> warnings under gcc in 2021
 
"1700 lines", and "terse, tight, efficient, and largely uncommented" is
all the context you really needed to establish.
jacobnavia <jacob@jacob.remcomp.fr>: Apr 23 11:02PM +0200

Le 23/04/2021 à 22:51, Chris M. Thomasson a écrit :
>> it is used for the whole time that the editor is running. Freeing it
>> just before exiting the program makes no sense.
 
> Why? Did you create the system its running on?
 
The code is for the 10th edition of the UNIX system, and was around
probably since the start of UNIX.
 
Within the UNIX system, the OS frees all memory and ressources from a
program that terminates. No, I did not create UNIX, but maybe you should
study it a bit. It is a great system.
 
macpro: jacobnavia ~/ man ed
 
[snip]
 
HISTORY
An ed command appeared in Version 1 AT&T UNIX.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 02:13PM -0700

On 4/23/2021 2:02 PM, jacobnavia wrote:
 
> Within the UNIX system, the OS frees all memory and ressources from a
> program that terminates. No, I did not create UNIX, but maybe you should
> study it a bit. It is a great system.
 
I know exactly what you are talking about. However, please clean up
after yourself? Pretty please? UNIX is not the only system out there.
This is a bad habit to get into. Clean up, gosh darn it.
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 02:15PM -0700

On 4/23/2021 2:02 PM, jacobnavia wrote:
 
> [snip]
 
> HISTORY
>     An ed command appeared in Version 1 AT&T UNIX.
 
Please, don't be one of those people who never use fclose either!
 
https://pubs.opengroup.org/onlinepubs/009695399/functions/fclose.html
scott@slp53.sl.home (Scott Lurndal): Apr 23 10:25PM

>> reading C.
 
>Oh wow. Don't tell me you are one of those people who think that free()
>should not exist? I have dealt with them before.
 
He's talking specifically about the ed.c code from Unix V10 that
was recently posted.
 
The later version (Unixware 2.12) uses sbrk (thus never frees).
scott@slp53.sl.home (Scott Lurndal): Apr 23 10:27PM

>> freed by the OS when the program terminates. This is abvious for anyone
>> reading C.
 
>Have you ever had to work with non-paged memory before?
 
Ironically, the program in question was "run on non-paged memory",
i.e. a PDP-11.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 03:31PM -0700

On 4/23/2021 3:25 PM, Scott Lurndal wrote:
 
> He's talking specifically about the ed.c code from Unix V10 that
> was recently posted.
 
> The later version (Unixware 2.12) uses sbrk (thus never frees).
 
Oh, for some reason I thought he was talking about the general case.
Sorry for the misunderstanding. Still, I have created custom allocators
on top on mmap and such. Also, I would always munmap it and close the
mapped file. ;^)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 03:34PM -0700

On 4/23/2021 3:27 PM, Scott Lurndal wrote:
 
>> Have you ever had to work with non-paged memory before?
 
> Ironically, the program in question was "run on non-paged memory",
> i.e. a PDP-11.
 
The problems I had with non-paged memory was back when I was creating
server software back in WinNT 4.0. Every IOCP operation that's inflight
would use non-paged memory. So, using too much would foobar the system.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 03:39PM -0700

On 4/23/2021 2:13 PM, Chris M. Thomasson wrote:
 
> I know exactly what you are talking about. However, please clean up
> after yourself? Pretty please? UNIX is not the only system out there.
> This is a bad habit to get into. Clean up, gosh darn it.
 
Ack! I missed the part where you were explicitly referencing the ed code
in question. Sorry! Ouch.
 
olcott <NoOne@NoWhere.com>: Apr 23 03:17PM -0500

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)