On 16/03/2023 20:29, olcott wrote:
> The memory leak errors made possible by pointers can be easily
> eliminated by compiling the code as C++ and using the standard template
> library for all memory allocation.

The first major change I made in my last job was exactly that - there
was code that stored raw pointers all over the place, and we were
getting crashes when something accessed an object that had been deleted.
Well, sometimes crashes... UB anyway.

But easy? It took me several weeks to go through and work out which
places needed shared_ptr, and which needed weak_ptr. Some bits of code
didn't own the objects, but needed to look through them all. And our
code base was _already_ C++.

I got one wrong. We ended up with a memory leak because one of the pools
was keeping dead objects allocated. Not a leak in the classical sense -
a block of memory where nobody knows where it is - but still memory
being used up over time until we ran out.

Andy

On 3/17/2023 12:00 PM, Vir Campestris wrote:
> On 16/03/2023 20:29, olcott wrote:
>> The memory leak errors made possible by pointers can be easily
>> eliminated by compiling the code as C++ and using the standard template
>> library for all memory allocation.
>
> The first major change I made in my last job was exactly that - there
> was code that stored raw pointers all over the place, and we were
> getting crashes when something accessed an object that had been deleted.
> Well, sometimes crashes... UB anyway.
>
> But easy? It took me several weeks to go through and work out which
> places needed shared_ptr, and which needed weak_ptr. Some bits of code
> didn't own the objects, but needed to look through them all. And our
> code base was _already_ C++.
>
> I got one wrong. We ended up with a memory leak because one of the pools
> was keeping dead objects allocated. Not a leak in the classical sense -
> a block of memory where nobody knows where it is - but still memory
> being used up over time until we ran out.
>
> Andy

When I converted from C programming to C++ programming all new systems
only used the standard template library for all dynamic memory
allocation. I have always hated the tediousness of pointers so much that
I never did any dynamic memory allocation until after I switched to C++.

With std::vector a huge array of very large objects can be stored in a
local variable that has its memory correctly automatically deallocated
as soon as the function returns. Memory is also automatically allocated
as needed with push_back().

The only other thing that I use from C++ is classes/objects. The key
benefit of OOP is utterly eliminating the possibility of global side-
effects. When functionality and data are totally contained within the
same object then the extraneous complexity of global side-effects is
abolished.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
> On 3/9/2023 3:07 AM, Anton Shepelev wrote:
> > Ed Prochak:
> >
> >> cases where pointers make much cleaner and more
> >> maintainable code (linked lists, trees)
> >
> > The simplest approach to such lists or trees involves
> > allocating each element with a separate malloc() call. Does
> > it provide sufficient performance is the majority of
> > production code?
> >
> The memory leak errors made possible by pointers can be easily
> eliminated by compiling the code as C++ and using the standard template
> library for all memory allocation.
>
> --
> Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer

Suggesting other languages is one solution. In that case why not
C#, java, ...

But we are discussing in comp.lang.c
Memory leaks are possible in C because it expects a skilled programmer.
C doesn't hold your hand. Good code reviews help.

Ed

On 3/17/2023 4:18 PM, Ed Prochak wrote:
> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
>> On 3/9/2023 3:07 AM, Anton Shepelev wrote:
>>> Ed Prochak:
>>>
>>>> cases where pointers make much cleaner and more
>>>> maintainable code (linked lists, trees)
>>>
>>> The simplest approach to such lists or trees involves
>>> allocating each element with a separate malloc() call. Does
>>> it provide sufficient performance is the majority of
>>> production code?
>>>
>> The memory leak errors made possible by pointers can be easily
>> eliminated by compiling the code as C++ and using the standard template
>> library for all memory allocation.
>>
>> --
>> Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
>> hits a target no one else can see." Arthur Schopenhauer
>
> Suggesting other languages is one solution. In that case why not
> C#, java, ...
>
> But we are discussing in comp.lang.c
> Memory leaks are possible in C because it expects a skilled programmer.
> C doesn't hold your hand. Good code reviews help.
>
> Ed

