3 ms·

No, modulo the aligned allocation overloads, but applications are allowed to override the default standard library operator new with their own, even on platform

No, modulo the aligned allocation overloads, but applications are allowed to override the default standard library operator new with their own, even on platforms that don't have an equivalent to ELF symbol interposition.

masklinn 2y ago
That doesn't really explain where the dependency on the C++ runtime come from tho, as far as I know the dependency chain is std::allocator -> operator new -> malloc, but from the post the replacement only strips out the `operator new`. Notably I thought the issue would be the throwing of `std::bad_alloc`, but the new version still implements std::allocator, and throws bad_alloc. And so I assume the issue is that the global `operator new` is concrete (it just takes the size of the allocation), thus you need to link to the C++ runtime just to get that function? In which case you might be able to get the same gains by redefining the global `operator new` and `operator delete`, without touching the allocator. Alternatively, you might be able to statically link the C++ runtime and have DCE take care of the rest.
- kllrnohj 2y ago
  Yes they could have just defined their own global operator new/delete to have a micro-runtime. Same as you'd do if you were doing a kernel in C++. Super easy, barely an inconvenience
  - vitaut 2y ago
    Changing global new/delete is a non-starter in a reusable library. Allocator is a much more localized change and roughly the same amount of work.
- gobblegobble2 2y ago
  > Notably I thought the issue would be the throwing of `std::bad_alloc`, but the new version still implements std::allocator, and throws bad_alloc. The new version uses `FMT_THROW` macro instead of a bare throw. The article says "One obvious problem is exceptions and those can be disabled via FMT_THROW, e.g. by defining it to abort". If you check the `g++` invocation, that's exactly what the author does.
  - masklinn 2y ago
    The author also compiles with `-fno-exceptions` which should already have the same behaviour.

masklinn 2y ago

That doesn't really explain where the dependency on the C++ runtime come from tho, as far as I know the dependency chain is std::allocator -> operator new -> malloc, but from the post the replacement only strips out the `operator new`. Notably I thought the issue would be the throwing of `std::bad_alloc`, but the new version still implements std::allocator, and throws bad_alloc. And so I assume the issue is that the global `operator new` is concrete (it just takes the size of the allocation), thus you need to link to the C++ runtime just to get that function? In which case you might be able to get the same gains by redefining the global `operator new` and `operator delete`, without touching the allocator. Alternatively, you might be able to statically link the C++ runtime and have DCE take care of the rest.

kllrnohj 2y ago
Yes they could have just defined their own global operator new/delete to have a micro-runtime. Same as you'd do if you were doing a kernel in C++. Super easy, barely an inconvenience
- vitaut 2y ago
  Changing global new/delete is a non-starter in a reusable library. Allocator is a much more localized change and roughly the same amount of work.
gobblegobble2 2y ago
> Notably I thought the issue would be the throwing of `std::bad_alloc`, but the new version still implements std::allocator, and throws bad_alloc. The new version uses `FMT_THROW` macro instead of a bare throw. The article says "One obvious problem is exceptions and those can be disabled via FMT_THROW, e.g. by defining it to abort". If you check the `g++` invocation, that's exactly what the author does.
- masklinn 2y ago
  The author also compiles with `-fno-exceptions` which should already have the same behaviour.