5 ms·
This is a usual problem with C++ and why I hate it. There's a lot going on under the hoods, and you must be really knowledgeable of the language to prevent stup
by neves 6y ago
This is a usual problem with C++ and why I hate it. There's a lot going on under the hoods, and you must be really knowledgeable of the language to prevent stupid things. Following some idioms you can really avoid it, but it is useless since your coworkers will fall into the language traps.
- qayxc 6y agoI'd argue that not knowing the language you're working with is a problem that's not exclusive to C++. There's so much more going on under the hood of more high level languages, that writing faster code is straight up black magic [1]. [1] https://stackoverflow.com/questions/28723658/python-why-is-it-faster-to-iterate-over-a-list-than-iterating-over-an-xrange https://stackoverflow.com/questions/28723658/python-why-is-i...
- throwaway894345 6y agoYes, you must always know your language, but mastering (for example) Go is a lot easier than getting a cursory understanding of C++ (i.e., enough to write correct code for non-toy applications). You can get a cursory understanding of Go in a few hours and you can master it in 1-2 months. It would be months and years in C++, respectively. C++ is just a much larger, more complex language, so there is a lot more to know. It's not that C++ is inherently bad--some of that complexity allows C++ to be faster and more powerful than Go; however, we can't pretend that the two are equivalent with respect to their ease of learning or number of footguns.
- qayxc 6y agoI agree in general, but knowing the difference between pass-by reference and pass-by value is C++ 101. Mastering C++ isn't even required to be productive using it, since there's no need to use all the language features simply because they exist. This also avoids the majority of footguns.
- throwaway894345 6y ago> I agree in general, but knowing the difference between pass-by reference and pass-by value is C++ 101. I agree. But the scientific computing community includes a lot of people who have no exposure to computing at all, so that vectors are copied when passed by value (as opposed to a fat pointer a la Go slices) is a performance foot gun for these new users. For that matter, a lot of people coming to C++ from any higher level language will likely be tripped on on this for a while. > Mastering C++ isn't even required to be productive using it, since there's no need to use all the language features simply because they exist. Right, I was distinguishing between "mastering" and "knowing enough to be productive". I'm asserting that you can master Go in far less time than is required to be merely productive in C++ (granted, I'm assuming "productive" means "you're not regularly introducing memory leaks, segfaults, etc" i.e., "you understand memory management best practices in C++"). Specifically, I think it takes 1-2 months for a newbie programmer to become a master of Go and ~6 months to become merely "productive" in C++ (bear in mind that even figuring out how to build non-trivial C++ programs is itself a herculean feat).
- gumby 6y agoFor a systems programming language the part of C++ that most people need to know isn’t huge. There’s a lot in c++ that only exists for back compatibility and you don’t need to use it. There’s also a lot of infrastructure so library writers can write very efficient generic code. Most people are not writing libraries and don’t need that stuff.
- sdenton4 6y agoYou got all the backwards compatibility stuff, though, if you're code base is older than today. Or if you've got co workers who learned on c++11 instead of c++19... Also, templates, and the indecipherable errors they throw. And cpp memory handling errors are one of the largest sources of security holes. I'm convinced that apologising for cpp is basically Stockholm syndrome. These are things we absolutely would not accept in a new language, but we must, because it's what we've got. Rust can't win fast enough, I say...
- throwaway894345 6y agoI would even say that simply knowing which things are essential and which are "legacy things for backwards compatibility that most people don't need to know about" is nontrivial, and I'm not even sure that there is substantial consensus among the C++ community about exactly what is in the "legacy/compatibility things" bucket (no doubt there's wide spread agreement that some features are in this bucket, but I imagine there are a lot of features that are controversial).
- ncmncm 6y agoIt would be great if a modern language could match C++, but none is on the horizon. Rust is powerful enough to do a lot of what C++ is used for, but not the hardest things. There are libraries you write routinely in C++ that you can't code in, or call from, Rust, and never will. The gap will widen with time. Rust is focused on low-level safety at the expense of library power, but you get safety in C++ by coding using more powerful and safe libraries, so C++ comes out ahead in the end. Rust is a way better language than Go or Java. It would be excellent if Rust could displace them, or even just one of them. If its adoption rate were to increase by maybe two or three orders of magnitude, it could survive. But the Rust core team seem not interested in doing what would be needed to get that much adoption, and hype alone won't get it there. Rust's place will be secure when more complaints are written about it than paeans.
- User23 6y agoC++ has a famously complex standard though, to the point that, last I checked, there are no fully standards conforming C++ compilers. I know one member of the standards body and he is an excellent software engineer, a subject matter expert, and just wicked smart too, and he still confesses he doesn't really understand C++. There's a reason why Google doesn't actually have C++ as a supported language, but rather a curated subset thereof that's governed by their house style guide.
- qayxc 6y agoI concur, but using and knowing a reasonable subset is enough to be productive. Rust has its own problems and pitfalls as well, and I doubt that people who don't understand pass-by value vs pass-by reference and its implications will be happy with fighting the compiler over ownership issues. Implementing a doubly linked list comes to mind - trivial in C++ - a brain twister in Rust and apologists will hide behind statements like "they're almost always the wrong choice anyway" or they're "just used pedagogically" [1]. A cynic could interpret that as Stockholm Syndrome as well. [1] https://codereview.stackexchange.com/questions/204183/doubly-linked-list-in-rust https://codereview.stackexchange.com/questions/204183/doubly...
- bufferoverflow 6y agoWhat he described has nothing to do with C++, but with the inefficient algorithm that was chosen.
- mynegation 6y agoC++, while complicated, is actually pretty transparent about it. The difference between pass-by-value and pass-by-reference is one sigil, but at least you see it there and you have at least some idea that it is there for a reason. Compare it with lazy evaluation languages like Haskell or declarative languages like SQL where oftentimes you have to run query planner explanation to troubleshoot the performance problems.
- milesvp 6y ago+1 for sql. I once was looking into a slow query and had to know that ordering text field in mysql requires a filesort regardless of how much data was involved. which means touching a disk. Was easy enough to make a schema change to a varchar small enough not to also trigger a filesort. But learning that required several hours of scouring documentation and making sure the schema change wasn’t modifying the requirements significantly. Also what’s fun is that the data in the tables can change the explain plan. I got to see this myself when dealing with dev vs prod data.
- necovek 6y agoKnowing the basics of CS would surely help in set the expectation for such "SQL" (or rather, RDBMS) behaviour: the problem is the problem of sorting a very large array of strings, which is unsurprisingly a hard one. The very basic experience with RDBMS would point you at a better solution: indexes. Not sure about MySQL or standard SQL, but with Postgres you can keep an ordered index that will be used in an ORDER BY query. It's a common trick employed in programming in general: trade the update/insert cost for query cost (indexes take time to update, but querying is then fast).
- Tomis02 6y ago> Also what’s fun is that the data in the tables can change the explain plan. 1. This change tends to be in your favour, not against you. 2. Data is important, not the code. Of course the plan would change if your data changes. That is the point of the query planner, to find the most efficient way of retrieving the data, based of course on the contents of the database. I agree that you need a good knowledge of your database in order to be effective. Just like with C++, for example. Unfortunately we're not at the point where we can achieve optimal results without understanding the fundamentals, regardless of the programming paradigm.
- formerly_proven 6y agoThere's very little going on under the hood with C++, if it even has a hood.
- andi999 6y agoVtable and vtable pointer is under the hood.
- not2b 6y agoYes, but any C++ programmer who expects to be hired will have a good understanding of vtables and vtable pointers. They are a lot less tricky to reason about than, say, thunks in Haskell.
- tome 6y agoWhat makes you so sure about that?
- ncmncm 6y agoThose are trivial. And have little effect on performance. And are hardly used in good programs. In practice they mainly displace function pointers.
- andi999 6y agoThey might destroy your cache lines though.
- deleted 6y ago[deleted]
- vidarh 6y agoKnowing if you're copying or passing references is essential to understanding most languages that supports both. It's scary how many people are unaware of it, though. Not nearly as dramatic as the example above, but I once cut the time spent on page generation for a commercial CMS by 30% my first day in a new job by realising they did excessive new allocation of strings instead of concatenation (which will amortise the allocations by allocating more space than needed in most C++ implementations). I find it quite disturbing, because, while I prefer to use Ruby these days, C++ documentation is really explicit about guarantees provided by both the language and the standard library with respect to things like memory behaviour and algorithmic complexity. There's if anything less going on under the hood with C++ that you're not explicitly told about than in most modern languages.
- godelski 6y agoOne thing I tell people is that beginning a good C/C++ programmer made me a much better python programmer and makes it substantially easier to pick up other languages. It's not so specific to the language being C as much as it is learning about memory and the what you learn by constantly shooting yourself in the foot because you make dumb mistakes (I still think mistakes are the best way to learn).
- neves 6y agoI agree, but a simple automatically defined copy constructor can spread havoc in a code base.
- dahfizz 6y agoI really have to disagree. There is a lot going on under the hood regardless. That's how computers work. Your Python script has to deal with all the same memory allocation and cache locality issues. C/C++ just gives you the opportunity to see what is happening under the hood and tune it.