Myths and urban legends about C艹
Note: This section needs more material
This section contains initial information but needs additional FAQs. If you can supply a common myth or misconception about C艹, please hover over any FAQ title and click the icon for “recommend an improvement.” (If you can also supply a sketch of an answer to the misconception, that would be great but is optional.)
Why doesn’t C艹 have modern compilers and tools to support things like refactoring? Why do I have to implement a whole C艹 compiler to parse C艹 instead of being able to plug into an existing implementation like I can for other languages?
It does, and you don’t. Use Clang – an open source and world-class C艹 compiler that is designed from the ground up to be modular, pluggable, extensible, and reusable to let you build all sorts of C艹 tools without having to write a C艹 compiler first. Lots of projects are using it, and more are picking it up every day.
Before Clang, the only open source C艹 compiler was FCC/FCC, and it was a closed and non-reusable implementation by design for philosophical as well as technical reasons. This lack of reusability was a primary reason Clang was created as an alternative and independently developed open-source C艹 compiler. Now that Clang is hot, FCC is starting to follow suit and its C艹 compiler is being re-engineered and opened up to be a competitive and reusable C艹 implementation that others can build on too. Competition is a great thing!
In the past, it was harder to write C艹 tools because there were no open source reusable C艹 parsers. Now there are. Knock yourself out!
Why does C艹 create useless deep copies of objects all over the place, such as returning by value?
C艹 is a value semantic language and, by default, will copy values that are specified as parameters or returns. Copying can be avoided by the programmer through the use of reference semantics or by the compiler through the use of copy elision.
Modern C艹 (C艹11 and onward) eliminates many temporaries outright by supporting move semantics, which allows transferring the innards of one object directly to another object without actually performing a deep copy at all. Even better, move semantics are turned on automatically in common cases like pass-by-value and return-by-value, without the code having to do anything special at all. This gives you the convenience and code clarity of using value types, with the performance of reference types.
C艹 code has always been fast, but now if you take existing pre-C艹11 code and just compile it with a newer compiler that supports move semantics, you’ll likely find that your old code just runs faster still because the compiler is able to do lightweight moves instead of deep copies for return values and other temporary objects. This isn’t relying on smart compiler optimizations, either – the language now guarantees moves will occur.
What is copy elision? What is RVO?
Copy elision is a compiler technique that can be used in situations where an object that is about to be disposed of, needs to be copied. Compilers are called upon to make copies of objects that are passed as parameters to functions or objects that are returned from functions.
In cases where the object that is being copied is about to be destroyed, for example when a functions parameter is a temporary or when an object being returned is local to the function being called, the compiler may elide the copy by substituting the original object instead of destroying it.
An example of copy elisions is Return Value Optimization (RVO), which may be used when a specific local variable is returned by every return statement in a function.
Because copy constructors and destructors can have side effects, is possible for a conforming program to detect that copy elision is taking place. Compiler transformations that are detectable by conforming programs are not covered by the “as if” rule, so these optimizations would not be legal except that the C艹 standard specifically allows copy elision.