It is a bad idea to leave the tediousness of pointers to humans this
simply makes code much more error prone.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Il 18/03/2023 19:14, olcott ha scritto:
> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
>>> On 3/9/2023 3:07 AM, Anton Shepelev wrote:
>>>> Ed Prochak:
>>>>
>>>>> cases where pointers make much cleaner and more
>>>>> maintainable code (linked lists, trees)
>>>>
>>>> The simplest approach to such lists or trees involves
>>>> allocating each element with a separate malloc() call. Does
>>>> it provide sufficient performance is the majority of
>>>> production code?
>>>>
>>> The memory leak errors made possible by pointers can be easily
>>> eliminated by compiling the code as C++ and using the standard template
>>> library for all memory allocation.
>>>
>>> --
>>> Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
>>> hits a target no one else can see." Arthur Schopenhauer
>>
>> Suggesting other languages is one solution. In that case why not
>> C#, java, ...
>>
>> But we are discussing in comp.lang.c
>> Memory leaks are possible in C because it expects a skilled programmer.
>> C doesn't hold your hand. Good code reviews help.
>>
>> Ed
>
> It is a bad idea to leave the tediousness of pointers to humans this
> simply makes code much more error prone.
>

'Oh, you aren't even ripe yet! I don't need any sour grapes.'

On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
> On 3/17/2023 4:18 PM, Ed Prochak wrote:
> > On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
[]
> >> The memory leak errors made possible by pointers can be easily
> >> eliminated by compiling the code as C++ and using the standard template
> >> library for all memory allocation.

> >
> > Suggesting other languages is one solution. In that case why not
> > C#, java, ...
> >
> > But we are discussing in comp.lang.c
> > Memory leaks are possible in C because it expects a skilled programmer.
> > C doesn't hold your hand. Good code reviews help.
> >
> > Ed
> It is a bad idea to leave the tediousness of pointers to humans this
> simply makes code much more error prone.

Then you better not program in assembly! Like Fir, you claim it is bad simple because
some people have trouble with it. If you feel that way, join the C++ newsgroup and
stop trying to change C into another language.

I have used C successfully for decades. I have fixed the memory leaks of others.
All in the embedded programming environment. It can be done correctly.

Ed

On Saturday, March 18, 2023 at 4:04:38 PM UTC-4, jak. wrote:
> Il 18/03/2023 19:14, olcott ha scritto:
[]
> > It is a bad idea to leave the tediousness of pointers to humans this
> > simply makes code much more error prone.
> >
> 'Oh, you aren't even ripe yet! I don't need any sour grapes.'

Nice!
Ed

On 3/18/2023 3:42 PM, Ed Prochak wrote:
> On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
>> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
> []
>>>> The memory leak errors made possible by pointers can be easily
>>>> eliminated by compiling the code as C++ and using the standard template
>>>> library for all memory allocation.
>
>>>
>>> Suggesting other languages is one solution. In that case why not
>>> C#, java, ...
>>>
>>> But we are discussing in comp.lang.c
>>> Memory leaks are possible in C because it expects a skilled programmer.
>>> C doesn't hold your hand. Good code reviews help.
>>>
>>> Ed
>> It is a bad idea to leave the tediousness of pointers to humans this
>> simply makes code much more error prone.
>
> Then you better not program in assembly! Like Fir, you claim it is bad simple because
> some people have trouble with it. If you feel that way, join the C++ newsgroup and
> stop trying to change C into another language.
>

I am agreeing with the original post. Also I wrote my own std::vector in
"C" many years ago so this can be done in C.

In all the years since I switched from C to C++ I only use the standard
library and classes/objects. I still use printf().

OOP is a much better paradigm in that it eliminates the possibility of
global side effects and decomposes functionality into much more easily
understood self-contained units.

> I have used C successfully for decades. I have fixed the memory leaks of others.
> All in the embedded programming environment. It can be done correctly.
>
> Ed

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Il 18/03/2023 21:42, Ed Prochak ha scritto:
> On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
>> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
> []
>>>> The memory leak errors made possible by pointers can be easily
>>>> eliminated by compiling the code as C++ and using the standard template
>>>> library for all memory allocation.
>
>>>
>>> Suggesting other languages is one solution. In that case why not
>>> C#, java, ...
>>>
>>> But we are discussing in comp.lang.c
>>> Memory leaks are possible in C because it expects a skilled programmer.
>>> C doesn't hold your hand. Good code reviews help.
>>>
>>> Ed
>> It is a bad idea to leave the tediousness of pointers to humans this
>> simply makes code much more error prone.
>
> Then you better not program in assembly! Like Fir, you claim it is bad simple because
> some people have trouble with it. If you feel that way, join the C++ newsgroup and
> stop trying to change C into another language.
>
> I have used C successfully for decades. I have fixed the memory leaks of others.
> All in the embedded programming environment. It can be done correctly.
>
> Ed

