I think I should write a little follow up for “ .” It was clearly misunderstood by quite a lot of people, and it’s fine. Inability to clearly express myself is only my fault. But it also revealed some cardinal misconceptions not about my writings, but about C++ in general. For the sake of argument, I have to respond to them. Blood, sweat, and C++ Misconception 1. C++ is a bad language C++ is huge, complex, needlessly eclectic and it suffers from its heritage. That’s all true. But there is another language we all know and love that share the same traits. It’s English. At first glance it seems to be just pieces of French, Latin, Dutch, Sweden and God knows what else sewed together. But it has its own core, own rules which all the borrowed parts comply. It incorporates other languages just like C++ incorporates bits of Simula, Ada and ML. It is also huge in comparison to its peers. Different methods show different word count, but with its 250 000–1 000 000 impressive number English probably has than any other language on earth. Just like that, current C++ standard consists of 1358 pages, and it is by far the largest computer language standard ever existed. Most of the languages fit in between 600–800 pages. But it only took to standardize Algol 60, so this is also possible. more words ISO/IEC 14882:2014 18 pages And have you ever wondered, how come non-personified objects come in neuter gender in English, unless she is a ship? That’s one example of . Gender system in English evolved from West-German where genders applied to inanimate objects as well. It became genderless only by the 14th century. Except for the exceptions of course. confusing heritage Speaking about heritage. Up to C++17, the standard had trigraph sequences in it. Trigraphs is the way to type 7-bit ASCII symbols using 6-bit encoding. If you have a teletype that has no button on it, no worries! Just type and the wonderful world of C-preprocessing is open for you once again. # ??= Yes, C++ is big and complex. You can’t deny it. But it doesn’t necessary make it a bad language. Complexity may be a burden, but it may also be a merit if you want versatility and the expressiveness. Misconception 2. C++ was designed for performance C++ was designed to be with cheap abstractions. You can write rather efficient low-level code, and you can leverage it with little to none overhead. You can achieve comparably good performance with this, but this is not what “designed for performance” stands for. systems language Languages that are deliberately designed for performance are , , or even good old . Fortran compilers have a 60 years old history of optimizations, and since they are much simpler than C++ ones, they are notorious for creating more efficient code in Fortran typical applications. It’s also easier to port Fortran efficiently to any new perspective platform. There is with full support for the Fortran 2003 standard. But CUDA C/C++ only supports some bits of C++; it is not at all ISO/IEC compliant. Fortress Chapel Fortran CUDA Fortran But honestly, if you want performance, you should think about programming . Then VHDL and Verilog will be your languages of choice. hardware directly So yes, you can write rather relatively efficient code in C++; and no, it is not designed for performance. Misconception 3. C++ is easy if you follow the rules There are lots of rules for C++ programming. There are coding standards: MISRA C++ JSC AV C++ HICPP There are books that work like standards: C++ Coding Standards: 101 Rules, Guidelines, and Best Practices Industrial Strength C++ Coding Standard And there is, of course, . Core Guidelines There are more, but these are the ones I read and can safely recommend for acknowledgment. Technically you can follow HICPP 4.0 to the bone and shoot yourself in the foot a little less. That’s true. You can also quit drinking, eat healthy and run a half-marathon every other morning. Everybody can! Everybody can increase their health significantly with a little discipline. But somehow the world is still full of heart diseases. Apparently, people don’t like to be told what to do. Even if it is for their own good. I hope you can see what my point is. Standards are useless unless everybody follows them. And no, this is not the case. You may impose a standard for your organization, you can shield it with static analysis, and you can punish trespassers mercilessly, but the moment you have to go out in the wild — you’re screwed. Unless you can make your development fully hermetic, — no third party code, no merger inheritance, no legacy — you should not rely on the sanity of a coding standard. In conclusion There is one thing that programming teaches better than anything else. And this is accepting reality. You can convince your college professor that you know all about economic transition in Uzbekistan, but you can’t convince a compiler that your syntax is correct. The reality is harsh for C++ programmers, but since we don’t compete with gods, but only with each other, this harshness doesn’t mean all that much. It’s all even, all fair. Good programmers write good code in any language. is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
