Template Metaprogramming Made Easy (Huh?)

[Jeremie Pelletier]

Tom S Wrote:

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

Then just inform the GC to not scan the allocations you want, or better yet have a static ctor modify the flag of the typeinfo you don't want scanned.

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

The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both.

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

I thought of that, but I don't feel like opening a project for just a few random code snippets or standalone classes. I think I'll just post it in this forum and let interested people grab it for now.