Replacing C's memcpy with a D implementation

Walter Bright newshound2 at digitalmars.com
Mon Jun 11 10:07:39 UTC 2018


On 6/11/2018 1:12 AM, Mike Franklin wrote:
> On Monday, 11 June 2018 at 08:00:10 UTC, Walter Bright wrote:
> 
>> Making it a template is not really necessary. The compiler knows if there is 
>> the possibility of it throwing based on the type, it doesn't need to infer it.
> 
> There are other reasons to make it a template, though.  For example, if it were 
> a template, it would not rely on `TypeInfo` and could then be used in 
> -betterC-like situations.

We have no design for this function that doesn't rely on the GC, and the GC 
needs TypeInfo. This function is not usable with betterC with or without the 
TypeInfo argument.


> I think there might also be optimization opportunities using templates, 
> metaprogramming, and type introspection, that are not currently possible with 
> the current design.

Just making it a template doesn't automatically enable any of this.


> So there are other reasons to pursue a template design for all of our runtime 
> hooks, and if our memcpy, memcmp, etc.. are also templated it't turtles all the 
> way down.

memcpy and memcmp are already handled specially by modern compilers, have been 
for decades; I seriously doubt there's more oil in that well.


More information about the Digitalmars-d mailing list