Replacing C's memcpy with a D implementation
Walter Bright
newshound2 at digitalmars.com
Mon Jun 11 08:00:10 UTC 2018
On 6/10/2018 8:43 PM, Mike Franklin wrote:
> That only addresses the @safe attribute, and that code is much too complex for
> anyone to audit it and certify it as safe.
>
> Exceptions are also not all handled, so there is no way it can pass as nothrow.
>
> The runtime call needs to be replaced with a template that can take advantage of
> D's compile-time type information instead of `TypeInfo`, but doing so will force
> the implementation through semantic processing, which, in it's current state,
> will fail to compile. It needs to be refactored, and creating @safe, nothrow,
> pure building blocks will help with that, hence the topic of this thread.
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.
(I notice it is doing __doPostblit(). This looks wrong, D allows data to be
moved. As far as I can tell with a perfunctory examination, that's the only "can
throw" bit.)
Doing without TypeInfo is a worthy goal most of the time, but I don't think it
is of much value here because it calls the garbage collector anyway which
requires TypeInfo.
Some obvious refactoring tasks for it would be to:
1. eliminate the gotos
2. use single assignment for variables
3. minimize the scopes of variables
4. use const
5. document the inputs and outputs
6. add test cases for the red lines
More information about the Digitalmars-d
mailing list