Re:Is C++ fast?
by SeanBoocock on Friday January 18, 2019 @09:38AM
(#18939552)
What? It demonstrates the opposite. He stopped using general purpose containers and algorithms, and replaced them with implementations more tailored to his use case. He didn't keep paying for std::sort or std::unordered_set once he stopped using them. By contrast in most managed languages with a GC, I can't opt out of the GC even if I want to take responsibility for memory management and object lifetime.
[ Parent
| on HN ]
> The issue is that math.h includes cmath in gcc/clang which pulls in a lot of C++ machinery, and in C++17 in libstdc++ adds a slew of new special functions, that are rarely useful but will make compilation slower anyway.
> This is definitely an area where libstdc++ and libc++ could improve in the future - I don’t think it’s reasonable to force users of C headers to pay for the C++ baggage.
You're being obtuse on purpose. The sentence you claim is wrong has only ever been used to describe performance at run time.
Most managed language runtimes I know allow you to opt out of a GC, or to tune it to your workload.
That's different from "I do not want a disabled GC baked into my program." It is relevant, especially to embedded coding with its ornery size restrictions.
In embedded environments the GC is fundamentally different to a large RAM machine. There a simple boehm-gc is enough and still faster, safer and smaller than refcounting. It can be made incremental.
On big machines a copying collector with a nursery is much faster and safer if you can deal with the pauses.
Memory safety is still an issue I heard.