71–80 of 95 posts
The code: //a decent amount of this was copied/modified from backward.cpp (https://github.com/bombela/backward-cpp) The license on the other side of that link: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
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.…
FWIW, I have waaaay more experience with iostreams than printf. I once wrote a replacement for most parts of std::ostream purely because I had a logging system that was loosely based on log4cxx (which is based on iostreams) and I needed much faster formatting.
Right now I'm in the process of switching to a different logging system that uses fmtlib. I can say that I really, really do not miss the extreme verbosity of iostreams at all. The statefulness I could take or leave, although on balance I'd say it's usually more of a negative. Thankfully I don't have to give up type safety or extensibility.
As for treating files/strings/whatever as streams--my impression of fmtlib is that it's concerned primarily with formatting, which frankly I'm fine with. It can write to an in-memory buffer or to a FILE* or to a std::ostream, which covers pretty much all of my needs. Given the performance of iostreams (lots of virtual method calls) I never really saw the point of using it as a more generalized 'streaming' interface, even knowing that it's possible.
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.
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?
This does not even remotely look to be signal safe to me?
This does not even remotely look to be signal safe to me?
The signal handler just saves the trace and then wakes up another thread which does the reporting. The signaled thread uses only and mutex/cv, all signal-safe as far as I can tell.
I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.
Earlier quoted context omitted.
The signal handler just saves the trace and then wakes up another thread which does the reporting. The signaled thread uses only and mutex/cv, all signal-safe as far as I can tell.
The crashing thread might hold a lock in the memory allocator - which could either self deadlock when saving the stack trace (which certainly seems to do memory allocation and thus isn't a-signal safe), or could deadlock with the crash reporting thread which definitely allocates memory all over. I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.
You're right about mutex & cv in the general case though
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
Well, `std::regex` is literally orders of magnitude slower than other common regex libraries found in JS, Python, Perl, C, etc. It allocates a ton, is poorly implemented, and can never be fixed due to ABI constraints. The entire subsystem is a mess and should have never been standardized as is.
std::regex only sucks because the developers of gcc and clang never bothered to optimize it. (Too much work and they have other stuff to worry about.)
Earlier quoted context omitted.
Do you mean VC_EXTRALEAN? Or is WIN32_EXTRA_LEAN also a thing?
First time I hear of VC_EXTRALEAN, always used WIN32_EXTRA_LEAN.
The good news is also that it has no effect. :)
You can verify this for yourself by grepping the Visual Studio headers for VC_EXTRALEAN and WIN32_EXTRA_LEAN.