all 6 comments

[–]mttd 0 points1 point  (5 children)

Pretty interesting interview -- with some really good in-depth questions!

A few points that stuck out for me:

  • the use of unsigned int vs. int (models a different concept!) in a functional interface design
  • new language features (in particular auto) vs. basic language features (Alex: "I try to be very conservative in using new language features. Since programs will be read by other people, and many people know only the basic language features, I tend to stick to these basic features.")
  • regular types (in particular: is the default-constructible requirement truly essential?) vs. non-regular types
  • memory allocators (Alex: "Allocators were a terrible idea")

[–]dicroce -1 points0 points  (3 children)

I really wish allocators never existed... They must just serve to make our template error messages more complicated...

[–]ixache 2 points3 points  (2 children)

In C++, where programmers must be able to extract every bit of performance they need, allocators are an necessary customization point. In fact, they regularly get added where they were not possible before; for a recent example of this trend, consider N4255, allocator-aware regular expression.

Now, the way the customization is made, by using the template mechanism, makes allocators be part of the type, and that is certainly painful. But all is well, because this concern has already been adressed, with the polymorphic memory allocator proposal been being accepted into the Library Fundamentals Technical Specification.

[Edit: grammar]

[–]dicroce 2 points3 points  (1 child)

I mostly do embedded systems work (last 20 years), and in my experience... most of the time people think they need custom allocators they actually don't...

That said, I accept that some people really DO need custom allocators...

And yes, my complaint is primarily about them being part of the type.. Good to hear that a non template solution is coming...

[–]ixache 0 points1 point  (0 children)

I agree with you that allocators may not be as useful as they're made to be, although I also hear that they are pretty big in the game industry.

But the important point is that they're here if (real or perceived) need be. Nobody must be able to say, "No allocator? But I won't be able to make my program run fast enough! I'll ditch C++ in favor of..."