4 ms·

I'm going to dig deep here, and say that true flexibility in memory allocation would require multiple global implementations of new, and when an object is delet

• coliveira 13y ago
  Ok, so let's count... Just from the top of my head, we have global new/delete overloading. At the class level you have new/delete overriding. Then you have allocators that can be used with any STL container. In you templates you can also have custom allocators. Then you have new with placement syntax, which means that you can allocate memory with anything, including something like malloc or gmalloc. Of course, you can also use the stack for automatic memory... You can even use a garbage collector such as Boehm. And you really want to argue that there are no options for memory allocation in C++?... The problem with C++ is exactly the opposite, it has too many options, which makes it difficult to create a global memory management policy, unless you define you own complete framework. Quite the opposite of what you said.
  • comex 13y ago
    I'm not sure whether the previous poster was thinking along these lines, but in some sense C++ makes it harder to control allocations compared to C due to a combination of increased abstraction and a general assumption that objects are fixed size. For example, if a C struct contains an array whose size is known at the time of allocation, there's a good chance the elements will be located after the end of the struct rather than being in a separate allocation. Of course, you could do this in C++, but neither language nor library provides sugar, so it ends up looking unnecessary compared to just using a std::vector. I won't opine on whether it actually is unnecessary.
    • mpyne 13y ago
      Well at a language level C++ shares more or less the same behavior as C. If you input the same "plain old data" struct into C++, with an array whose size is known at compile-time, it would be placed where C places it. Now you're correct that the standard library provided with C++ does not quite give you this same level of control. If you want node elements placed somewhere specific you either have to pick the right container, write a custom allocator (including rebind support so that any required container-internal elements also can use your allocator), etc. But this is a complaint about a C++-only feature that C doesn't even provide. On the very few times that C does provide an standard library function that will automatically allocate storage from the heap, it is even less customizable than the C++ equivalent. Normally your only option is something allocated with malloc(3), you're told to use free(3) when appropriate, and if you need something different you run into trying to replace malloc/free and friends and then somehow telling your custom malloc when to use custom behavior and when to use stdlib behavior. But you could do this in C++ code too. Now you can certainly easily write your own library with better support for custom allocation/deallocation. Things like the Apache Portable Runtime, for instance, or glib. But once you've bought into the idea of simply ignoring the language standard library anyways, you've bought into something else that you could do in C++ if you really felt like it were useful. The problem with C++ is that the standard library makes it almost straightforward to do what you want and still be able to use standard containers without having to write your own, but we have to remember that we're talking about a problem that essentially can't even be spoken about in C. So it's not so much that C "doesn't have a problem", as that this problem couldn't even be expressed in C.