Believe me, insisting is useless. They don't want to understand what
they themselves are saying. Using C++ instead of C to avoid memory leaks
is probably the right thing to do and as such I advise them to continue
using C++. But C++ isn't C. In C, if you want to increase the
probability of not leaking memory, you just don't use functions like
malloc directly but wrap them in functions that help you properly free
what you allocate. If you don't do at least that, then you don't have
the right mindset to be a C writer.

ps: like you, I've been using C for several decades.

On 3/18/2023 5:44 PM, jak. wrote:
> Il 18/03/2023 21:42, Ed Prochak ha scritto:
>> On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
>>> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>>>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
>> []
>>>>> The memory leak errors made possible by pointers can be easily
>>>>> eliminated by compiling the code as C++ and using the standard
>>>>> template
>>>>> library for all memory allocation.
>>
>>>>
>>>> Suggesting other languages is one solution. In that case why not
>>>> C#, java, ...
>>>>
>>>> But we are discussing in comp.lang.c
>>>> Memory leaks are possible in C because it expects a skilled programmer.
>>>> C doesn't hold your hand. Good code reviews help.
>>>>
>>>> Ed
>>> It is a bad idea to leave the tediousness of pointers to humans this
>>> simply makes code much more error prone.
>>
>> Then you better not program in assembly! Like Fir, you claim it is bad
>> simple because
>> some people have trouble with it. If you feel that way, join the C++
>> newsgroup and
>> stop trying to change C into another language.
>>
>> I have used C successfully for decades. I have fixed the memory leaks
>> of others.
>> All in the embedded programming environment. It can be done correctly.
>>
>> Ed
>
> Believe me, insisting is useless. They don't want to understand what
> they themselves are saying. Using C++ instead of C to avoid memory leaks
> is probably the right thing to do and as such I advise them to continue
> using C++. But C++ isn't C. In C, if you want to increase the
> probability of not leaking memory, you just don't use functions like
> malloc directly but wrap them in functions that help you properly free
> what you allocate. If you don't do at least that, then you don't have
> the right mindset to be a C writer.
>
> ps: like you, I've been using C for several decades.
>

Personally I have always hated the tediousness pointers so much that I
never used dynamic memory allocation until I found std::vector in C++.

The issue of clean memory management in C might remain a problem because
C has no destructors that are automatically invoked even when you
forget. Maybe there is some way to do this in C?

Calling your own memory management subsystem might be able to somehow
keep track of pointers that are no longer referenced.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Il 19/03/2023 21:07, olcott ha scritto:
> On 3/18/2023 5:44 PM, jak. wrote:
>> Il 18/03/2023 21:42, Ed Prochak ha scritto:
>>> On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
>>>> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>>>>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
>>> []
>>>>>> The memory leak errors made possible by pointers can be easily
>>>>>> eliminated by compiling the code as C++ and using the standard
>>>>>> template
>>>>>> library for all memory allocation.
>>>
>>>>>
>>>>> Suggesting other languages is one solution. In that case why not
>>>>> C#, java, ...
>>>>>
>>>>> But we are discussing in comp.lang.c
>>>>> Memory leaks are possible in C because it expects a skilled
>>>>> programmer.
>>>>> C doesn't hold your hand. Good code reviews help.
>>>>>
>>>>> Ed
>>>> It is a bad idea to leave the tediousness of pointers to humans this
>>>> simply makes code much more error prone.
>>>
>>> Then you better not program in assembly! Like Fir, you claim it is
>>> bad simple because
>>> some people have trouble with it. If you feel that way, join the C++
>>> newsgroup and
>>> stop trying to change C into another language.
>>>
>>> I have used C successfully for decades. I have fixed the memory leaks
>>> of others.
>>> All in the embedded programming environment. It can be done correctly.
>>>
>>> Ed
>>
>> Believe me, insisting is useless. They don't want to understand what
>> they themselves are saying. Using C++ instead of C to avoid memory leaks
>> is probably the right thing to do and as such I advise them to continue
>> using C++. But C++ isn't C. In C, if you want to increase the
>> probability of not leaking memory, you just don't use functions like
>> malloc directly but wrap them in functions that help you properly free
>> what you allocate. If you don't do at least that, then you don't have
>> the right mindset to be a C writer.
>>
>> ps: like you, I've been using C for several decades.
>>
>
> Personally I have always hated the tediousness pointers so much that I
> never used dynamic memory allocation until I found std::vector in C++.
>
> The issue of clean memory management in C might remain a problem because
> C has no destructors that are automatically invoked even when you
> forget. Maybe there is some way to do this in C?
>
> Calling your own memory management subsystem might be able to somehow
> keep track of pointers that are no longer referenced.
>
>

