Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Using C++23 to get proper crash logs in C++ programs

github.com

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#61

Post by fyrn_ »

plq wrote: post #45
verall wrote: post #20

Earlier quoted context omitted.

What's wrong with std::regex? Seems to work fine for me. And iostreams - they're not great. Bad programming UI, poor performance, etc. Issues abound. But should you never use them? What do you use instead? *printf methods have lots of issues too. And so does depending on Boost::format. And so does writing your own Logger/wrapping code (which is what everyone does AFAICT). locale is bad though

> What's wrong with std::regex? In my experience, stdlibc++ is VERY slow, especially on debug builds. We are using g_regex instead, which in turn uses pcre2. > And iostreams achieves too little with too much code. We instead use: std::cout for simple output, loguru[1] for everything else. I feel like the fmt grammar/mini-language is both nicely extensible and has hit the expressiveness sweet spot -- not too verbose (…

Consider ``` #include

... fmt::print(...); ``` Instead, to save that potential double buffer copy.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#62

Post by npsimons »

usefulcat wrote: post #55
npsimons wrote: post #35

Earlier quoted context omitted.

> What do you use instead [of std::iostream]? This is what I want to know. Having come from C to C++, iostreams were a big improvement over the "strings" and print functions of C. I even extended a base iostream class to have a "teebuf" logger, that could output to multiple streams and had the standard logging levels. It's been a while since I last had mastery of C++, but I'd like to hear what is as portable and bett…

> I'd like to hear what is as portable and better than iostreams Have a look at fmtlib. The interface is more like printf, but type safe and format strings are parsed at compile time. I believe it’s what std::format is based on, which could also be an option for you depending on how recent your compiler/language version is.

> The interface is more like printf

See, I don't believe that's an improvement. Having used printf in C, I was relieved to be able to "redirect" whatever to a stream, and not care about whether it should be "%d" or "%02f" or even if it was a struct/class.

On top of this, treating files as streams, strings as streams, or even extending streams to make a tee-stream[0] all seem clunkier to me with a printf like system.

Maybe fmt fixes these problems, I don't know. But I feel a lot of people don't like iostreams because they have some form of Stockholm syndrome with printf.

[0] - https://wordaligned.org/articles/cpp-streambufs#tee-streams

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#63

Post by trws »

verall wrote: post #20
zX41ZdbW wrote: post #17

There are parts of C++ standard library that no one should ever use. The examples are: regex, iostreams, locale... My main concern - this can also become such a dead weight.

What's wrong with std::regex? Seems to work fine for me. And iostreams - they're not great. Bad programming UI, poor performance, etc. Issues abound. But should you never use them? What do you use instead? *printf methods have lots of issues too. And so does depending on Boost::format. And so does writing your own Logger/wrapping code (which is what everyone does AFAICT). locale is bad though

It’s impossible to implement std::regex efficiently due to internal but exposed character handling requirements. To the sibling comments about iostream, thank vzeverovich and everyone that worked on fmt and turning it into std::format (edit: accidentally wrote std::fmt initially), which is vastly superior and not dependent on mutable global state.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#64

Post by smileybarry »

Night_Thastus wrote: post #7
rightbyte wrote: post #3

This is my favorite macro: "#define WIN32_LEAN_AND_MEAN" Why is it that even though Github or what ever has cutsie unicorns (or whatever it is) as error messages it feels fake and contrived while this define just feels like some random dude at MS naming it before going off to write Solitaire?

We've had to use this at my work a couple times. I forget the exact reasoning, but IIRC if you're using including parts of the Win32 API, you get some things that would stomp on C or C++ names, which is bad. Macros like that one prevent loading things you don't want. One example was min and max - Win32 includes those which messes with trying to use std::min and std::max.

I think we had to use that when importing FDI.h (the CAB-extracting part of winapi) to avoid it bringing more legacy cruft.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#65

Post by dietrichepp »

npsimons wrote: post #35
verall wrote: post #20

Earlier quoted context omitted.

What's wrong with std::regex? Seems to work fine for me. And iostreams - they're not great. Bad programming UI, poor performance, etc. Issues abound. But should you never use them? What do you use instead? *printf methods have lots of issues too. And so does depending on Boost::format. And so does writing your own Logger/wrapping code (which is what everyone does AFAICT). locale is bad though

> What do you use instead [of std::iostream]? This is what I want to know. Having come from C to C++, iostreams were a big improvement over the "strings" and print functions of C. I even extended a base iostream class to have a "teebuf" logger, that could output to multiple streams and had the standard logging levels. It's been a while since I last had mastery of C++, but I'd like to hear what is as portable and bett…

Strings in C++ are nice, especially now that we have std::string_view, but is one of the worst pieces of the C++ standard library.

- makes localization more difficult, compared to printf (localizing code is beyond awful)

