3 ms·
The use of goto is unambiguously correct and elegant in some contexts. Unwavering avoidance of goto can lead to unnecessarily ugly, convoluted code that is diff
by jandrewrogers 3y ago
The use of goto is unambiguously correct and elegant in some contexts. Unwavering avoidance of goto can lead to unnecessarily ugly, convoluted code that is difficult to maintain. It usually isn't common but it has valid uses.
While use of functions like `strcpy` are less advisable, there are contexts in which they are guaranteed to be correct unless other strong (e.g. language-level) invariants are broken, in which case you have much bigger problems. In these somewhat infrequent cases, there is a valid argument that notionally safer alternatives may be slightly less efficient for no benefit.
- sirwhinesalot 3y agostrcpy and friends don't really have any benefits beyond just being there. The "safer" versions are still unsafe in many cases, while being less performant and more annoying to use. Writing a strbuffer type and associated functions isn't particularly hard and the resulting interface is nicer to use, safer, and more efficient.
- bvrmn 3y agoI argue strview (non-owning) is almost always what is needed. Most of string operations are searching and slicing.
- sirwhinesalot 3y agoYou also need a strview. Not really relevant for avoiding strcpy and strcat though.
- xedrac 3y ago> The use of goto is unambiguously correct and elegant in some contexts. For C, absolutely. For C++, it's likely a footgun.
- jandrewrogers 3y agoIt has fewer use cases in C++ but it still has use cases where the alternatives are worse.
- xedrac 3y agoWhat is a C++ use case where RAII doesn't solve the problem better? I imagine one exists, but I've never encountered it in 20 years. Conversely, I've seen it used inappropriately for cleanup many times (which would be fine in C).