"C++ Must Become Safer" by Andrew Lilley Brinker

[Lynn McGuire]

"C++ Must Become Safer" by Andrew Lilley Brinker
https://www.alilleybrinker.com/blog/cpp-must-become-safer/

"Not everything will be rewritten in Rust, so C++ must become safer, and
we should all care about C++ becoming safer."

"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a term
known to Consumer Reports and the White House. The key contention is
that software weaknesses and vulnerabilities have important societal
impacts — software systems play critical roles in nearly every part of
our lives and society — and so making software more secure matters, and
improving memory safety has been identified as a high-leverage means to
do so."

Not gonna happen since to do so would remove the purpose of C and C++.

Lynn

[geodandw]

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
   https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer, and
we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a term
known to Consumer Reports and the White House. The key contention is
that software weaknesses and vulnerabilities have important societal
impacts — software systems play critical roles in nearly every part of
our lives and society — and so making software more secure matters, and
improving memory safety has been identified as a high-leverage means to
do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

Which is to create memory overflow errors?

[Lynn McGuire]

Post by geodandw

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
    https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a
term known to Consumer Reports and the White House. The key contention
is that software weaknesses and vulnerabilities have important
societal impacts — software systems play critical roles in nearly
every part of our lives and society — and so making software more
secure matters, and improving memory safety has been identified as a
high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

Which is to create memory overflow errors?

To create fast and small executables.

Lynn

[Lynn McGuire]

Post by geodandw

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
    https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a
term known to Consumer Reports and the White House. The key contention
is that software weaknesses and vulnerabilities have important
societal impacts — software systems play critical roles in nearly
every part of our lives and society — and so making software more
secure matters, and improving memory safety has been identified as a
high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

Which is to create memory overflow errors?

The purpose of C++ is to create fast and small executables.

Lynn

[Bonita Montero]

Post by Lynn McGuire

Post by geodandw

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
    https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many
programmers see the benefits of memory safety, but policymakers do as
well. The concept of “memory safety” has gone from a technical term
used in discussions by the builders and users of programming
languages to a term known to Consumer Reports and the White House.
The key contention is that software weaknesses and vulnerabilities
have important societal impacts — software systems play critical
roles in nearly every part of our lives and society — and so making
software more secure matters, and improving memory safety has been
identified as a high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

Which is to create memory overflow errors?

The purpose of C++ is to create fast and small executables.

Bounds-checking doesn't cost much.
Rust f.e. is only a small amount slower than C++.

[Lynn McGuire]

Post by Bonita Montero

Post by Lynn McGuire

Post by geodandw

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
    https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many
programmers see the benefits of memory safety, but policymakers do
as well. The concept of “memory safety” has gone from a technical
term used in discussions by the builders and users of programming
languages to a term known to Consumer Reports and the White House.
The key contention is that software weaknesses and vulnerabilities
have important societal impacts — software systems play critical
roles in nearly every part of our lives and society — and so making
software more secure matters, and improving memory safety has been
identified as a high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

Which is to create memory overflow errors?

The purpose of C++ is to create fast and small executables.

Bounds-checking doesn't cost much.
Rust f.e. is only a small amount slower than C++.

Only if your code can be bounds checked. I put C pointers into integers
in my F66 / F77 code. Yes, I know, big violation of type safety. But,
I started this practice back in 1979. If I live long enough, I hope to
change it all to C++ and correct my bad habits that have now become
routine. I have a million lines of C++ code and 800,000 lines of F77 in
my desktop product.

Lynn

[Bonita Montero]

Post by Lynn McGuire
Only if your code can be bounds checked.
I put C pointers into integers in my F66 / F77 code. ...

If you actually access the data you've to know the type behind and
then you can do a bounds-check.

[Bonita Montero]

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
   https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer, and
