6 ms·

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same an

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't seem to be something that only Zig can do.

logicchains 6y ago
A concrete example is std::stable_sort. As far as I'm aware there's no way to pass it a custom allocator/buffer to avoid it allocating memory.
- cycloptic 6y ago
  Thank you for the example.
voldacar 6y ago
It isn't really a matter of can do/cannot do. It's more about the default patterns promoted by the idiomatic way of writing code. Yeah you could write C++ code that constantly passes around allocators while also using STL heavily, but it will be verbose, unnatural, and ugly. As well as having nicer syntax in general and real metaprogramming instead of the brain damage that is templates, zig promotes this kind of allocator-aware programming style in a way that's clean and idiomatic
- cycloptic 6y ago
  I'm not sure what you mean that it's verbose, unnatural and ugly. To me it looks the same. In C++, you have to pass around an allocator to your templates. You can typedef this away if you want. In Zig, you have to pass around an allocator as a function argument or a struct member. You can comptime this away if you want. Is there some fundamental way that I missed that Zig changes this? If your actual complaint is that C++ templates are bad and you're saying Zig comptime is better, that's different than having woes about allocators.
  - fsociety 6y ago
    The difference is you have to pass an allocator to the standard library functions in Zig. That’s why it is idiomatic compared to C++.
  - voldacar 6y ago
    have fun trying to globally override new and delete in C++ (hint: there is no way to do this)
    - cycloptic 6y ago
      Are you sure? https://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements https://en.cppreference.com/w/cpp/memory/new/operator_new#Gl... You don't need to do this if you're using allocators.
mwkaufma 6y ago
Many core modern C++ types don't permit customizing the allocator. E.g. std::function
- mwkaufma 6y ago
  Furthermore, C++ dependencies commonly instantiate types like std::vector with the default allocator internally, rather than exposing it to the host application.
  - cycloptic 6y ago
    Thank you for the examples. I'm not sure std::function is a good comparison. After some research it seems this used to be in the spec, but it was removed because nobody supported it correctly and it seems it was too difficult to do it in a type-safe manner anyway: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p030... The other thing is that Zig doesn't seem to have any real plans to support C++-style closures right now. If they ever find a type-safe way to do it while supporting custom allocators, then that would be interesting, but at the moment I wouldn't say it's any better than C++ in this regard. I actually have seen some C/C++ libraries that do allow changing the default allocator although it's usually only low-level libraries that bother to do this.
    - int_19h 6y ago
      C++-style closures are unrelated to custom allocators, since they're not heap-allocated.
      - mwkaufma 6y ago
        You are correct that the type the compiler creates for a lambda is allocated in-place, usually on the stack, and perform no heap-allocs. However if you pass it to a std:: function it will be _boxed_ and std::function _will_ heap alloc the space for it. This alloc is what's not customizable.

logicchains 6y ago

A concrete example is std::stable_sort. As far as I'm aware there's no way to pass it a custom allocator/buffer to avoid it allocating memory.

cycloptic 6y ago
Thank you for the example.

voldacar 6y ago

It isn't really a matter of can do/cannot do. It's more about the default patterns promoted by the idiomatic way of writing code. Yeah you could write C++ code that constantly passes around allocators while also using STL heavily, but it will be verbose, unnatural, and ugly. As well as having nicer syntax in general and real metaprogramming instead of the brain damage that is templates, zig promotes this kind of allocator-aware programming style in a way that's clean and idiomatic

cycloptic 6y ago
I'm not sure what you mean that it's verbose, unnatural and ugly. To me it looks the same. In C++, you have to pass around an allocator to your templates. You can typedef this away if you want. In Zig, you have to pass around an allocator as a function argument or a struct member. You can comptime this away if you want. Is there some fundamental way that I missed that Zig changes this? If your actual complaint is that C++ templates are bad and you're saying Zig comptime is better, that's different than having woes about allocators.
- fsociety 6y ago
  The difference is you have to pass an allocator to the standard library functions in Zig. That’s why it is idiomatic compared to C++.
- voldacar 6y ago
  have fun trying to globally override new and delete in C++ (hint: there is no way to do this)
  - cycloptic 6y ago
    Are you sure? https://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements https://en.cppreference.com/w/cpp/memory/new/operator_new#Gl... You don't need to do this if you're using allocators.

mwkaufma 6y ago

Many core modern C++ types don't permit customizing the allocator. E.g. std::function

mwkaufma 6y ago
Furthermore, C++ dependencies commonly instantiate types like std::vector with the default allocator internally, rather than exposing it to the host application.
- cycloptic 6y ago
  Thank you for the examples. I'm not sure std::function is a good comparison. After some research it seems this used to be in the spec, but it was removed because nobody supported it correctly and it seems it was too difficult to do it in a type-safe manner anyway: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0302r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p030... The other thing is that Zig doesn't seem to have any real plans to support C++-style closures right now. If they ever find a type-safe way to do it while supporting custom allocators, then that would be interesting, but at the moment I wouldn't say it's any better than C++ in this regard. I actually have seen some C/C++ libraries that do allow changing the default allocator although it's usually only low-level libraries that bother to do this.
  - int_19h 6y ago
    C++-style closures are unrelated to custom allocators, since they're not heap-allocated.
    - mwkaufma 6y ago
      You are correct that the type the compiler creates for a lambda is allocated in-place, usually on the stack, and perform no heap-allocs. However if you pass it to a std:: function it will be _boxed_ and std::function _will_ heap alloc the space for it. This alloc is what's not customizable.