gcc

I was surprised when I revisited the GCC code after 20 years to find that GCC switched from using flex/bison to using a hand-written recursive descent parser (even for C++ which is reputed to be "impossible" to parse). Here's the C parser: https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-parser... and the C++ parser: https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/...

Really it's the other way around: peek is complex so the compiler didn't inline it. In essence, you do a virtual call which I think winds you up in https://github.com/gcc-mirror/gcc/blob/1cb6c2eb3b8361d850be8... which itself redirects to a whole bunch of stuff. The virtual call alone is a lot more expensive than a simple pointer dereference, and though it's possible proper inlining might have alleviated some of this problem, you're not particularly likely to see it come close to something that's efficient by design.

> only a very small fraction of code written in Java, C#, or any other high-level OOL does dynamic code generation, or even reflection The overall fraction might be small, however vast majority of software still contain substantial amount of code that does. Most serialization and DB access libraries do. For C#, this includes all framework-provided serializers (XML, data contract, etc.), the ubiquitous Json.NET, and my own one: https://github.com/Const-me/EsentSerialize > OOP doesn't allow people to reason about complex systems Respectfully disagree, ‘coz I have never saw complex systems that aren’t OOP. Even most compilers are OOP, take a look: https://github.com/llvm-mirror/llvm https://github.com/gcc-mirror/gcc/tree/master/gcc https://github.com/dotnet/roslyn > An object can contain references to any other object held by the process Th

Call me confused, too. When I was once following up the allocator in the STL because of some performance issues, it was (more or less) going directly to malloc. I've searched now the code for GLIBCXX_FORCE_NEW, and it seems it is used in the pool_allocator and the mt_allocator [1]. String uses std::allocator [2]. I agree, the blog entry seems to missing some information to reproduce the issue. It looks to me, that the author was jumping to a conclusion, which confirmed his initial "insight". Not surprising, if you are under pressure and working over the whole weekend and nights. Who hasn't been there. What bug me, that the standard answer seems quite often, that the whole thing is broken, and we have to switch to a complete different implementation, and/or re-write it from scratch. [1] https://github.com/gcc-mirror/gcc/search?p=1&q=GLIBCX

I suspect the issue is that variant<int,char> is not trivially copy constructible (at least when I tested on godbolt), so the ABI believes it is not allowed to pass the object by value. (this is a guess only, correct me if you know better!) Now why it is not trivially copy constructible is another question. But the latest standard draft does not require it [variant.ctor] though it does require the destructor to be trivial if all type destructors are trivial [variant.dtor]. The GCC implementation also seems to ensure only trivial destructor not copy constructor (the code is here [1] if anyone likes to see). EDIT: I did a small experiment that agrees with this - adding a copy constructor causes passing by pointer. https://godbolt.org/g/UG0YXJ EDIT2: I filed a bug report for gcc, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187 [1] https:/

The author seems to ignore that GCC's implementation of std::hash is the identity on integral types: https://github.com/gcc-mirror/gcc/blob/cf8c140a8b8131b3ab4f5... This is an incredibly poor design choice (at Facebook we'd say "clowntown") as it makes it unusable with any sophisticated hashtable data structure that assumes reasonable randomness. That's what causes the quadratic growth in the sequential example with dense_hash_map. The solution is to use better hash functions, not prime hash table sizes. Prime modulus will only make the problems harder to notice, but if you have a poor hash function, you're giving up every complexity guarantee. Note that even if you reduce modulo a prime > n, you'll still have the identity over the first n numbers. Personally I just use folly::Hash (https://github.com/facebook/folly/blob/da08e63ce3bac9196

[author of the post] Thanks for the links; a lot of interesting material in there. FWIW, DejaGnu gives some flexibility over how granular the test files can be. For example, here's part of the test case for the -Wmisleading-indentation warning I added in gcc 6: https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/... i.e. that's one 700 line test source file, expressing most of the test coverage for one feature. I realize now that the post should have had an example of what such a test case has; see the "dg-warning" directives in that file. So that's one "single file" test case. That said, I had to put some of the other test cases for that feature into different test files: some of them interact with the preprocessor in "interesting" ways, so it was simplest to split them out. However, when a test starts failing, it's handy if th