Bernie
Did you know that the C++ standard had library support for grabage collection?
And did you know that it's being removed in C++23 because nobody was using it?
There are several successful garbage collectors for C++, but their design differ from what's offered by std.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2186r2.html
#programming #cpp
Tenno Seremel, La ĉiela ombro
@codewiz So they garbagecollect the garbage collector… :blobcatthinking:
Maryam
@codewiz why would you need GC in cpp?
Bernie
@Maryam For graph structures where it's hard to track ownership using either unique_ptr or reference counting (shared_ptr, etc.).
Example domains where this happens often are compilers and game engines.
Bernie
@keadamander I just updated a firmware codebase to C++17, and I've been using C++20 on Android platform code before the standard was finalized 🙂
Modern C++ offers powerful compile-time evaluation, static data structures (std::array...) and more powerful data definition syntax, all of which come very useful on embedded systems.
keadamander
No surprise i didn't know that:
"Minimal support for Garbage Collection was added to C++0x in 2008"
I am still using C++98 for my larger embedded systems.
Bernie
@keadamander Did they also ban heap allocations, so that everything uses fixed-sized buffers with manual overflow checks?
keadamander
@codewiz
Do you want to sell me something? 😉
Military, Functional Safety, Realtime Systems (<100us hard realtime). Some only trust in C89 here.
In some situations you cannot decide which language to use, the customer just defines which standard and version you have to use.
Bernie
@keadamander All right, I agree that one shouldn't call the heap allocator from timing-sensitive parts of the application, but that's usually a tiny percentage of the codebase.
Allocating memory at startup, when reading config files, launching threads setting up data structures, should be fine.
It's also fine to allocate memory for network protocols, since they're subject to TCP flow-control. Even datagram protocols see jitter from CSMA/CD, switches, etc.
keadamander
it is not a good idea to use heap on real time systems due to inpredictability of runtime to allocate new memory and also fragmentation is a huge problem.
But no customer has to ban this, as it is self-evident.
Heap issues will always pop up in stress and system integration tests.
So yes, malloc/free and new/delete is banned for the real time critical processes/threads of the software.
fixed size memory (item) pools are more predictable and real time efficient here.
Bernie
@keadamander Heap fragmentation tends to be a bigger problem with simpler allocators and when the heap is very tight.
Many modern allocators keep it under control with fixed-size pools for small allocations, and mmap() for multi-page allocations.
Once you get to mmap(), process address-space fragmentation could still be a problem for 32-bit code, but not for 64-bit code.
Bobinas P4G is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Bobinas P4G content and data are available under the Creative Commons Attribution 3.0 license.