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

91–95 of 95 posts

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

#91

Post by nikbackm »

Tempest1981 wrote: post #83
nikbackm wrote: post #80

Earlier quoted context omitted.

The bad news is that WIN32_EXTRA_LEAN has no effect, you have to define VC_EXTRALEAN if you want to exclude extra stuff from the MFC and VC headers. 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.

But it did in 2005? > VC_EXTRALEAN defines WIN32_LEAN_AND_MEAN and a number of NOservice definitions, such as NOCOMM and NOSOUND. > https://gamedev.net/forums/topic/367942-win32_lean_and_mean-...

WIN32_EXTRA_LEAN != WIN32_LEAN_AND_MEAN

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

#92

Post by anarazel »

gpderetta wrote: post #86
anarazel wrote: post #77

Earlier quoted context omitted.

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.

> I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe. They are not. Use sem_t for signaling . edit: also even if they where, the signal handler might wait forever for a mutex owned by the blocked thread.

It was more a rethorical doubting because I did not want to look the standard up on my phone....

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

#93

Post by otabdeveloper4 »

JonChesterfield wrote: post #90
otabdeveloper4 wrote: post #79

Earlier quoted context omitted.

There's nothing wrong with the std::regex design as it is the standard. 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.)

"can't be fixed without breaking ABI" sounds plausible for C++. There's generally not all that much stdc++ specific optimisation stuff in clang. There might be parts of regex that are worth implementing as compiler intrinsics, that seems to be the existing pattern for making bits much faster. The really heavy lifting you want for regex is to partially evaluate and split them. They're a separate language unto themselv…

C++ regexes are literally just copy-pasted ECMAScript regexes. They could have just used an existing regex library, but C++ compiler developers presumably don't want to support an extra dependency.

That's the only real reason why std::regex is slow.

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

#94

Post by tcbawo »

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

IMHO, the printf-style API is superior to the stream based API, because it can be adapted into a logging API that defers string formatting or delegates it to another thread. Overloading by type can be accomplished with printf-style API as well. Cluttering business code with string formatting can be a liability in code that needs to be performant/low latency, which is one of the primary reasons people use C++.

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

#95

Post by NooneAtAll3 »

offices wrote: post #88
dietrichepp wrote: post #65

Earlier quoted context omitted.

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 sens…

>The operator overloading syntax is bad In an obnoxious way. The first code someone will see of a new language is often 'hello world'. In C++, 'hello world' is an advertisement for the fact that operator overloading exists.

I still don't get the hate for it's the coolest part
Post reply on HN