C++ Discussion Thread

For science and engineering, Julia looks VERY promising, but it's taking forever to reach 1.0.

Pretty much tbh, I work in what is technically embedded, and most devices have 256 or 512 MiB of RAM and a relatively good ARM v7 processor, which runs a full version of Linux 2.6.x.

Conveniently ignoring throughput. GCs can only balance between those two.

Go

The alternative is ugly as fuck and unsafe unless you always put the referenced value on the heap. References solve that problem because they can't be null (except without horrible, deliberate abuse that a typical C++ noob would never think of doing), so you know it's valid.

If you knew how generational GC worked you'd know you can produce all sorts of fake speed numbers for it by ensuring all your data isn't in the generation that needs swept. Real programs that grind a lot of data rather than just idle with a large heap by necessity require large sweeps and that takes a large amount of time. There's no way around that, it's like trying to go faster than the speed of light.

You don't have to use libstdc++, newfriend. C++ is no more bloated than C.

Rust wins again. How will sepplesfags ever recover? du -h .rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-ddeed4efba8e9952.so9.3M .rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-ddeed4efba8e9952.so

C and C++ are not even related. Stroustrup just happens to allow certain C keywords to work, but the way C++ operates is in no way the same as C.

Find me a compiler as simple as tcc or pcc for C++. You won't find it because the language is bullshit with an ambiguous grammar. And if you want a "clear" argument, look at the number of keywords:
en.cppreference.com/w/c/keyword
en.cppreference.com/w/cpp/keyword
Another one:
> archive-extract.sh -d . /usr/portage/distfiles/gcc-6.4.0.tar.xz> du -hd0 gcc-6.4.0/gcc/{c,cp}1.7M gcc-6.4.0/gcc/c9.7M gcc-6.4.0/gcc/cp