C's Biggest Mistake on Hacker News

[Ecstatic Coder]

On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>> On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
>>> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder 
>>> wrote:
>>>> So, at the moment, I don't see how you can EASILY convince 
>>>> people to use BetterC for C/C++ use cases, like programming 
>>>> games, microcontrollers, etc.
>>>
>>> *Extremely powerful meta programming that blows c++ meta 
>>> programming out of the water
>>> *Clean readable syntax
>>> *No header file nonsense
>>> *Standard keyword for ASM if you really need the performance 
>>> boost.
>>> *Compiler enforce memory safety.
>>>
>>> -Alex
>>
>> I know.
>>
>> And D's builtin strings/arrays/slices/maps/etc and automatic 
>> memory deallocation are part of what makes D a better 
>> alternative to C++ too.
>
> No. For many C++ users, tracing GC is absolutely not an option. 
> And, if it were, D's GC is not a shining example of a good GC. 
> It's not even precise, and I would bet that it never will be. 
> If I'm able to tolerate a GC, there are languages with much 
> better GCs than the D one, like Go and Java.
>
> I work in a mostly C++ shop where exceptions are intolerable in 
> C++ code, and in many places we use CRTP to eliminate dispatch 
> overhead. DasBetterC would be usable here but it's too late 
> given the existing investment in C++. Obviously there's no CRTP 
> in DasBetterC without struct inheritance, but there are other 
> designs to address this issue.
>
> Besides having more betterC libraries, I'd like to see some 
> kind of restricted approach to exception handling, like the 
> ones being investigated in 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf. If you want a better C++, look at what people who have to use C++ use it for, and where the pain points are.

I agree.

What I leant is that after having built several realtime 3D 
engines using simoly strong/weak references to transparently 
release unused objects, I don't see why such features couldn't be 
integrated in a language like D as a core feature (T,T^,T*), 
instead of being a template library.

This gets the job done, and while not perfect, this remains very 
handy. A cycle detector is only required as a debugging tool.

All you need is 3 kinds of pointers:
- strong reference
- weak reference
- raw pointer

And, unfortunately, more discipline to manage mutual references 
yourself, instead of letting the GC manage that for you. So in 
some cases, having an optional cycle colkector can be very useful 
when using D in a Go-like way...