Looks like it. Section 4.1 eliminates lower level languages on code size, and 4.2 eliminates higher level languages on performance. The challenge in C form would be:
Create a better string copy way:
while (*d++ = *s++);Create a better string copy way:
while (*d++ = *s++); return memcpy (dest, src, strlen (src) + 1);
I think the logic is that strlen is virtually free for short strings, and that memcpy can be a lot faster for long ones (reading https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memc..., it even copies “whole pages from SRCP to DSTP by virtual address manipulation, as much as possible”. strlen doesn’t do things the K&R way either anymore. It checks one byte at a time until things are word aligned, then checks words for zero bytes. That can read from past the string, so it requires the platform it runs on to make that OK. See https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strl...)Also, heck, it's a challenge, we all want in, please make it so :)
If I can outperform Julia by 50% in C++, but I have to write 10x code. I won't bother with C++.
If you manage to have that in the end, that's a very valuable promotional information.
For one of my master courses, I had to write 200 lines in python. C++ solution would have been in the thousands. My colleague solved it in 10 R lines. R is on my list now :)
d := s
Strings are immutable, so it internally just copies a descriptor.