Jeremie Pelletier wrote:
Tom S Wrote:
Jeremie Pelletier wrote:
I haven't had to use the C heap whatsoever so far in D, could you give me an
example of where you need it? In fact, the *only* place I use the C heap is in
my garbage collector's internals, for pool structs and mark ranges. I use
pointers to GC memory all the time too, there are plenty of algorithms,
especially in loops, that can run faster with pointer arithmetic than slices
and it's still the fastest way to pass struct references around.
I use the C heap a lot when I need slabs of memory that the GC should
not look into for performance reasons. This includes images/textures,
mesh data and some data structures that I release manually - again, for
efficiency reasons.
The garbage collector in D already mark allocations which contains pointers and
scans these only. If you want to know if a type contains pointers, check the
'flags' property of the typeinfo or classinfo, test for bit0 and bit1
respectively. This is what the GC uses at runtime when allocating memory to
know if it should tag the allocation as containing possible pointers.
Yea I know, but I want structures with pointers manually managed as well.
I myself allocate all my meshes and textures directly on the GC and I'm pretty
sure its faster than C's malloc and much safer.
Hm, why would it be faster with the GC than malloc? I'm pretty sure it's
the opposite :P Plus, I could use a specialized malloc implementation,
like TLSF.
- I like how D doesn't totally ignore safety as C does, in D sometimes the default
way is the safer one, and the unsafe way is used only where you ask for it. I'd
like to see more safeties added to D, like optional run-time and compile-time
integral overflow tests, some pointer safety, better template error messages
(template constraints help some in such regard), stack traces, less compiler bugs,
safer casts (in C# you need explicit casts to convert double => float), a safer
printf, some optional annotations inspired by Plint (a lint program) to give more
semantics to the compiler, that can be used to both speed up code and avoid bugs.
There's lot that can be done in this regard. And release-mode performance can be
usually kept unchanged.
Stack traces is a feature for the runtime, I made one for mine, which shows a
dialog window with the stack trace, current registers values, loaded modules
and whatnot. Took me almost a week to piece together my CodeView reader, I
still need a DWARF reader for linux. I'm gonna try and implement it in druntime
and submit the patch to bugzilla.
Tango's runtime already does stack tracing on Windows and *NIX, however
its CV parser is subject to some licensing issues :( Perhaps you could
release yours under some liberal license so it can be plugged there? :)
Sure, I wouldn't mind at all, I'm not into licenses myself so I might just
release it to public domain. I'll try and get a standalone package ready and
post it somewhere, I just don't know where yet :x
Sweet :D As for a place, there are plenty of options, e.g.
http://dsource.org/projects/scrapple/ or a separate dsource project.
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