we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a term
known to Consumer Reports and the White House. The key contention is
that software weaknesses and vulnerabilities have important societal
impacts — software systems play critical roles in nearly every part of
our lives and society — and so making software more secure matters, and
improving memory safety has been identified as a high-leverage means to
do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

I'm using iterator debugging as most as possible. And if I need a
pointer into an aribtrary container I've got my ptr<>-class which
inherits the bounds of the container it is initialized with.

[David Brown]

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
   https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer, and
we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a term
known to Consumer Reports and the White House. The key contention is
that software weaknesses and vulnerabilities have important societal
impacts — software systems play critical roles in nearly every part of
our lives and society — and so making software more secure matters, and
improving memory safety has been identified as a high-leverage means to
do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

The problem with a lot of "memory safe language" ramblings is that so
many people seem to imagine that "memory safety" is a binary issue.
They divide languages into two groups - "memory safe" languages and
"memory unsafe" languages and think that all code written in the former
category is automatically "safe", and all code written in the later is
inherently "unsafe".

This is, of course, total drivel.

It is not at all hard to have resource leaks in garbage collected
languages. You can happily have out of bounds accesses that crash the
program. Equally, you can perfectly well write safe code in C and C++.

The "safe" languages can make it harder to write certain kinds of
mistakes in the code, and can reduce the consequences of errors. They
can automate some things, reducing the manual work and error risk
involved. And that's great. There's a lot that gets written in
low-level languages such as C when it would be more productive and lower
risk to use a higher level language.

And with modern C++, you can also automate lots of things and write
clearly memory-safe code, just as well as many managed languages. The
difference is that with C++ you can /also/ write unsafe code with all
the risks available to more manual low-level programming. Resource
management with smart pointers and standard containers can be as "memory
safe" as code written in Python - but C++ also lets you use manual
malloc() and C-style arrays and pointers, with the risks these entail.
(Of course you can write correct memory-safe code in that style too.)


I believe that the people who re-write ancient C code in Rust, producing
code with fewer bugs, could have had just as much success if they had
re-written the old C code in new C, using modern C standards, modern C
tools, and modern C development techniques. It's not the language
change that makes the difference - it's throwing out accumulated cruft,
avoiding old, riskier techniques, and writing code with an emphasis on
safety and correctness instead of trying to get efficient results from
limited tools.


That said, I think it will be good to see more safety-related features
added to C++, such as contracts and borrow checking. And more static
analysis to make it harder to write risky code is always a nice thing.

[Lynn McGuire]

Post by David Brown

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
    https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a
term known to Consumer Reports and the White House. The key contention
is that software weaknesses and vulnerabilities have important
societal impacts — software systems play critical roles in nearly
every part of our lives and society — and so making software more
secure matters, and improving memory safety has been identified as a
high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

The problem with a lot of "memory safe language" ramblings is that so
many people seem to imagine that "memory safety" is a binary issue. They
divide languages into two groups - "memory safe" languages and "memory
unsafe" languages and think that all code written in the former category
is automatically "safe", and all code written in the later is inherently
"unsafe".
This is, of course, total drivel.
It is not at all hard to have resource leaks in garbage collected
languages.  You can happily have out of bounds accesses that crash the
program.  Equally, you can perfectly well write safe code in C and C++.
The "safe" languages can make it harder to write certain kinds of
mistakes in the code, and can reduce the consequences of errors.  They
can automate some things, reducing the manual work and error risk
involved.  And that's great.  There's a lot that gets written in
low-level languages such as C when it would be more productive and lower
risk to use a higher level language.
And with modern C++, you can also automate lots of things and write
clearly memory-safe code, just as well as many managed languages.  The
difference is that with C++ you can /also/ write unsafe code with all
the risks available to more manual low-level programming.  Resource
management with smart pointers and standard containers can be as "memory
safe" as code written in Python - but C++ also lets you use manual
malloc() and C-style arrays and pointers, with the risks these entail.
(Of course you can write correct memory-safe code in that style too.)
I believe that the people who re-write ancient C code in Rust, producing
code with fewer bugs, could have had just as much success if they had
re-written the old C code in new C, using modern C standards, modern C
tools, and modern C development techniques.  It's not the language
change that makes the difference - it's throwing out accumulated cruft,
avoiding old, riskier techniques, and writing code with an emphasis on
safety and correctness instead of trying to get efficient results from
limited tools.
That said, I think it will be good to see more safety-related features
added to C++, such as contracts and borrow checking.  And more static
analysis to make it harder to write risky code is always a nice thing.

