One reason I like assert strings is that they can assist bug triage in a large organization, assuming that (as in my environment) the string is available outside of the core/kernel dump, probably in the kernel ring buffer/logs. Often, keying off of line number won't work across different branches, maintenance releases, patches and the like, so having a unique-ish string to search known issues/chat history/etc with is valuable. Sure, you can check out the code corresponding to the build that produced the core and find the code context from there, but that's another step that takes time, especially if you have to traverse a bunch of mappings like "oh, the core's from a machine on B_FOO_1337, which according to this one service corresponds to commit abcdef123, which is in repo baz, which I don't actually have checked out and/or fetched recently, oops." In an environment of this sort, it's also frequently not super quick or straightforward to get a debugger set up with the appropriate symbols to open the core and see the context - if a person running through a big list of defects can simply plug the string into a search and go oh, yup, it's known issue #12345 vs. having to hunt for the correct symbols, copy the (potentially several gb!) core around, get gdb to happily open it, etc, that eventually adds up to big time savings. Finally, compiler optimizations can make it so that, while a value is present in the core, the debugger can't automatically find it and gives you that <value optimized out> thing. While you usually can go digging around in the registers to extract it, that's a pain and yet more time. If you put the value(s) of the failed assertion in the string, that's one less spot for someone doing triage to get hung up on when trying to tell whether an issue is something new or just frequency of a known issue.
For stuff I'm just writing by and for myself, yeah, I take your approach. For software that will generate failures I may not be the first person in an organization to have to look at, I add friendly strings.
For stuff I'm just writing by and for myself, yeah, I take your approach. For software that will generate failures I may not be the first person in an organization to have to look at, I add friendly strings.