Hacker News Reader

Comment by SeanBoocock | Hacker News Reader

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.

View 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.

Reply on news.ycombinator.com