What is borrow checking ?

Lynn

[Paavo Helde]

Post by Lynn McGuire

Post by David Brown
That said, I think it will be good to see more safety-related features
added to C++, such as contracts and borrow checking.  And more static
analysis to make it harder to write risky code is always a nice thing.

What is borrow checking ?

Looks like built-in and default-used std::unique_ptr + std::move(), so
the Rust compiler can e.g. issue compile-time errors when a moved-away
variable is used.


For C++ the same is done by e.g. MSVC++ analyzer and other static
analysis tools:

#include <vector>
void foo(std::vector<int>&& v) {}

int main() {
std::vector<int> vv{ 1,2,3,4 };
foo(std::move(vv));
return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).


Plus in Rust it allegedly also helps with multithread locking, though I
was not able to figure it out in 10 minutes of googling.

[Lynn McGuire]

Post by Paavo Helde

Post by Lynn McGuire

Post by David Brown
That said, I think it will be good to see more safety-related
features added to C++, such as contracts and borrow checking.  And
more static analysis to make it harder to write risky code is always
a nice thing.

What is borrow checking ?

Looks like built-in and default-used std::unique_ptr + std::move(), so
the Rust compiler can e.g. issue compile-time errors when a moved-away
variable is used.
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
    std::vector<int> vv{ 1,2,3,4 };
    foo(std::move(vv));
    return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking, though I
was not able to figure it out in 10 minutes of googling.

Ah, my multithreading has not been good so far. I have three threads in
my main app and none of the variables involved cross the thread boundaries.

Lynn

[Scott Lurndal]

Post by Lynn McGuire

Post by Paavo Helde

Post by Lynn McGuire

Post by David Brown
That said, I think it will be good to see more safety-related
features added to C++, such as contracts and borrow checking.  And
more static analysis to make it harder to write risky code is always
a nice thing.

What is borrow checking ?

Looks like built-in and default-used std::unique_ptr + std::move(), so
the Rust compiler can e.g. issue compile-time errors when a moved-away
variable is used.
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
    std::vector<int> vv{ 1,2,3,4 };
    foo(std::move(vv));
    return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking, though I
was not able to figure it out in 10 minutes of googling.

Ah, my multithreading has not been good so far. I have three threads in
my main app and none of the variables involved cross the thread boundaries.

Whereas:

(gdb) thread apply all bt

Thread 89 (Thread 0x7fffc2cca700 (LWP 35934)):
#0 0x00007ffff775ead3 in futex_wait_cancelable (private=<optimized out>, expected=0x0, futex_word=0x7fffc2ccb0e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fffc2ccb0f0, cond=0x7fffc2ccb0c0) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=***@entry=0x7fffc2ccb0c0, mutex=***@entry=0x7fffc2ccb0f0) at pthread_cond_wait.c:655
#3 0x0000555555893213 in c_condition::wait (lockp=0x7fffc2ccb0f0, this=0x7fffc2ccb0c0)

All the threads share access to a set of common resources. A
subset of the threads run at 100% utilization, the remaining threads
are waiting for some condition to become true, whereafter they
do some work and return to the waiting condition when the condition
becomes not true.

[Chris M. Thomasson]

Post by Scott Lurndal

Post by Lynn McGuire

Post by Paavo Helde

Post by Lynn McGuire

Post by David Brown
That said, I think it will be good to see more safety-related
features added to C++, such as contracts and borrow checking.  And
more static analysis to make it harder to write risky code is always
a nice thing.

