On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote:
On 12/2/2017 4:38 AM, Iain Buclaw wrote:
But then you need to bloat your program with debug info in
order to
understand what, why, and how things went wrong.
Most of the time (for me) that isn't necessary, because the
debugge
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
Just from D's type signature, we can know a lot about memcpy():
1. There are no side effects.
2. The return value is derived from s1.
3. Nothing s2 transitively points to is altered via s2.
4. Copies of s1 or s2 are not saved.
Th
On Tuesday, 31 January 2017 at 19:20:40 UTC, Walter Bright wrote:
On 1/31/2017 5:50 AM, Richard Delorme wrote:
Well, I would not have taken memcpy as an example in favor of
D. Good C
compilers (like gcc) know what memcpy does and are able to
optimize it according
to its arguments. DMD may know
On Tuesday, 31 January 2017 at 23:30:04 UTC, Walter Bright wrote:
On 1/31/2017 3:00 PM, Richard Delorme wrote:
The thing about memcpy is compilers build in a LOT of
information about it that simply is not there in the
declaration. I suggest retrying your example for gcc/clang, but
use your own
On Wednesday, 1 February 2017 at 10:20:45 UTC, Patrick Schluter
wrote:
On Wednesday, 1 February 2017 at 10:05:49 UTC, Richard Delorme
wrote:
//-8<---
#include
#include
void* mymemcpy(void* restrict dest, const void* restrict src,
size_
