On 05-Oct-2015 09:52, Shachar Shemesh wrote:
On 04/10/15 19:14, welkam wrote:
On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
these tools are not very good and they don't help when the standard
library(...or builtin language features...) use the GC and tie your
hands
IMO tools for memory management in D are way better than that of other
languages. Game developers who use c++ dont use all of c++
features(templates, exceptions), because they care about performance the
same can be said about D. Yes some features use GC heap, but you can
just not use it. Or you can use so little that GC collection wont even
kick in. With Go you have no real option but to use GC.
When D structs has a destructor that is guaranteed to run for any
instance that finished construction, no matter what is the use case,
then we can have that discussion.
Supposed to be the case for structs except for any bugs.
Until then, no, D's mechanisms for non-heap allocations are vastly
inferior to C++'s.
Well need some helpers for RC/on stack classes plus kill that horrible
extra monitor field.
Otherwise I fail to see how. Plus with D's everything is movable by
default. I mean I can memcpy D's structs just fine _by spec_ provided
that I bitblit T.init over the source.
In C++ you can't - not only self-references are permitted but also there
is no T.init so there is no bit-pattern that is guaranteed to not
explode in dtor.
Shachar
--
Dmitry Olshansky