What is borrow checking ?

Looks like built-in and default-used std::unique_ptr + std::move(), so
the Rust compiler can e.g. issue compile-time errors when a moved-away
variable is used.
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
    std::vector<int> vv{ 1,2,3,4 };
    foo(std::move(vv));
    return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking, though I
was not able to figure it out in 10 minutes of googling.

Ah, my multithreading has not been good so far. I have three threads in
my main app and none of the variables involved cross the thread boundaries.

(gdb) thread apply all bt
#0 0x00007ffff775ead3 in futex_wait_cancelable (private=<optimized out>, expected=0x0, futex_word=0x7fffc2ccb0e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fffc2ccb0f0, cond=0x7fffc2ccb0c0) at pthread_cond_wait.c:502
#3 0x0000555555893213 in c_condition::wait (lockp=0x7fffc2ccb0f0, this=0x7fffc2ccb0c0)
All the threads share access to a set of common resources. A
subset of the threads run at 100% utilization, the remaining threads
are waiting for some condition to become true, whereafter they
do some work and return to the waiting condition when the condition
becomes not true.

I will never forget when I had to debug some code, and it deadlocked.
However, the programmers worked around it by using a timed wait for the
condvar. So, it would deadlock, then the timed wait would go by, and
things would progress, then deadlock again sometime later. It was great
fun to debug... Barf!!!!!!

[Bonita Montero]

Post by Paavo Helde
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
    std::vector<int> vv{ 1,2,3,4 };
    foo(std::move(vv));
    return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking,
though I was not able to figure it out in 10 minutes of googling.

C++ says that moved from objects are left in an indefinite state,
but for vectors this actually doesn't happen. With strings this
might happen due to the short string optimization so that there
might be a copy instead of a move.

[Paavo Helde]

Post by Bonita Montero

Post by Paavo Helde
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
     std::vector<int> vv{ 1,2,3,4 };
     foo(std::move(vv));
     return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking,
though I was not able to figure it out in 10 minutes of googling.

C++ says that moved from objects are left in an indefinite state,
but for vectors this actually doesn't happen. With strings this
might happen due to the short string optimization so that there
might be a copy instead of a move.

This is not what the standard says. There is nothing indefinite about
the state of the object after move, this is not some quantum theory.

What the standard actually says (about C++ standard library types):
"Unless otherwise specified, such moved-from objects shall be placed in
a valid but unspecified state".

This just means the standard does not prescribe to the implementations
in which state the objects will be left, and therefore a programmer
should not rely on expecting some certain state. Hence the static
analyzer warnings and Rust errors when accessing the moved-away state.

Unfortunately, the C++ standard has messed itself up again by sometimes
requiring a specific state after move. For example,
std::map::try_emplace: "Unlike insert or emplace, these functions do not
move from rvalue arguments if the insertion does not happen."

That's pretty unfortunate. I can see that such interfaces might be
useful for squeezing out the max possible performance, but IMO they
should be defined in terms of normal lvalue references, instead of
rvalue references.

[Bonita Montero]

Post by Paavo Helde

Post by Bonita Montero

Post by Paavo Helde
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
     std::vector<int> vv{ 1,2,3,4 };
     foo(std::move(vv));
     return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking,
though I was not able to figure it out in 10 minutes of googling.

C++ says that moved from objects are left in an indefinite state,
but for vectors this actually doesn't happen. With strings this
might happen due to the short string optimization so that there
might be a copy instead of a move.

This is not what the standard says. There is nothing indefinite about
the state of the object after move, this is not some quantum theory.
"Unless otherwise specified, such moved-from objects shall be placed in
a valid but unspecified state".

You work with quibbles over words.

