12 ms·

What implicit memory allocation are you talking about?

• mgaunard 5y ago
  The only thing I can think of that allocates is throwing an exception (nad that's an ABI-specific strategy), but I doubt that's what he means.
• woodruffw 5y ago
  They might be referring to how easy it is to accidentally/unwittingly invoke the copy constructor in C++. `Foo x = Foo();` used to be the famous example of that, although more recent versions of C++ may guarantee that the copy is elided there. Another good example is implicit comparison conversions, e.g. some class defines `operator==` as non-explicit and any code that does `x == y` where `typeof(x) != typeof(y)` may find itself going though a possibly-allocating constructor.
  • int_19h 5y ago
    Allocations in this context usually refers to heap allocations. Temporaries aren't heap-allocated.
    • woodruffw 5y ago
      Temporaries may or may not be heap-allocated; the C++ spec doesn't specify. But even beyond that: you can have a non-trivial constructor that requires heap allocations internally. So even relying on (sane) compiler-defined behavior won't save you in the general case.
      • MaxBarraclough 5y ago
        > Temporaries may or may not be heap-allocated; the C++ spec doesn't specify. Presumably the same is true of C.
      • int_19h 5y ago
        Are there any C++ implementatons that actually heap-allocate temporaries? The only context where I can imagine that happening is an async (as in co_await) function, where all autos might need to be heap-allocated for obvious reasons. But that aside, it just seems like a very weird choice that would have profound perf implications - to the point of removing pretty much the sole remaining advantage of the language - for no gain whatsoever, since it's not even simpler. As for non-trivial ctors - at that point you might as well worry that every function call made in pure C code can also heap-allocate, no?