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