C++ or D?

[Ola Fosheim Grøstad]

On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote:
> Meanwhile I believe C++ (keep in mind I very rarely touch or 
> look at C++) already has a standard allocator interface that 
> parts of the STL (and I assume libraries, when/if they care) 
> are able to use? I'm unaware of the issues it might have in 
> C++, but that's mostly because of my lack of use and knowledge 
> of the language. It has standard pointer types, etc.

So, C++ had the same issues as D prior to C++11, that you had 
many many different options, but none of them were standard... 
Which was ok if you used one big framework, but if you wanted to 
mix libraries... yuck. Since C++11 things are looking better 
although it obviously takes time for frameworks/libraries to 
catch up.

In C++ everything is up to the library/programmer so there is 
basically no way for the compiler to be particularly clever with 
heap allocations, although it can be clever with values (e.g. 
stack allocations).  So, that is an area where D could be bold 
make the compiler smart, and do better than C++, but that takes 
some courage.

C++ smart pointers do allow for custom allocators, but then the 
owning pointers will have an extra field for referencing it, 
which is used for deallocation. I suspect most people don't use 
it, but it might be important for creating nice C++ wrappers for 
C libraries?

> I wonder what problems D faces in comparison to C++ and other 
> languages in this regard, since it's been in a limbo, 
> fragmented state for a while now.

Mostly a lack of strategic decision making? Just map out the 
various alternatives and pick a combination that is "wholesome".

(Do you want to be a bird and fly or a fish that can swim? Being 
neither bird nor fish isn't working in the long run, I don't 
think so.)