Template Metaprogramming Made Easy (Huh?)

Jeremie Pelletier jeremiep at gmail.com
Sun Sep 13 17:16:25 PDT 2009


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.

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.

> >> - 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



More information about the Digitalmars-d mailing list