Post by Paavo Helde
This just means the standard does not prescribe to the implementations
in which state the objects will be left, and therefore a programmer
should not rely on expecting some certain state. Hence the static
analyzer warnings and Rust errors when accessing the moved-away state.
Unfortunately, the C++ standard has messed itself up again by sometimes
requiring a specific state after move. For example,
std::map::try_emplace: "Unlike insert or emplace, these functions do not
move from rvalue arguments if the insertion does not happen."
That's pretty unfortunate. I can see that such interfaces might be
useful for squeezing out the max possible performance, but IMO they
should be defined in terms of normal lvalue references, instead of
rvalue references.

[David Brown]

Post by Paavo Helde

Post by Lynn McGuire

Post by David Brown
That said, I think it will be good to see more safety-related
features added to C++, such as contracts and borrow checking.  And
more static analysis to make it harder to write risky code is always
a nice thing.

What is borrow checking ?

Looks like built-in and default-used std::unique_ptr + std::move(), so
the Rust compiler can e.g. issue compile-time errors when a moved-away
variable is used.
For C++ the same is done by e.g. MSVC++ analyzer and other static
#include <vector>
void foo(std::vector<int>&& v) {}
int main() {
    std::vector<int> vv{ 1,2,3,4 };
    foo(std::move(vv));
    return vv.empty();
}
main.cpp(7): warning C26800: Use of a moved from object: ''vv''
(lifetime.1).
Plus in Rust it allegedly also helps with multithread locking, though I
was not able to figure it out in 10 minutes of googling.

Yes, that's how I understand it. (I know very little of the details of
Rust, so I am happy to be corrected if I make any mistakes here.) Rust
has a "borrow checker" program that runs in addition to the compiler, to
track ownership of objects and resources and be sure that the ownership
rules are followed. C++ compilers can do some checking, as you show
above, just as Rust compilers can. But to do it properly requires
inter-module analysis and that's where the external borrow checker
program comes in. (AFAIUI, there is a Rust frontend for gcc, but they
have not yet got a companion borrow checker.)

I think it should be possible to make a similar borrow checker program
for C++ that tracks usage and ensures you don't use objects incorrectly
after moves, even as they are passed across modules. There would be a
key difference, however - Rust is designed to make it as hard as
possible to break these kinds of rules, while C++ has no such
restrictions. Borrow-safe C++ code would require you to use the
specific borrow-safe types (i.e., no raw pointers and the like).

There is a language XC made by XMOS for use with their microcontrollers.
This is designed for hard real-time software with hardware-assisted
RTOS and message passing (inspired by CSP). XC is based on C, but with
some restrictions and limitations, and several additions and
enhancements. One of the features is that the XC tools know which
thread "owns" a given piece of data, and stops you from accessing it
incorrectly with from a different thread. (It's arguably a bit too
strict - sometimes you know things are safe, but the tools block you
from the accesses you want.) There could be ways to get similar
checking for C++ (again, it would no doubt be restricted to a specific
subset of C++).

[Vir Campestris]

On 19/07/2024 12:40, David Brown wrote:
<snip>

Post by David Brown
And with modern C++, you can also automate lots of things and write
clearly memory-safe code, just as well as many managed languages.  The
difference is that with C++ you can /also/ write unsafe code with all
the risks available to more manual low-level programming.  Resource
management with smart pointers and standard containers can be as "memory
safe" as code written in Python - but C++ also lets you use manual
malloc() and C-style arrays and pointers, with the risks these entail.
(Of course you can write correct memory-safe code in that style too.)

</snip>

The very first thing I was asked to do in my last job was to look at
system crashes. I worked out that one of the common ones was a resource
management issue - it was allocating objects and freeing them
dynamically, losing track of which objects had been freed, and accessing
them after they had been deleted. It was all done with raw pointers.

I replaced them all with shared_ptr and weak_ptr.

System reliability went up. Noticeably. But in one place I used a
shared_ptr that should have been weak_ptr - so under certain
circumstances the code "leaked" memory, not unloading objects it had
finished with.