- makes thread safety more difficult, compared to printf (it is safe to printf/fprintf from multiple threads, simultaneously, without any extra work)

- The operator overloading syntax is bad (my sense is that the operator overloading abuse in was a contributing factor for why Java doesn't allow operator overloading)

- Streams in are stateful, and it's easy to accidentally leave them in the wrong state (radix, padding, field width, etc)

- Performance of , out of the box, is mediocre (to get decent performance, you need to change some defaults)

The main advantage of was that it provided type safety, but IMO that advantage has long since been irrelevant. You get type safety with std::printf, with most compilers, assuming you enable -Wformat on GCC or similar options in other compilers.

The only remaining advantage of is that you can overload operatorUsing std::printf is better and more portable. Libfmt is also better and more portable, and it is now part of the standard library as std::format.

https://www.moria.us/articles/iostream-is-hopelessly-broken/

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#67

Post by dietrichepp »

npsimons wrote: post #62
usefulcat wrote: post #55

Earlier quoted context omitted.

> I'd like to hear what is as portable and better than iostreams Have a look at fmtlib. The interface is more like printf, but type safe and format strings are parsed at compile time. I believe it’s what std::format is based on, which could also be an option for you depending on how recent your compiler/language version is.

> The interface is more like printf See, I don't believe that's an improvement. Having used printf in C, I was relieved to be able to "redirect" whatever to a stream, and not care about whether it should be "%d" or "%02f" or even if it was a struct/class. On top of this, treating files as streams, strings as streams, or even extending streams to make a tee-stream[0] all seem clunkier to me with a printf like system.…

> Maybe fmt fixes these problems, I don't know.

Yeah, it looks like you did a lot of guesswork in that comment, and a lot of those guesses were inaccurate. Not really trying to be hostile here, but you did acknowledge that you were unfamiliar with std::format.

The part that fmtlib / std::format has, which is printf-like, is the idea of having a format string and arguments, rather than having a bunch of separate, piecemeal strings.

  // Old printf code, works ok for most people
  std::printf("failed to clone %s from %s", target, src);
  // 
  std::cout
You can see that you don't need to remember what kind of format specifier you need. This is C++, and that kind of problem is solved with overloading.

The std::print interface can work equally well with FILE or std::ofstream, or whatever you want. This is C++, and so you can just use a templated output iterator—or one of the overloads that creates one automatically.

There are a lot of problems with . I think it’s telling that lots of languages have copied printf, but nobody (or almost nobody) thought was good enough to copy. There are just too many serious design flaws with . It would be one thing if were just annoying to use, but it poses problems for localization, thread-safety, accidental misuse through its statefulness, and its operator overloading syntax is bad.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#68

Post by 95014_refugee »

npsimons wrote: post #62
usefulcat wrote: post #55

Earlier quoted context omitted.

> I'd like to hear what is as portable and better than iostreams Have a look at fmtlib. The interface is more like printf, but type safe and format strings are parsed at compile time. I believe it’s what std::format is based on, which could also be an option for you depending on how recent your compiler/language version is.

> The interface is more like printf See, I don't believe that's an improvement. Having used printf in C, I was relieved to be able to "redirect" whatever to a stream, and not care about whether it should be "%d" or "%02f" or even if it was a struct/class. On top of this, treating files as streams, strings as streams, or even extending streams to make a tee-stream[0] all seem clunkier to me with a printf like system.…

Considering the origins of "stockholm syndrome" this may not be exactly the message you intended.

However, printf and its ilk get it right; presentation is a property of the context in which the entity is to be presented, not of the entity itself. You can kvetch about the markup syntax, or the type safety issues the C implementation has, but the architecture is fundamentally correct.

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#69

Post by jcelerier »

Night_Thastus wrote: post #7
rightbyte wrote: post #3

This is my favorite macro: "#define WIN32_LEAN_AND_MEAN" Why is it that even though Github or what ever has cutsie unicorns (or whatever it is) as error messages it feels fake and contrived while this define just feels like some random dude at MS naming it before going off to write Solitaire?

We've had to use this at my work a couple times. I forget the exact reasoning, but IIRC if you're using including parts of the Win32 API, you get some things that would stomp on C or C++ names, which is bad. Macros like that one prevent loading things you don't want. One example was min and max - Win32 includes those which messes with trying to use std::min and std::max.

not only min, max, other "fun" ones to debug are "near", "far", "small"

Re: Show HN: Using C++23 <stacktrace> to get proper crash logs in C++ programs

#70

Post by PaulDavisThe1st »

If you don't care about exotica like async or signal safety, and just need to see the callstack from arbitray points, this can do the job without C++23:

https://github.com/Ardour/ardour/blob/master/libs/pbd/stackt...

(2 different implementations, one for POSIX-y systems with the execinfo.h header, and one for Windows)

The demange() function is elsewhere.

Post reply on HN