C++ Just Got Standardized Garbage Collection (And Much More)!

[patrickjp93]

The next time anyone says C++ doesn't have garbage collection and is a leaky nightmare, do the entire programming community a favor and 

1) Slap the ignoramus

2) Show them this

3) Tell them it's been leak-free for 4 years

 

No other programming language currently (not Rust, Go, Java or Python, I just checked) is actually leak-free by construction. Finally there exists a comprehensive lecture showing how to make it happen with nearly 0 overhead, possibly 0 if you're using the right compiler.

 

[AresKrieger]

I always laugh when people tell me Python or java is a good language, what they generally mean is that they are an easy language but in coding easy generally translates to inefficient.

[patrickjp93]

3 minutes ago, AresKrieger said:

I always laugh when people tell me Python or java is a good language, what they generally mean is that they are an easy language but in coding easy generally translates to inefficient.

Except in C++ 11 and 14

 

Generally, readable = efficient. Sometimes you need to add const, &, and &&; and maybe you need to use std::move() in a return statement to do copy and move elission (and by then you're working on optimizing away those last 3-4 cycles), but C++ 11, 14, and 17 all show readable = fast.

[fizzlesticks]

2 hours ago, patrickjp93 said:

and maybe you need to use std::move() in a return statement to do copy and move elission 

You shouldn't use std::move in a return statement (unless you're actually returning a rvalue& or moving from a member variable in which case you have to of course.)  Compilers will already perform a move instead of a copy if possible even without doing a std::move however you're taking away the ability of the compiler to perform (N)RVO. 

[patrickjp93]

4 hours ago, fizzlesticks said:

You shouldn't use std::move in a return statement (unless you're actually returning a rvalue& or moving from a member variable in which case you have to of course.)  Compilers will already perform a move instead of a copy if possible even without doing a std::move however you're taking away the ability of the compiler to perform (N)RVO. 

I'm afraid someone needs to see a couple lectures by Scott Meyers and Herb Sutter. There are 3 cases (in C++ 14) where RVO and NRVO cannot directly handle it, and only one of them is returning an RVal&

[Unimportant]

If only ppl would actually write code like this. I still come across code with naked new, and then handing out pointers everywhere, weekly causing massive bugs. Even std::auto_ptr was already available in C++03, even tough it had it flaws, 13 years later some programmers are still stuck in the mindset before that...

[patrickjp93]

3 hours ago, Unimportant said:

If only ppl would actually write code like this. I still come across code with naked new, and then handing out pointers everywhere, weekly causing massive bugs. Even std::auto_ptr was already available in C++03, even tough it had it flaws, 13 years later some programmers are still stuck in the mindset before that...

To be fair, it can be necessary for optimizing the last 1-2%, and much of Clang uses packed pointers (doubly dangerous because they pack pointers and ints into the low 4 bits of each other (x86's memory model tends to align on 16-bit boundaries)). Still, it's not something 95% of C++ programmers should even be considering at this point.