I replaced a classic C problem with one you could quite easily get in
Java or C#, or I assume Rust.

There are no magic bullets.

Andy

[jseigh]

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
   https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer, and
we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a term
known to Consumer Reports and the White House. The key contention is
that software weaknesses and vulnerabilities have important societal
impacts — software systems play critical roles in nearly every part of
our lives and society — and so making software more secure matters, and
improving memory safety has been identified as a high-leverage means to
do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

I did look at Rust (mostly askance :)). I decided to take a pass on it
because of the allegedly long time to take to learn it and it didn't
really address concurrency (at least the stuff I mess with). Also they
keep making unsubstantiated claims that Rust is more performant than
Java, also a "memory safe" language. Apparently they are unaware of
Java's JIT compilation and how good concurrent garbage collection can
be. This from where reference counting, one of the least performant
ways of managing shared memory, is insanely popular.

Its "memory safety" is type safety I think, if you ignore concurrency.
It's solved the aliasing problem somewhat. I do like its send trait,
"you've just send this heap based object to another thread so don't mess
with it from now on". This is mostly just impressions I got from
reading the Rust users form which has a lot of help related stuff so
there might be some sample bias there.

Its handling of mutability of referenced objects is a little weird.

Access to locked object is done by "dereferencing" the mutex. So no
using mutexes on groups of things. You would have to create a type to
hold that group and use the mutex on that.

Joe Seigh

[Ross Finlayson]

Post by jseigh

Post by Lynn McGuire
"C++ Must Become Safer" by Andrew Lilley Brinker
https://www.alilleybrinker.com/blog/cpp-must-become-safer/
"Not everything will be rewritten in Rust, so C++ must become safer,
and we should all care about C++ becoming safer."
"It has become increasingly apparent that not only do many programmers
see the benefits of memory safety, but policymakers do as well. The
concept of “memory safety” has gone from a technical term used in
discussions by the builders and users of programming languages to a
term known to Consumer Reports and the White House. The key contention
is that software weaknesses and vulnerabilities have important
societal impacts — software systems play critical roles in nearly
every part of our lives and society — and so making software more
secure matters, and improving memory safety has been identified as a
high-leverage means to do so."
Not gonna happen since to do so would remove the purpose of C and C++.
Lynn

I did look at Rust (mostly askance :)). I decided to take a pass on it
because of the allegedly long time to take to learn it and it didn't
really address concurrency (at least the stuff I mess with). Also they
keep making unsubstantiated claims that Rust is more performant than
Java, also a "memory safe" language. Apparently they are unaware of
Java's JIT compilation and how good concurrent garbage collection can
be. This from where reference counting, one of the least performant
ways of managing shared memory, is insanely popular.
Its "memory safety" is type safety I think, if you ignore concurrency.
It's solved the aliasing problem somewhat. I do like its send trait,
"you've just send this heap based object to another thread so don't mess
with it from now on". This is mostly just impressions I got from
reading the Rust users form which has a lot of help related stuff so
there might be some sample bias there.
Its handling of mutability of referenced objects is a little weird.
Access to locked object is done by "dereferencing" the mutex. So no
using mutexes on groups of things. You would have to create a type to
hold that group and use the mutex on that.
Joe Seigh

In terms of stack unwinding, the exceptions are about the greatest
things with regards to defining exceptional behavior, and otherwise
reliance on vigilance and diligence and discipline is not.

I.e., syntactic sugar for structured return values is not scope guard.

"Type" safety is pretty much the only word with which it's associated.

Then there's "thread" safety, yet at compile-time, "type" safety.

There's something to be said for const, and immutables, with
regards to hiding and making encapsulation and using the language
features vis-a-vis the most usual sorts of concrete adapters.

When goto was considered bad, was a thing, then with regards to
signals and segfault, longjmp and so on, "shared libraries"
is sort of one image, to crash altogether.

C++ can be plenty safe, just use the safe parts safely.