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?
For those curious about WIN32_LEAN_AND_MEAN - it reduces compile time by not auto-including a number of windows headers: https://devblogs.microsoft.com/oldnewthing/20091130-00/?p=15...
Its also my favorite btw.
One example was min and max - Win32 includes those which messes with trying to use std::min and std::max.
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.
The examples are: regex, iostreams, locale...
My main concern - this can also become such a dead weight.
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
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 better than iostreams.
2. Some existing implementations have efficiency issues, e.g. performing many allocations.
3. It is claimed (e.g. by Titus Winters) that the ABI of std::regex is problematic, and without breaking it, the implementations cannot be good enough
See these points and others at:
https://www.reddit.com/r/cpp/comments/e16s1m/what_is_wrong_w...
In my experience, stdlibc++ <regex> is VERY slow, especially on debug builds. We are using g_regex instead, which in turn uses pcre2.
> And iostreams
<iostream> achieves too little with too much code. We instead use:
std::cout << fmt::format(...);
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 (iostreams) nor too terse (printf).I also like that fmt has helpers for pointers (fmt::ptr), enums (fmt::underlying) and arrays (fmt::join). It's both easy on the eyes and feels consistent.
//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.The code must be fully async-safe, which means you cannot use <stacktrace>. You also cannot acquire mutexes, use any of the standard allocators, etc etc etc.
2. Have these changes been offered as patch for libunwind or boost::stacktrace?
As for not using standard allocators - not a problem, just have a fixed area set aside as a buffer for crash reporting. Yes, it might not fit an extremely long report, but it's not that much of an issue.
> Note about signal safety: this proposal does not attempt to provide a signal-safe solution for capturing and decoding stacktraces. Such functionality currently is not implementable on some of the popular platforms.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p08...
[edit] Replying here, because HN is doing its occasional obnoxious rate-limiting of replies:
Signal-safe and async-safe are effectively the same thing, and “async-safe” absolutely isn’t the same thing as “thread-safe”.
A code path that acquires a mutex can be thread-safe; that’s absolutely not async-safe.
If boost implemented a fully async-safe stack unwinder, complete with DWARF expression support, Apple compact unwind encoding support, and all the other features required across platforms, then good for them — but that’s not what <stacktrace> is guaranteed to provide, and such a thing is still not sufficient to implement anything but the most barebones portion of a real crash reporter.
To the extent that in-process crash reporting is even possible... seems the most common class of crashes would be entirely unrecoverable.
A version of Crashpad or something like it with a single turnkey server for database dumps, a one-line "defaults are good enough" integration, would be a real great thing to see.
> It's possible that some implementation have references to some stack addresses (like for example the address of a function parameter), in which case you would need to serialize the stack trace before storing them/ moving then another thread.
So which of these two mutually exclusive options is it? As I understand it, that was the question.
I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.