July 16, 2022

On Friday, 15 July 2022 at 09:27:51 UTC, LinguisticMystic wrote:

>

D seems to be a good one as it ticks all the boxes of C++ while fixing most (all?) of its flaws.

It was said before but I will repeat it. Try not to view D as C++ with its flaws fixed but as C with features added to it. If you would to expect D to behave like C++ you will get frustrated as D doesnt behave like C++ in some cases.

>

My necessary requirement is that the runtime should not include<...>

Im not surprised you wrote that. Zero cost abstractions and minimal runtime are like gospel in C++ circles. Its not 1990 anymore and in modern times these things almost dont matter when compared to memory copying, allocations and cpu cache usage. If you want your code to go fast pay attention to memory. One time a D project had a crown of being the fastest json parser in the world. It achieved that by avoiding making temporary heap allocations.
https://forum.dlang.org/thread/20151014090114.60780ad6@marco-toshiba

>

Does the [@nogc] switch apply globally, so that the compiled binary is free from GC code?

GC does not run periodically like a cron job. It can only runs when you are making an allocation. @nogc applies to a scope and compiler makes sure that no GC allocations occur in that scope. If you put @nogc at main() then your program cant allocate GC memory. If you never allocate from GC then its not going to be initialized. If GC is not initialized at all then its never used and code that's never used is not linked in final binary.

>

Is it better for me to look elsewhere if I don't want GC?

I dont think so. While D usage without GC is not streamlined I believe its still a better package as a whole compared to alternatives especially if you write green field projects.

If you want to write games in D you might be interested in this GDC talk
https://gdcvault.com/play/1023843/D-Using-an-Emerging-Language

July 17, 2022

On Saturday, 16 July 2022 at 22:23:36 UTC, welkam wrote:

>

It was said before but I will repeat it. Try not to view D as C++ with its flaws fixed but as C with features added to it. If you would to expect D to behave like C++ you will get frustrated as D doesnt behave like C++ in some cases.

Well, C++ has been distancing itself from C for a long time and new features makes this more and more true for modern C++.

C is a legacy language that is in for the long haul, but trying to merge higher level concepts with C leads to unnecessary complications. There are some decisions in D that undermines what C tries to achieve, like having wrapping signed int, having non zero default initialization for built in types and GC dependent language features.

In total, C++ is more of a C with features added, making C constructs and idioms more and more obsolete. Making C++ increasingly more high level.

D is more like an attempt to merge C, Java and templates, but trying to find a path back to C patterns while retaining some memory safety rather than providing abstractions of a higher level to deal with in optimization. It is unclear whether there is a market for C idioms. It might be waning...

July 17, 2022

On Sunday, 17 July 2022 at 05:36:37 UTC, Ola Fosheim Grøstad wrote:

>

There are some decisions in D that undermines what C tries to achieve, like having wrapping signed int, having non zero default initialization for built in types

Modern C compilers are "undermining what C tries to achieve" too. GCC has '-fwrapv' option for wrapping signed ints and '-ftrivial-auto-var-init=' option for preventing variables from being accidentally left uninitialized. There's also '-fno-strict-aliasing' option for eliminating the root cause of a certain class of hard to debug problems. All of this together forms a kind of somewhat safer non-standard C dialect, which is still fully compatible with the existing C code.

July 17, 2022

On Sunday, 17 July 2022 at 09:27:03 UTC, Siarhei Siamashka wrote:

>

Modern C compilers are "undermining what C tries to achieve" too. GCC has '-fwrapv' option for wrapping signed ints and '-ftrivial-auto-var-init=' option for preventing variables from being accidentally left uninitialized.

C-compilers have a gazillion of options, but the advantage of having zero-initialisation of heap allocated arrays is that you can bypass initialization if your memory manager zeros out memory for you.

>

There's also '-fno-strict-aliasing' option for eliminating the root cause of a certain class of hard to debug problems. All of this together forms a kind of somewhat safer non-standard C dialect, which is still fully compatible with the existing C code.

This is necessary because of existing (old) type punning practice.

1 2 3
Next ›   Last »