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

To Continue Play Video, Please Click Ads & Closed Here, Thank you ×


http://www.Cppcon.org

std::allocator Is to Allocation what std::vector Is to Vexation

Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/cppcon/cppcon2015

std::allocator has an inglorious past, murky present, and cheerless future. STL introduced allocators as a stop gap for the now antiquated segmented memory models of the 1990s. Their design was limited and in many ways wasn’t even aiming at helping allocation that much. Because allocators were there, they simply continued being there, up to the point they became impossible to either uproot or make work, in spite of valiant effort spent by the community.

Popular Posts :

But this talk aims at spending less time on poking criticism at std::allocator and more on actually defining allocator APIs that work.

Scalable, high-performance memory allocation is a topic of increasing importance in today’s demanding applications. For such, std::allocator simply doesn’t work. This talk…

c++ coding

20 thoughts on “CppCon 2015: Andrei Alexandrescu “std::allocator…”

  1. I really enjoy your talks, not only informative but sometimes fun as well 🙂

    Such a talent wasted in such a crappy evil company like Facebook (which is now implementing measures to destroy freedom of speech and opinion).

  2. Can anyone answer me a question? I'm not very experienced in c++ and this talk left me a doubt…
    Say that I implement all of these allocators…however I could have a class that contains an std::list…this will be probably allocated with mallocs, how are these allocator going to help me with that?

  3. operator new is a function essentially the same as malloc. No type information. It does not call constructors. You mean to refer to a "new expression" which uses the keyword and has complex behavior implemented by the compiler, which includes calling operator new, checking the result, and calling the constructors.

  4. In 1983, the C programming language did not have a void* type. We used char* and at least some of us used a typedef to indicate I really had unspecified stuff (I used 'ambi'). The void and void* types, along with features like allowing different structures to have members of the same name, were added later.

  5. 1:12 – you don't need to keep the file and line number, it is enough to keep the return address (__builtin_return_address on gcc), you can then get the source/line number from debug information (addr2line).

  6. Andrei makes it sound like goodSize is useful for wrapping the argument to allocate, but why not just have allocators return the good size (the actually allocated size, and not the requested size) in Blk, which callers can read to find out how much they really got? Is there any other use for goodSize? Any reason to know goodSize without calling allocate?

  7. On slide 29 the `owns` should have && instead of ||, no? The size needs to be the same and it needs to come from the parent allocator. Also, this assumes that no two FreeList for the same size will be created with the same parent allocator.

  8. The things he describes do not integrate well with the current STL implementation. In fact, that is one of the keystone statements. The next iteration of the STL (aka. STL2) is currently being designed which will be a complete revamp of everything. The STL has many historic garbage in it that are rooted too deeply into the entire system. Allocators for one is one such entity. You cannot change its API without having to touch just about everything.

  9. just found the hole in my argumentation: you don't get size_t as an input in free() in an std::allocator, do you? so you'd have to keep track of that seperately. This sucks >.<

  10. You'd have to write wrapper code to "unpack" the struct Blk into size_t and void*. Maybe some day std::allocator will be gone and something like this will be added to the standard, but until then, you'd have to write a wrapper.

    You could also write a std::allocator that does only one thing: pass stuff on to an instance of YourComposableAllocatorType (YCAT). You actually use the YCAT instance for your code, but "dumb" code like std::something can use the std::allocator as a shim.

  11. This is great! I'm a huge fan of Andrei. He gave a similar talk about allocators in D. I was hoping for a C++ treatment of the same topic.

    What's with the comments about no profilers on OS X? I don't know why he would think that. Does Instruments not fit the bill?

  12. Great talk, but there's one thing I do not quite understand.

    He's suggesting to stay away from operator new and std::allocator, but how are you supposed to implement given Allocators globally, if not by using either of those tools?

    I see how you're able to use them for your own stuff, but can't get an idea how to make it work for std::vector or std::string for example. You can write your own std::allocator, sure, but they're still using size_t and void* as Input, and not struct Blk.

Leave A Comment

Your email address will not be published. Required fields are marked *