CppCon 2015: Andrei Alexandrescu “std::allocator...”

Actually it is C's malloc and free that is "broken". malloc() takes a size parameter, but free() doesn't. This imbalance means it can never be maximally efficient. Whatever GNU stdlibc++ is doing is probably, on balance, a net win for most programs. It's not exactly roses in C++ either of course. You can do better than the standard library facilities. Andrei Alexandrescu gave a great, entertaining, and technically elegant talk on memory allocation in C and C++ at Cppcon 2015 that is well worth watching ▶ this video

in “The Horror in the Standard Library” · View on HN

Allocators have an inherently broken design, tying them to types. See this CppCon talk by the (engaging and funny) Andrei Alexandrescu: ▶ this video std::allocator is to allocation what std::vector is to vexation (or: designing allocators that don't not-work)

in “C++ Should Be C++” · View on HN

I come from the opposite camp. I detest functions that are five pages of boolean logic, which I guarantee you contain at least a dozen bugs, no matter how much you think you've tested it. Code coverage is like those skin creams that say "Scientifically tested!" on the label. Yeah, well, tested doesn't mean that it worked. It just means that there was a test. Watch this video of Andrei Alexandrescu's talk in CppCon 2015: ▶ this video I've done things like this in my career, and it's always worked out brilliantly . Bugs just evaporate when you let the compiler "combine" things for you, instead of just plopping everything into a bowl and mashing it together with your hands like some sort of animal. Especially in today's C++ or Rust, you can "have your cake and eat it too". It's possible to build up these nice, single-purpose class hierarchies and combine them into complex, powerful constructs via templates / traits. The compiler takes care of the edge cases for you, because it never gets bored or distracted. There's no performance downside because of static dispatch, inlining, and aggressive optimisers.

in “How to write untestable code (2008)” · View on HN

Andrei Alexandrescu had a great talk[0] on allocators and this convinced me that if you really care about allocator performance[1] what you need is a tunable and composable system. The whole idea of how and when (runtime/compile-time) to choose the appropriate allocator is also interesting. [0] ▶ this video [1] I suppose there's a digression to be had here about allocation being trivial and RAII-style deallocation not really being deterministic, but...

in “Mimalloc – A compact general-purpose allocator” · View on HN

Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to avoid fragmenting the heap). Related, Andrei Alexandrescu had a great talk about allocators in C++ a couple of years ago: ▶ this video Also related to the Orthodox C++, the same engine also ousted exceptions and RTTI. I'm not sure about the reason for exceptions, but C++'s RTTI was simply inadequate and instead it was replaced with a custom one made using macros (similarly to wxWidgets and MFC) that allowed automatic object serialization and reflection which was used for all saving and loading, exposing objects to the editor automatically with a common UI and exposing classes and objects to the (custom) scripting language with very little setup. Interestingly most of the stuff the engine had to reinvent seem to be first class citizens in the D language. Also Andrei's allocators also seem to be available (experimentally) there too. Personally i prefer plain old C (C89 even, although with a few commonly available or easily reproducible extras like stdint) because i see C++ as too complex for what it is worth. However D seems to provide more power with less complexity and

in “Show HN: Crown – A flexible game engine written from scratch in C++” · View on HN

More to the point, the comment in the code mentions the “combinatorial” explosion of conditions that have to be carefully maintained by fallible meat brains. In most modern languages something like this could be implemented using composition with interfaces or traits. Especially in Rust it’s possible to write very robust code that has identical performance to the if-else spaghetti, but is proven correct by the compiler. I’m on mobile, so it’s hard to read through the code, but I noticed one section that tries to find an existing volume to use, and if it can’t, then it will provision one instead. This could be three classes that implement the same interface: class ExistingVolume : IVolumeAllocator class CreateVolume : IVolumeAllocator class SeqVolumeAllocator : IVolumeAllocator The last class takes a list of IVolumeAllocator abstract types as its input during construction and will try them in sequence. It could find and then allocate, or find in many different places before giving up and allocating, or allocating from different pools trying them in order. Far more flexible and robust than carefully commented if-else statements! Similarly, there's a number of "feature gate" if-else statements adding to the complexity. Let's say the CreateVolume class has two variants, the original 'v1' and an experimental 'v2' version. Then you could construct a SeqVolumeAllocator thus: allocator = new SeqVolumeAllocator( featureFlag ? new CreateVolumeV2() : new CreateVolumeV1(), new ExistingVo

in “Please do not attempt to simplify this code” · View on HN

> Isn’t polymorphic memory allocator the most significant recent C++ addition for embedded systems I would say no. Run-time polymorphism is overrated IMHO, and more so for embedded systems, again IMHO. C++ in general has been moving towards preferring things happening statically rather than dynamically. > that allows preventing runtime memory allocation after the init phase That's not what allows preventing runtime memory allocation after an "init phase". Unless I'm misunderstanding what you mean. ... oh, I think I get it: As a general rule, avoid using standard library data structures with allocators. They may work fine as boilerplate, but are usually not what you want when you have any non-trivial requirements. std::vectors are fine if you don't mind the allocations - but you do, so not even those. You could use custom allocators, but that whole mechanism is totally broken design in the opinion of many; see Andrei Alexandrescu's talk about this subject: ▶ this video

in “C++17’s Useful Features for Embedded Systems” · View on HN

I see something like this and think about how much an ensemble approach to the data structure would help. This keeps popping up in places where you have a very general abstraction (like the DOM) and want to support a broad set of operations and use cases (read-only, insert heavy, traversal heavy, etc.) and so you often choose the structure which supports most of these cases pretty well. But you sacrifice a lot of perf by doing so. What I'm wondering is how well you could do perf-wise by having the DOM be comprised of a heterogeneous set of structures, each of which is chosen based on the history of what operations have been performed on it (ie. we're appending a lot here, let's use a vector of children). This is all similar in spirit and goals of: - JIT compiling, but for the data structures, and not code - This work on composing allocators in D ▶ this video - ML ensemble methods

in “Modernizing the DOM Tree in Microsoft Edge” · View on HN

In my line of work (real-time), C++ typically reigns supreme but D is just as fast and more productive, so why not use it? It's not really about meta-programming, for me it wins on the basics. And is we talk meta-programming, I think D goes further in the Stepanov style: ▶ this video

in “Metaprogramming is less fun in D” · View on HN

As Andrei Alexandrescu famously said, "Allocator is to allocation what alligators is to allegation" ▶ this video

in “I was surprised by how simple an allocator is” · View on HN