7 ms·
Why I haven't given up on C++
- taneq 11y agoC++ is a language that's easy to code badly in, but that doesn't mean it's hard to code well (portably, maintainably, effectively) in. IMO it's a language that well suits pragmatic programmers who are willing to cherry-pick the most convenient and productive features for their projects and leave the rest alone. It's a terrible language for those of us who compulsively try to be clever and use every little nook and cranny of the language they're using. They get lost out in the dark scary corridors and spiderwebs, and then say "C++ sucks" instead of "what the hell, don't go out there unless you really NEED variadic templates today." Edit: And it's easy to get yourself in really weird pickles if you don't know what not to do, (static initialization order, I'm looking at you!) I've found my WTF-per-minute rate has dropped dramatically over the years as my coding style has improved.
- jwdunne 11y agoThis comment reminded me of a lesson in The Elements of Programming Style: Use good language features, eschew the bad ones (paraphrased). After reading this, some opinions across a few languages made more sense. For example, Crockford advocates subsetting, hence JS The Good Parts. There are also more times than I can count where choosing a subset of C++ from its stupendously large array of features. When you think about it, it's possible to write esoteric, hard to read code in many languages, even ones designed to improve programmer productivity. If a language offers you capabilities that can blow readability out of the window, you'll see it happen. The more capabilities for such and the larger the number of programmers using the language, I'm sure you'll see a larger number of cases where code is indecipherable. From experience, to finish, I've seen a lot of very straight-forward C++ code that shines with readability compared with some Python code I've come across.
- masklinn 11y ago> C++ is a language that's easy to code badly in, but that doesn't mean it's hard to code well (portably, maintainably, effectively) in. It kinda does. It's like Perl: between the historical precedent, the stuff that's available on the interwebs, the affordances of the language and the easiest/shortest way to solve a given problem, it's way harder to code portably, maintainably and effectively than not, and you need to expend serious efforts trying to keep up. Which most people aren't going to do. It's the old quip that "within C++, there is a much smaller and cleaner language struggling to get out". If you have the knowledge and the discipline you can use that smaller and cleaner language, but I don't think you can argue it's easier to use that smaller and cleaner language than to use C++ in general.
- DanielBMarkham 11y agoYes. C++ used to be my favorite language. I still like it a lot, but I no longer love it. The trick, in my opinion, to C++ was what you were not doing. Coding in such a rich language means making a lot of decisions up front about limiting complexity. That turns out to be a good thing. The reason it's not my favorite anymore? Because the language designers seem hell-bent on continuing to make it more and more feature-ful. Over time, it's creating a huge, diverse codebase, all with the title "C++ code" on it, but all vastly different in nature and scope. That ain't a good thing. STL is a good example. On its own, STL is a good thing. Greatly needed in the language. But now that its implemented, its basically its own system. You could solve world hunger with STL (I am being factitious to make a point) Remember the criticism Microsoft always had, that they couldn't build anything that did just a few things? Everything had to be able to do everything? C++ has that, only worse. I like the language. I really do. I don't know if I've given up on it -- unless I wanted to tweak the hell out of something or was writing lower-level code the answer is probably "yes" -- but it seems to be heading in a direction that is not good for the maintenance programming community. It's great for really smart people who love complex things, but no so much for the poor schmuck coming in 10 or 15 years later. It's become a monster.
- CyberDildonics 11y agoI'm not sure why you say that about the STL - you didn't give any examples. Having worked with it a large amount at this point it seems to me to be mostly very well designed and focused on fundamentals of the parts of a program that are both common and non trivial. Some things are messy (like hashing) some things are missing (like serialization) and some things would be incredible to have (like thread local heap allocation, lock free concurrent data structures, some sort of dynamic stack allocation, the functionality of something like capnproto, shared memory and memory mapping...), but in general it seems like it covers the fundamentals well.
- amelius 11y ago> It's a terrible language for those of us who compulsively try to be clever and use every little nook and cranny of the language they're using. Do you mean the Boost developers? :)
- zelos 11y agoRight now, C++ is less portable than Java..., that really have this ‘write once, run everywhere’ thing. As someone who's currently rewriting a massive Java project in C++ so we can port it to other platforms, this made me laugh. It reminds me of that physicist joke about spherical cows. "Assume a working JVM..."
- reacweb 11y agoI have the migration studies for a big software base containing C++ code, Ada code and Java code (around 30% each). The migrations were from HPUX to RedHat4, then to RedHat5, then to RedHat6. Each time, more than 90% of the migration workload was on the C++ code.
- z92 11y agoMaybe that's because C++ was used mostly for system level calls, and low level jobs.
- qb45 11y agoOne advantage of Java is huge standard library with basic support for important OS-specific things like filesystem, threading, GUI, time, etc. You don't get all the bells and whistles of your OS, but you can write portable code which works and does some simple things expected to be possible "everywhere". C++ only recently is starting to go there.
- zelos 11y agoInteresting. Is that still the case if you go in with the intention of writing portable code, though? Or was it just a case of taking a large single-platform piece of code and porting it? The main issue is that Java's portability has hard limits. C++'s may require work, but it is at least (in theory) almost always possible.
- reacweb 11y agoI have the migration studies for a big software base containing C++ code, Ada code and Java code (around 30% each). The migrations were from HPUX to RedHat4, then to RedHat5, then to RedHat6. Each time, more than 90% of the migration workload was on the C++ code.
- hathym 11y agoC++ is the new Cobol
- jacobush 11y agoNah, PHP is the new COBOL
- osullivj 11y agoNah, Java is the new COBOL. Billions of LOC that will never be replaced, running on arcane infrastructure. In this case the arcane infrastructure isn't mainframe hardware or OSes, it's J2EE bean containers, XML configged ORMs, and Ant build systems.
- jacobush 11y agoYou are right, of course. Maybe PHP is the new VB?
- deleted 11y ago[deleted]
- eklavya 11y agoMan I am so glad I escaped all that. Sheer luck !
- kozukumi 11y agoOne of the best things about Java is that getting old code running on newer hardware is so much easier compared to the COBOL cluster-fuck we have these days. Hopefully we won't see as much 30+ year old hardware running our mission critical Java applications as we see our COBOL applications.
- IshKebab 11y agoI do like C++, but I do find myself more and more finding bugs that would have picked up in another language. "Huh. I'm pretty sure Rust would have picked me up on that bug." Here's an example. I accidentally wrote this: while (getLine(pc, buffer, sizeof(buffer) > 0)) Which compiles fine. Stricter languages could detect this bug.
- mpweiher 11y agoMost likely two bugs. The bracket one, and the fact that sizeof(buffer) will give you the pointer size, not the buffer size if buffer is a pointer rather than an array.
- eddyb 11y agoThe first one would be caught in Rust as it has no integer -> boolean automatic conversions (similar to Java). The second one could only arise with unsafe pointers in Rust, as safe code uses slices, combining the base pointer and the element count in a single value.
- masklinn 11y ago> The second one could only arise with unsafe pointers in Rust, as safe code uses slices, combining the base pointer and the element count in a single value. OTOH the point here is to pass a preallocated but "uninitialised" buffer to the callee, which Rust wouldn't allow with slices, unless you created a slice from a raw allocation (I don't know if that's defined behaviour, though I guess you could do that safely by passing in a Write rather than the slice itself, but then you're Write-ing to a slice which has… interesting behaviour)
- dancsi 11y agoYour second point depends, in fact, on whether buffer was allocated statically.
- mpweiher 11y ago
- abhi152 11y agoI am interested on your views about Portability. While Boost and STL are portable in terms of static compilation Boost gives you very painful bugs at runtime :(. I also would like to know why you say that Java is portable on paper ?
- RotsiserMho 11y agoI've used parts of boost extensively on embedded platforms and cross-platform projects without ever encountering painful runtime bugs. What issues did you have?
- deleted 11y ago[deleted]
- raverbashing 11y ago"I agree it’s complicated, but that’s not necessarily a bad thing. You really don’t need to understand the whole thing to start using it. And when you’ve been using it for a while and start to understand the intricate details, it becomes very, very powerful." To be honest, this is a corporate sales pitch. It's trying to justify the injustifiable It doesn't need to be full of "features" that most people don't use. Granted, some of them are needed regardless C++11 and 14 have simplified some parts, which is good. Still, a lot of other languages do more with less complexity Some things that are painful - String formatting in STL is a joke - "Smart pointers" are still an add-on and clunky to use - No reflection. Manual setup of getters/setters/copy constructors
- walkingolof 11y agoTo be event more honest, everything is complicated when you do not master it. C++ is a language with true benefits in terms of execution speed and flexibility, it may not just be the language for everything and everybody.
- raverbashing 11y agoYou can get most of the speed with C and it is not as complicated Flexibility should not imply in being "hard to use"
- walkingolof 11y agoThats an old sentiment that apparently never goes away, just like C++ is "hard to use", its only hard to use because you dont know what you are doing, when you are using C++ professionally you get to learn the language and appropriate patterns and after a while your perfectly comfortable, just like you would be with Java, Go, Haskell and Lisp.
- autoreleasepool 11y agoWhat's wrong with std::string though?
- hellofunk 11y agoI've been having so much fun writing functional programs in C++14 after spending 2 years writing exclusively Clojure code. It was amazing to me that I could return to C++ and use most of the same idioms and styles that I'd gotten spoiled by in Clojure. The ability to pass and store anonymous functions, with captures when desired, is so useful, and doing this is easy in C++11/14. It has really changed my appreciation of the language. The algorithm library for doing things like map, reduce-style expressions is also wonderful. C++ is a rapidly moving target and they are not resting on the past.
- JanneVee 11y agoI've given up on finding another C++ programming job for the foreseeable future. The problems I have is not with the language itself it is the other C++ programmers I have issues with. Not to say that I don't think the language doesn't have issues. With proper care you can work around the issues and avoid overcomplicating the code. But occasionally you have other C++ programmers who just makes things too complicated and don't realize that they have done so.
- nmeofthestate 11y agoIn my personal experience, C++ suffers from a surfeit of programmers who don't have a perspective on just how unproductive C++ is, and fall into the trap of considering themselves as an elite based on the complexity of their language of choice. I'd recommend C++ programmers learn how other languages have moved far beyond C++ in usability, because that will help them in writing C++.
- CyberDildonics 11y agoCan you give an example of a language that goes beyond C++11/14 in both speed and usability, including tools?
- deleted 11y ago[deleted]
- JanneVee 11y agoWell in part I agree. That is why I've expanded my language toolbelt over the years. I just have yet to meet any smug C++ weenies, I only occasionally see them in comments on the internet.
- CyberDildonics 11y agoIt's interesting to not consider a language based on what you want to write, but what you wish the other person had written it in.
- hellofunk 11y agoMy own take on the original article that this author is responding to: >C++ IDEs suck. Big time. I find Xcode quite a pleasure to use. The autocompletion, debugging, the quick moving around the interface, splitting files side-by-side.. I haven't used other IDEs besides emacs, but nothing about Xcode is getting in my way. >It’s an unmanageable language. Compared to a dynamic language or a weakly-typed language (I'm looking at you C, and a few others), I'd say the strong typing of C++ alone helps in code manageability. And, unlike Swift or Clojure or other languages, I find putting an API in a header file and an implementation in a translation unit really helps me reduce time later on. It's an automatic API summary without needing to review your implementation. When I move on from one part of a program to another, I don't want to study my source code just to remember what the access is. Just show me the header. I miss header files in other languages. >It’s a counterproductive language. and >STL sucks. The tools in the STL are serious time-savers. Sure you can choose not use them or implement your own, but in either scenario, you will likely spend a lot more time writing code than working on your actual problem or idea. In that regard, I'd say C++ and its standard library are very productive. And all the new multithreading and async primitives in C++11/14 take this productivity to a new level. >namespace stupidity Without namespaces, you have to work harder to name your stuff and to debug name clashes. Every good language that I've worked with uses namespaces. I consider them a requirement for any language that will handle a large project. >The language sucks. It sucks because it’s so complicated. C++ is probably the most complicated language I will ever use. I'm not sure why that makes it suck, though. Unlike many other languages, where it is wise and expected that you can keep the whole language in your head and understand entirely how it works, C++ is a different thing altogether. Nobody on this planet probably understands 100% of C++ -- including its creator, who has said that he gets maybe 80% there. In C++ you can use a small and ordinary part of the language and choose to go to the complicated stuff only if you really want to, but rarely do you need to. Yes, complex metaprogramming is mind-bending in what you can do -- and also, you cannot do a lot of it any other language. But you don't have to do any of that, and most people probably shouldn't, until they want to have some fun and really see how deep C++ can go. And a lot of the most complicated stuff that was important to understand in the past is no longer required reading for new programmers to the language, since the latest standards handle many things for you automatically. I.e. just writing "new" or "delete" and deciding when and how to do so are no longer required and actually discouraged thanks to smart pointers.
- AnthonBerg 11y agoC++ is fool's gold. Its complexity is inefficient and this gives the sensation of power and accomplishment, when all we have done is waste energy on translating abstract thought into a fragile foam of symbols. Then finally there is a sad degree of orthogonality between the meaning and structure of said foam and our original thought. But it sure feels like we did something. We slaid that dragon good eh!
- rsp1984 11y agoMost C++ IDEs have problems, probably because C++ is a difficult language to fully parse. I’ve only ever used Visual Studio and KDevelop. That's me, about seven years ago. Then I tried Qt Creator. Now I'm an evangelist. It just works. It parses all your code in seconds and you get autocomplete and syntax coloring that's very close to perfect. The interface is as clean as it gets. And yes, you can use it without ever touching Qt (the framework) at all. The only thing is, try to avoid versions > 3.2.2 since they are a bit buggy. Edit: fixed typo.
- kozukumi 11y agoI want to use QT Creator but I find some things frustrating such as finding out how to change compiler options in a reliable way. Sometimes it is QMAKE_CXXFLAGS or some other option in the .pro file. In every other IDE it is a tick box in project settings. Yes yes I know a tick box sucks but it sure makes things easier to remember how to do rather than yet another cryptic bit of text in a config file, I have enough of that anyway.
- RotsiserMho 11y agoThis can be avoided by using CMake as QtCreator supports it as a project type. CMake isn't exactly a bastion of simplicity however.
- kozukumi 11y agoTo be honest I am just very lazy and would appreciate a simple GUI to make the build and project files. I guess Visual Studio has made me lazier ;)
- fenesiistvan 11y agoBrian Will says that that whole OOP concept is bad (not to say about C++ which is OOP in the ugly way): https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM
- inDigiNeous 11y agoIt's easy to bash anything, to find only bad things in something. And to let go, give up and get frustrated and write blog posts like this. Sure, most of this stuff is correct, like the header madness, but still C++11 especially is pretty nice these days. There just isn't any other way to do cross-platform, performant code, while having the compatibility with all the C/C++ libraries out there. I feel C++11 could use some kind of new approach, like "Lean C++11" which drops all the legacy crap that is holding back adaption for new developers, who now have to go through maybe 15-20 years of legacy coding styles in order to find the modern way of doing things. But this would break backwards compatibility, so maybe better focus on Rust or something else that is set to do things correctly. I still like C++, although it is more difficult to write in. Add in a scripting language like Lua to C++ and you have a very performant and nice stack of scriptability and close-to-the-hardware stack that feels super powerful.