Disadvantages of building a compiler and library on top of a specific memory management scheme

Frustrated c1514843 at drdrb.com
Thu Feb 6 11:57:49 PST 2014


On Thursday, 6 February 2014 at 18:41:25 UTC, Namespace wrote:
> I like the idea, but instead of new!strategy I would prefer:
> use @strategy(RefCount)
> or
> use @strategy(GC) // Default
>
> We would have in druntime some functions which are tagged with 
> @strategy(Whatever) (which are invoked if the use comes):
> ----
> @strategy(C_Memory)
> T[] new(T : U[], U)(size_t count) {
> 	return (cast(U*) calloc(count, T.sizeof))[0 .. count];
> }
>
> @strategy(C_Memory)
> void delete(T : U[], U)(ref U[] arr) {
> 	free(arr.ptr);
> 	arr = null;
> }
> ----
>
> It's not perfect, just a thought.

I'm sure there are a lot of ways to do it. I think the hard part
is coming up with a cohesive and elegant solution that is
efficient. By providing an allocation strategy we can deal with
specific memory issues.



More information about the Digitalmars-d mailing list