Designing a better strcpy

Re:Designing a better strcpy by rectang on Saturday June 19, 2021 @09:11PM (#27566101)

Saving 8 bytes, and saving a few cycles by scanning rather than counting... is an argument for using NUL-terminated strings as an optimization in specialized circumstances.

In the common case, the extra 8 bytes and the cycles saved (if any) don't matter — and are not worth the sacrifice of making it harder to program correctly.

[ Parent | on HN ]

Re:Designing a better strcpy by kevin_thibedeau on Sunday June 20, 2021 @01:09AM (#27567274)

> the extra 8 bytes and the cycles saved (if any) don't matter

You wouldn't last in embedded development with that sort of attitude. When you're nearly out of RAM you can't afford to waste overhead of fat strings.

[ Parent | on HN ]

Re:Designing a better strcpy by pjmlp on Sunday June 20, 2021 @03:39AM (#27567982)

I was using Turbo Basic, Turbo Pascal, Turbo C++ (with C++ collections), and Clipper on MS-DOS, with 640 KB of memory.

It was just fine, then there are those that nowadays even toy with C++17 on C64.

“Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

https://www.youtube.com/watch?v=zBkNBP00wJE

Really, unless we are talking about PIC and AVRs with like 4KB, we are optimizing for the wrong target.

[ Parent | on HN ]

Re:Designing a better strcpy by mh7 on Sunday June 20, 2021 @05:46AM (#27568550)

You can't afford to waste cycles on O(n) strlen either.

[ Parent | on HN ]

Re:Designing a better strcpy by pkaye on Sunday June 20, 2021 @03:05AM (#27567829)

Not every embedded system is memory constrained these days.

[ Parent | on HN ]

Re:Designing a better strcpy by rectang on Sunday June 20, 2021 @04:02AM (#27568079)

Indeed. And besides, didn't I account for precisely that scenario? Memory-constrained embedded development is a specialized situation that could call for using NUL-terminated strings.

[ Parent | on HN ]