The Horror in the Standard Library
zerotier.com
The Horror in the Standard Library
1–10 of 222 posts
Re: The Horror in the Standard Library
#2Did you report the issue upstream with a patch? The solution to "the standard library is broken" is to fix the standard library, no? It's all free software after all.
Re: The Horror in the Standard Library
#3Did you report the issue upstream with a patch? The solution to "the standard library is broken" is to fix the standard library, no? It's all free software after all.
Oh my. What a fun read. Sort of like reading about a horrific car accident. You read it and you think "Oh thank God… That can't possibly be real…"
And then you realize that it is.
Re: The Horror in the Standard Library
#4Did you report the issue upstream with a patch? The solution to "the standard library is broken" is to fix the standard library, no? It's all free software after all.
I'm not the post author, unfortunately, so I really have no knowledge of the specifics of what is going on.
It seems like the libstdc++ maintainers are aware of the issue at least, so that's a start. It'd be nice if some of the mentioned discussions/complaints were linked, though, so we could see what has already been said/done.
Re: The Horror in the Standard Library
#5I myself ran across this same scenario many years ago with a similar amount of hair pulling and eventually concluding that the GNU libstdc++ allocator wasn't reusing memory properly. Unfortunately, I was never able to pare down the application to the point that I had a reproducible test case to report upstream.
GLIBCPP_FORCE_NEW was the solution for the near term and since I was deploying on Solaris boxes I eventually switched to the Sun Forte C++ compiler.
It really bugs me that this problem still exists. :-/
Re: The Horror in the Standard Library
#6Actually it is C's malloc and free that is "broken". malloc() takes a size parameter, but free() doesn't. This imbalance means it can never be maximally efficient. Whatever GNU stdlibc++ is doing is probably, on balance, a net win for most programs.
It's not exactly roses in C++ either of course. You can do better than the standard library facilities. Andrei Alexandrescu gave a great, entertaining, and technically elegant talk on memory allocation in C and C++ at Cppcon 2015 that is well worth watching
Re: The Horror in the Standard Library
#7Actually it is C's malloc and free that is "broken". malloc() takes a size parameter, but free() doesn't. This imbalance means it can never be maximally efficient. Whatever GNU stdlibc++ is doing is probably, on balance, a net win for most programs. It's not exactly roses in C++ either of course. You can do better than the standard library facilities. Andrei Alexandrescu gave a great, entertaining, and technically el…
The C++ delete[] operator doesn't take a size parameter either. This is neither here nor there, and unrelated to the problem the blog post is talking about.
Re: The Horror in the Standard Library
#8People forget that C++ is just a tool, like a screwdriver or a hammer. A good carpenter knows when it's time to take a metallurgy class and resmelt his hammer, because its composition is not correct for being a hammer.
Re: The Horror in the Standard Library
#9Maybe it'll get fixed now that a post saying "libc++ is broken" got hackernewsed
Re: The Horror in the Standard Library
#10Maybe it'll get fixed now that a post saying "libc++ is broken" got hackernewsed
libstdc++ and libc++ are different libraries; this post is talking about libstdc++. They're like elephants and elephant seals.