So don't use STL
Indeed, No True Scotsman would use STL with C++.
clang-tidy and Cppcheck and flaw finder and Sonarqube
The last job I had where I had to use C/C++, we automatically ran an expensive static analysis tool every time we checked in code. I'd estimate that it only found about half of the potential segfaults, and it made up for that by finding twice as many false positives.
The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.
Nope. If I had used st::list instead of std::vector, it would have been perfectly fine and officially supported. (Assuming I changed "i+10" to "i+11" in order to make the algorithm actually terminate, although that change wouldn't affect the vector crash.).
The problem is that there are dozens of different rules you have to remember to apply to the different types of lists and iterators. And that's only talking about that one topic. There are hundreds of other rules covering a multitude of language aspects that you have to mentally apply against every single line of code you write, many of which can potentially cause memory corruption.
You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.
That is a dangerous misconception. You don't need to use any pointers to get memory errors in C++:
#include <stdio.h>
#include <vector>
int main() {
std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9};
for (auto i : v) {
if (i % 2 == 0) {
v.push_back(i + 10);
}
printf("%d\n", i);
}
return 0;
}
$ g++ -Wall -pedantic t.cpp
$ echo $?
0
$./a.out
1
2
-947527061
1600570778
5
6
7
8
9
languages like Rust exist to put ignorant programmers in straight jackets for their own good
Are you seriously trying to suggest that never allocating memory is not also a "straight jacket"?
You seem to be saying that a currently existing bowdlerized version C++ is safe for close-world problems. Possibly so, but that still leaves C++ unsuitable for open-world problems. That makes C++ only suitable for niche applications. Why learn it?
If you just use Rust or any other memory safe language, you won't have to worry about what kind of "world" you're writing for, or about choosing from a range of increasingly dangerous "profiles".
For that you would want to focus on free energy and food replicators because once you have that, there's not much reason to work anymore.
No matter what, you're still going to need someone in a red shirt to duck into the circuit bays and reverse the polarity.
Someone didn't live through the loss of the floppy drive, DB9 ports, and parallel ports.
In my day, to plug in a mouse: We took the box apart, installed a proprietary bus card, and then tried to figure out non-conflicting spots for the I/O and IRQ jumpers. Then we typed a bunch of gibberish into AUTOEXEC.BAT. And we liked it!
Not at all. Free citizens picking lettuce on a corporate-owned ranch is the American Dream!
It's better than medieval serfdom was because you're FREE!!! You could even prove it by wearing a giant bald eagle and flag T-shirt while you work!!!
A whole bunch of opportunities have recently opened up to US citizens for picking lettuce.
At least Nixon had the class not to force his minions to take all of the credit for the Apollo missions in their press releases.
That's what Trump did here: Same as usual he took all of the credit for other peoples' work.
You wonder why he gets under peoples' skin? It's because essentially everything he does is some kind of asshole move like this.
Yeah, that's why everyone gives Nixon credit for putting a man on the moon.
I meant using a pointer to the base of a buffer, then writing data beyond the end of the buffer the pointer refers to.
How are you going to get a buffer overflow on an integer or float scalar?
Those happen on arrays and pointers, whether on the stack, heap or global static spaces. You can also overflow the entire stack using unbounded recursive function calls, but that's a different issue.
Your seem to be totally ignorant about how different data types work.
Scalars on the stack are "automatic" variables. There is no explicit memory management needed by the programmer. They are pretty safe, as long as you don't do stupid C casting tricks.
The "certain things" you refer to includes using *any* pointer or array value in any way, including allocating, freeing, indexing and dereferencing. That essentially means any operations on items other than the automatic scalars I already covered. (For completeness, we can also consider "plain old data" structs lacking embedded pointers or arrays to be as safe as scalars, and globally allocated scalars and POD structs to be relatively safe, even if generally not good practice.)
So these things he says aren't true? He said that he was being forced to do memory safety when it wasnt even a concern and that the compiler was slow. Was he wrong about that?
Yes. Unless all of your variables are floats and integers on the stack, memory safety is always an issue when you write code in C. (If all of his values were actually floats and integers on the stack, he would have had no problem writing the Rust code either.)
Pro tip:
This article is not about ITER.
Honesty is for the most part less profitable than dishonesty. -- Plato
