To be safe if another reader/presenter (t)reats the presentation as a null-terminated slide deck. Of course you would also only iterate over it with for and the number of slides as a fixed upper limit, in addition to the null check.
If memory safety is vital and you cannot guarantee it, you should probably use another language. But if speed it what you’re after, this memory unsafetyness is actually a feature.
I believe talking about this stuff will just cement the incorrect perception of C++ as unsafe language further. You CAN NOT fix perception once established, no matter how much you fix it, or how many years pass.
My recommendation for fixing the perception of C++ as unsafe it to start by fixing the unsafety in C++. Until something like circle makes it into the standard, calling C++ save is at least deceptive.
I don't know why you think C++ is a safe language. Maybe you mean "C++ in combination with a lot of coding guidelines". Or "C++ used by a senior developper". But neither the guidelines nor the developper's age is part of C++. As such, C++ is a memory leak bound to happen.
It is time for people to stop projecting the blame for their inaptitude on something else and take self responsibility. If one can't handle pointers, he should stop using them. Unfortunately the C++ hubris makes too many people over use pointers (and malloc/free) and also makes compilers/tools lack default simple static checks and diagnostic help.
malloc/free are C functions, shouldn't be used in C++. Modern C++ has the tools, but not everyone follows that. Compiler Flags and Sanitizers are good for keeping stuff clean, but usage is not enough.
This is probably the worst take imaginable, its ostensibly "git gud". That works fine in DOTA, its down right negligent when you are talking about safety critical code. I mean do you always right perfect cryptographically secure code the first time? No, you don't so maybe you shouldn't code at all.
"Take self-responsibility". Seriously? Every coder should be careful about code, but with strict deadlines, working faster than expected or just a case of the mondays, nobody is safe from messing up. My team uses automated checks/compiler flags to prevent this. But please, do shout out your company and the industry you're working in, in which you prefer "self-resposibility" over tooling. Please don't let it be gaming or you're falling into the stereotype.
Do you think every C++ programmer is inept? Because the most talented teams in the world still write memory safety vulns every few hundred lines. Pointers are an essential tool for building optimized structures and algorithms, which is the point of using a systems programming language.
Why do you need a null-terminator if the presentation already has a begin and an end?
To be safe if another reader/presenter (t)reats the presentation as a null-terminated slide deck.
Of course you would also only iterate over it with for and the number of slides as a fixed upper limit, in addition to the null check.
Oh I miss those good old days of C++. Somebody remember the Siemens usenet group with C++ riddles?
If memory safety is vital and you cannot guarantee it, you should probably use another language. But if speed it what you’re after, this memory unsafetyness is actually a feature.
My least favorite feature of the Ford Model T is the lack of airbags.
Subtle.
Existence is my least favorite feature of C++.
C is my favorite feature of C++
existence is my least favorite feature
😢
I believe talking about this stuff will just cement the incorrect perception of C++ as unsafe language further. You CAN NOT fix perception once established, no matter how much you fix it, or how many years pass.
C++ is an unsafe language. Or rather is very easy to use unsafely. Some would say that's why it's so useful.
My recommendation for fixing the perception of C++ as unsafe it to start by fixing the unsafety in C++.
Until something like circle makes it into the standard, calling C++ save is at least deceptive.
I don't know why you think C++ is a safe language. Maybe you mean "C++ in combination with a lot of coding guidelines". Or "C++ used by a senior developper". But neither the guidelines nor the developper's age is part of C++. As such, C++ is a memory leak bound to happen.
It is time for people to stop projecting the blame for their inaptitude on something else and take self responsibility. If one can't handle pointers, he should stop using them.
Unfortunately the C++ hubris makes too many people over use pointers (and malloc/free) and also makes compilers/tools lack default simple static checks and diagnostic help.
malloc/free are C functions, shouldn't be used in C++. Modern C++ has the tools, but not everyone follows that. Compiler Flags and Sanitizers are good for keeping stuff clean, but usage is not enough.
This is probably the worst take imaginable, its ostensibly "git gud". That works fine in DOTA, its down right negligent when you are talking about safety critical code. I mean do you always right perfect cryptographically secure code the first time? No, you don't so maybe you shouldn't code at all.
"Take self-responsibility". Seriously? Every coder should be careful about code, but with strict deadlines, working faster than expected or just a case of the mondays, nobody is safe from messing up. My team uses automated checks/compiler flags to prevent this.
But please, do shout out your company and the industry you're working in, in which you prefer "self-resposibility" over tooling. Please don't let it be gaming or you're falling into the stereotype.
Do you think every C++ programmer is inept? Because the most talented teams in the world still write memory safety vulns every few hundred lines. Pointers are an essential tool for building optimized structures and algorithms, which is the point of using a systems programming language.
@@MeetingCPP Counterargument: Some developers make custom allocators with them.