Re:Why is the first C++ (m)allocation always 72 KB?
by danhor on Monday March 02, 2026 @05:13AM
(#47215981)
It's often a requirement for bare metal embedded development (too heavy in terms of memory), so it's basically unavoidable. Non-standard languages are very common for this kind of thing, just look at the linux-flavoured C.
Re:Why is the first C++ (m)allocation always 72 KB?
by surajrmal on Monday March 02, 2026 @08:56AM
(#47218011)
Even rust let's you turn panics into asserts. It saves a lot of binary size and arguably is equally debugable. We also see improved performance from being more cache friendly. C++ usage wouldn't be nearly as high if there wasn't such an option. As far as I'm concerned the primary downside is not being able to return errors in constructors and handle allocation failures but both are solve able via some common idioms (static methods and custom placement new)
Re:Why is the first C++ (m)allocation always 72 KB?
by pjmlp on Monday March 02, 2026 @09:35AM
(#47218464)
Constructors and destructors can have function level try-catch blocks.
Yes the syntax could have been much better.
As proven by ongoing work done by Khalil Estell, in some embedded scenarios exceptions aren't that great only due to quality of implementation, someone added the support and call it done, no effort at all to improve it.
Even Ada's Ravenscar profile does allow for exceptions in high integrity computing scenarios, in embedded systems.
Well I for one, if that would mean less "C programming with C++ compiler" that still plagues the security history to this day, great they can keep using C for that.
It was introduced for historical compatibility reasons, it is not officially supported on the standard, but some folks really keep on using non-standard language, spitting the libraries ecosystem.