21–30 of 95 posts
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?
Its also my favorite btw.
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.
Can you expand on the problems with regex?
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
Earlier quoted context omitted.
I am not sure if i understand the question correctly. But once collected, stack traces are just regular object that can be passed around thread as other object. 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.
> once collected, stack traces are just regular object that can be passed around thread as other object. > 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…
Earlier quoted context omitted.
Can you expand on the problems with regex?
From what I’ve heard, std::regex is notoriously inefficient (lots of memory allocations, no allocator support). But I’ve never used it myself.
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.
Can you expand on the problems with regex?
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
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...
Earlier quoted context omitted.
I am not sure if i understand the question correctly. But once collected, stack traces are just regular object that can be passed around thread as other object. 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.
> once collected, stack traces are just regular object that can be passed around thread as other object. > 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…
You should be able to, for example, collect the stacktace on one thread, transport it to another and print it.
Reliable in-process crash reporting is exceptionally difficult. The code must be fully async-safe, which means you cannot use . You also cannot acquire mutexes, use any of the standard allocators, etc etc etc.
What's the benefit of in-process crash reporting compared to just using something like crashpad/breakpad? 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.
Reliable in-process crash reporting is exceptionally difficult. The code must be fully async-safe, which means you cannot use . You also cannot acquire mutexes, use any of the standard allocators, etc etc etc.
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.