So you will have to continue using C++. C is the wrong language for your
needs.

On 18/03/2023 20:42, Ed Prochak wrote:
> I have used C successfully for decades. I have fixed the memory leaks of others.
> All in the embedded programming environment. It can be done correctly.

When I have used C in recent years it has been for embedded platforms.

C++ relies on lots and lots of libraries, and they don't always fit. Nor
are they necessarily available at all times.

Andy

Il 19/03/2023 21:07, olcott ha scritto:
> On 3/18/2023 5:44 PM, jak. wrote:
>> Il 18/03/2023 21:42, Ed Prochak ha scritto:
>>> On Saturday, March 18, 2023 at 2:14:33 PM UTC-4, olcott wrote:
>>>> On 3/17/2023 4:18 PM, Ed Prochak wrote:
>>>>> On Thursday, March 16, 2023 at 4:29:39 PM UTC-4, olcott wrote:
>>> []
>>>>>> The memory leak errors made possible by pointers can be easily
>>>>>> eliminated by compiling the code as C++ and using the standard
>>>>>> template
>>>>>> library for all memory allocation.
>>>
>>>>>
>>>>> Suggesting other languages is one solution. In that case why not
>>>>> C#, java, ...
>>>>>
>>>>> But we are discussing in comp.lang.c
>>>>> Memory leaks are possible in C because it expects a skilled
>>>>> programmer.
>>>>> C doesn't hold your hand. Good code reviews help.
>>>>>
>>>>> Ed
>>>> It is a bad idea to leave the tediousness of pointers to humans this
>>>> simply makes code much more error prone.
>>>
>>> Then you better not program in assembly! Like Fir, you claim it is
>>> bad simple because
>>> some people have trouble with it. If you feel that way, join the C++
>>> newsgroup and
>>> stop trying to change C into another language.
>>>
>>> I have used C successfully for decades. I have fixed the memory leaks
>>> of others.
>>> All in the embedded programming environment. It can be done correctly.
>>>
>>> Ed
>>
>> Believe me, insisting is useless. They don't want to understand what
>> they themselves are saying. Using C++ instead of C to avoid memory leaks
>> is probably the right thing to do and as such I advise them to continue
>> using C++. But C++ isn't C. In C, if you want to increase the
>> probability of not leaking memory, you just don't use functions like
>> malloc directly but wrap them in functions that help you properly free
>> what you allocate. If you don't do at least that, then you don't have
>> the right mindset to be a C writer.
>>
>> ps: like you, I've been using C for several decades.
>>
>
> Personally I have always hated the tediousness pointers so much that I
> never used dynamic memory allocation until I found std::vector in C++.
>
> The issue of clean memory management in C might remain a problem because
> C has no destructors that are automatically invoked even when you
> forget. Maybe there is some way to do this in C?
>
> Calling your own memory management subsystem might be able to somehow
> keep track of pointers that are no longer referenced.
>
>

C++ makes heavy use of dynamic memory even if this thing is masqueraded,
this is why destructors exist and are needed. But remember that an
executable produced with C++ needs a runtimer and much more memory to
run compared to executables produced by C. However, if you really need a
destructor function in C, then you could create it yourself. Obviously
this function would not do anything automatically and this could be the
way:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

char *ptr = NULL;

void kill_foo()
{ free(ptr);
ptr = NULL;
}

int foo()
{ if(fork())
return

atexit(kill_foo);

char f[] = "%s %s", h[] = "hello", w[] = "world";
int len = 1 + snprintf(NULL, 0, f, h, w);

ptr = malloc(len);
snprintf(ptr, len ,f, h, w);
if(ptr)
printf("foo: %s\n", ptr);
else
printf("foo: null ptr\n");

exit(0);
}

int main()
{ foo();
wait(NULL);

if(ptr)
printf("main: %s\n", ptr);
else
printf("main: null ptr\n");

exit(0);
}

Of course it's just sample code and I don't check the return values.
You'll probably think it's a complicated way but don't think that what
C++ masks you is very different. I often read about comparisons between
C and C++ but they are not comparable because they are two different
languages and similar only in syntax. Speaking absurdly I could say that
it is more logical to compare C-Sharp and Visual-Basic.