241–250 of 451 posts
Earlier quoted context omitted.
Open a file in the constructor, close it in the destructor. RAII with 0 allocations.
std::vector allocated and freed on the stack will allocate an array for its int’s on the heap…
Earlier quoted context omitted.
You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.
So you can’t use them then.
I mean .at is great and all, but it's really for the benefit of eliminating undefined behavior and if the program just terminates then you've achieved this. I've seen decoders that just catch the std::out_of_range or even std::exception to handle the remaining bugs in the logic, though.
The same is true for the software that runs many satellites. Use of the STL is prohibited. The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can contin…
> This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue. This seems like a rather manual way to go about things for which an automated solution can be devised. Such as create special ECC memory where you also account for entire cell failure with Reed-Solomon coding or s…
This is what make remote debugging possible. It is impossible to do interactive remote debugging over a ultra low bandwidth link. If everything have static address and deterministic static, you can have a exact copy on ground and debug there.
Earlier quoted context omitted.
The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".
Why is "no early returns" not a good rule? I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.
There is an element of taste. Don’t create random early returns if it doesn’t improve the code. But there are many, many cases where it makes the code much more readable and maintainable.
Earlier quoted context omitted.
You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?
I want some defined way to tell the compiler that I am intentionally ignoring the result. I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?
When my database logging fails, I write a file that logs the database fail (but not the original log file).
When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else.
Databases fail, file systems fill up. Logging logging failures is extremely important.
Earlier quoted context omitted.
> What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me. It's an interesting question and point, but those are two different things and there is no reason to think you'll get the same results. Why not compile from natural language, if that theory is true?
Natural language does not have a specification, while both C and assembly do.
I admit that's mostly philosphical. But I think saying 'C can autogenerate reliable assembly, therefore a specification can autogenerate reliable C' is also about two different problems.
Paging our Ada fanboys! You're missing it!
The same is true for the software that runs many satellites. Use of the STL is prohibited. The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can contin…
https://web.archive.org/web/20111219004314/http://journal.th... (referenced, at least tangentially, in the video) is a piece from the engineering lead which does a great job discussing Why C++. The short summary is "they couldn't find enough people to write Ada, and even if they could, they also couldn't find enough Ada middleware and toolchain." I actually think Ada would be an easier sell today than it was back the…
I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.
> And the F35 and America's combat readiness would be in a better place today with Ada instead of C++
What’s the problem with the F35 and combat readiness? Many EU countries are falling over each-other to buy it.
Earlier quoted context omitted.
The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".
Why is "no early returns" not a good rule? I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.