On 7/6/18 11:53 AM, Ecstatic Coder wrote:
Of course, the answer in C++ is that it won't compile, this is D code! ;)
Seriously ?
No, not seriously! I realized what you meant.
I wrote : "And what about the same code in C++ ?"
I thought people on this forum were smart enough to understand "the C++
port of this D code".
It was a point that we are delving into the absurd, saying "it depends
on what type point_value is".
I'm sorry to have been wrong on this.
Sorry I made it seem like I was serious, my humor can be very dry sometimes.
Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++
string code may not be performant, but in C++, even if you make
allocations/deallocations during the game loop, this won't be good for
the game performance, but that's all.
This is the reason why most game people shy away from D code. Because
the GC is so inherent in the language, it's difficult to prove that you
can call any function without incurring a possible GC cycle.
The two ways around this are to use @nogc, or to turn off the GC when
you don't want it to run.
The blog has a whole series on working with and without the GC in D.
With D, ANY forgotten allocation during the game loop (and I really mean
even JUST ONE hidden allocation somewhere in the whole game or engine),
may cause the game to regularly freeze at the wrong time, because of an
unwanted GC. Hence the phobia.
This is why you use @nogc. You then can't forget such things. But then
of course, you need to avoid a lot of D niceties.
-Steve
