3 ms·
I agree with lots of points in this article, but one advantage libc has is that many compilers implement intrinsic versions of memcpy, sin, sqrt and so on that
by quelsolaar 4y ago
I agree with lots of points in this article, but one advantage libc has is that many compilers implement intrinsic versions of memcpy, sin, sqrt and so on that will be faster than anything you can conceivably implement yourself in C. Still, the smaller dependency footprint you have the better, and that includes libc.
- megous 4y agoThese will/can be used even if you don't use libc.
- schemescape 4y agoBut wouldn’t that require splitting your implementation per platform? I’d rather leave that to someone else.
- badsectoracula 4y agoIf you avoid libc you'd need to do that anyway, otherwise how you'd open files, allocate memory, etc?
- schemescape 4y agoSorry, I meant as opposed to using some other library.
- Someone 4y agoMore or less. I don’t think declaring your own memcpy ‘inline’ will get you all the benefits of using the ‘real’ one. If you want your compiler to know what memcpy does, so that, for example, it can compile it as an inlined “load register, store register” instruction pair _if_ it knows it’s copying 8 bytes, you have to #include<string.h> (with the angle brackets; #include "string.h" won’t do) So, if you want optimal performance, you can’t do without the compiler header. You’re still free to link with your own implementation of memcpy, of course, but don’t expect it to be called in all places where the source code contains calls to it.
- tsimionescu 4y agoI think in this case doing #import<string.h> but then not linking to a libc should work, as long as you're only using the function your compiler implements with intrinsics.