Modernize your C++ code(jarchitect.com)
jarchitect.com
Modernize your C++ code
http://www.jarchitect.com/Blog/?p=1566
33 comments
It's an antipattern. Consider the following scenario: a function says "something = move(passed_by_value);". When called with an lvalue, this assumes that copy construction followed by move assignment is as efficient as copy assignment would be (which is what you get when you overload for const X& and X&&, or perfectly forward). This is untrue for vector/string-like things. When you copy construct a vector/string, it must allocate space for N elements, then copy then. Move assignment just transfers ownership, that part is fast. But consider copy assignment. If the destination has sufficient capacity, NO allocation will be performed - instead, the existing elements will be destroyed and the sufficiently-large buffer reused to hold the new elements.
Therefore, "want speed? pass by value" can result in worse performance. Overloading for copy/move is near-optimal and perfect forwarding is optimal - this is what the STL does (push_back is copy/move overloaded, emplace_back perfectly forwards).
Therefore, "want speed? pass by value" can result in worse performance. Overloading for copy/move is near-optimal and perfect forwarding is optimal - this is what the STL does (push_back is copy/move overloaded, emplace_back perfectly forwards).
There's certainly no reason to pass something (big) by value if you only need to look at it, but not copy. However, if you're going to copy the object in any case, you should do it right-away so that the caller my move their copy to you if they don't need one any more.
I'm guessing this detection is for those cases where the passed-by-ref value is always copied.
I'm guessing this detection is for those cases where the passed-by-ref value is always copied.
My understanding is simply that many programmers have a habit of passing parameters as const references. If they want a copy of the parameter, they make that copy by hand. In fact, on Thursday, I found a function in the code I work on that does exactly this.
That prevents some compiler optimizations ( http://stlab.adobe.com/wiki/images/8/85/2008_06_26_classes_t... ), but those optimizations predate C++11, so I don't know why the advice is in this article. In any case, if you want a function to operate in a copy of a parameter, consider passing that parameter by value instead of passing it by const reference and then making a copy. Note, this is not advice to start making unnecessary copies; instead it's advice that if you need a copy of something, rely on the compiler to make that copy for you.
That prevents some compiler optimizations ( http://stlab.adobe.com/wiki/images/8/85/2008_06_26_classes_t... ), but those optimizations predate C++11, so I don't know why the advice is in this article. In any case, if you want a function to operate in a copy of a parameter, consider passing that parameter by value instead of passing it by const reference and then making a copy. Note, this is not advice to start making unnecessary copies; instead it's advice that if you need a copy of something, rely on the compiler to make that copy for you.
This post explains when you should and shouldn't use it: https://juanchopanzacpp.wordpress.com/2014/05/11/want-speed-...
Very nice to see improvements to the tool landscape for C++. I'm sure the toolset that will emerge will be very nice. I just don't see any situation where I would like to subject any production codebase to this particular transform just for the fun of it. Cool CS toy, though.
I see no tangible reason to do this. I mean, all of this is nice, but it's just messing with the working codebase for the sake of messing with it.
Well to take the very first example from the article, adding "override" keywords: that improves your chances of avoiding bugs during normal maintenance. Have you never seen a base class that had more than a few derived classes, some of which may be in places you didn't even know about? Now imagine tweaking a base class method's signature slightly, and missing one of those derived classes somewhere, which had been trying to keep its copy of the signature in sync. Before it was overriding, now it is just a new method; there's a bug that "modernization" would have caught for you.
I'd just like to say that I have found meaningful bugs in existing code bases by running clang-modernize on them and then manually verifying that override was added everywhere I expected it to. It's just not a hypothetical benefit.
You can add them when you're actually facing a bug that you don't know the cause of. If the override keyword helps you find the cause, you are in exactly the same position that you were in, with the same time expended, as if you had pre-emptively added it. If the bug never occurs or you don't need to add declarations to everything to find it, you are strictly better off than if you'd done so initially.
This illustrates a general principle in software maintenance: later. Push decisions off until they're actually causing problems, and then fix them as soon as it's apparent that they're a problem. Code that's removed because of changing requirements or never touched again because the feature is frozen doesn't need to be maintained. Even for code that does need to be maintained, you have more information about what the optimal architecture for the system is once you built out the system more.
(All this assumes consumer or non-critical enterprise grade software, where the cost of a bug is that you spend time finding & fixing it. If you're doing high-assurance software like avionics or medical devices, or anything where a bug is likely to cause major collateral damage, then by all means add every language feature designed to stop bugs ASAP.)
This illustrates a general principle in software maintenance: later. Push decisions off until they're actually causing problems, and then fix them as soon as it's apparent that they're a problem. Code that's removed because of changing requirements or never touched again because the feature is frozen doesn't need to be maintained. Even for code that does need to be maintained, you have more information about what the optimal architecture for the system is once you built out the system more.
(All this assumes consumer or non-critical enterprise grade software, where the cost of a bug is that you spend time finding & fixing it. If you're doing high-assurance software like avionics or medical devices, or anything where a bug is likely to cause major collateral damage, then by all means add every language feature designed to stop bugs ASAP.)
> You can add them when you're actually facing a bug that you don't know the cause of.
EDIT: Sorry, mostly rewrote this comment. Apologies if anyone responded during that time.
Sure, but then you're just reacting to bugs. Wouldn't you like to preemptively prevent bugs? I think this is why you might like to use a C++ compiler rather than an interpreter?
Just reacting is sort of like "what you don't know won't kill you". But the thing is that it might end up killing you (figuratively, not as in avionics). Personally, I think it's part of due diligence as a consultant. Anything this will reduce our chances of making an error before runtime is worth it -- up to a point. Does auto-adding "override" exceed the cutoff point? I don't think so.
Btw, how do you know that these potential problems aren't causing (small per day, but large over time) monetary damage? If you have end-to-end metrics, then you're probably fine, but it can be very hard to judge if bugs are actually causing you damage.
(I'm going on a huge assumption here, namely that this tool -- which I'm not familiar with -- is actually semantics-preserving -- which is an extremely hard problem in C++.)
EDIT: Sorry, mostly rewrote this comment. Apologies if anyone responded during that time.
Sure, but then you're just reacting to bugs. Wouldn't you like to preemptively prevent bugs? I think this is why you might like to use a C++ compiler rather than an interpreter?
Just reacting is sort of like "what you don't know won't kill you". But the thing is that it might end up killing you (figuratively, not as in avionics). Personally, I think it's part of due diligence as a consultant. Anything this will reduce our chances of making an error before runtime is worth it -- up to a point. Does auto-adding "override" exceed the cutoff point? I don't think so.
Btw, how do you know that these potential problems aren't causing (small per day, but large over time) monetary damage? If you have end-to-end metrics, then you're probably fine, but it can be very hard to judge if bugs are actually causing you damage.
(I'm going on a huge assumption here, namely that this tool -- which I'm not familiar with -- is actually semantics-preserving -- which is an extremely hard problem in C++.)
So no, I wouldn't like to preemptively prevent bugs, at least for any substantial cost or risk. At least not in my line of work, which usually focuses on exploratory or risky new features where some tolerance for bugs is allowed. As 37signals says, you can't save time, you can only do less. Every effort you make in a code change is a sunk cost (and often leads to more sunk costs, if follow-on changes are necessary), so you should only do it if it gets you something.
FWIW, the tool is semantics-preserving, and I actually like it (and the general suite of clang refactoring tools) a lot. My point isn't for or against the tool, it's about the general philosophy of maintenance changes. You should use it if you have already decided you're going to switch to C++11, and value style consistency across your team. Or if you are actively having a problem with code maintenance and new features are becoming hard to add - this was the situation that Google was in when we developed the tool. Or because your developers will be happier if they get to use C++11 and don't have to do the conversion work themselves. You should not use it because you read about it on the Internet, or because it's the new hotness.
FWIW, the tool is semantics-preserving, and I actually like it (and the general suite of clang refactoring tools) a lot. My point isn't for or against the tool, it's about the general philosophy of maintenance changes. You should use it if you have already decided you're going to switch to C++11, and value style consistency across your team. Or if you are actively having a problem with code maintenance and new features are becoming hard to add - this was the situation that Google was in when we developed the tool. Or because your developers will be happier if they get to use C++11 and don't have to do the conversion work themselves. You should not use it because you read about it on the Internet, or because it's the new hotness.
This is interesting because it raises the whole meta-question of -- could you have developed feature X faster if you'd already done refactor Y? In my experience the answer is usually "yes", but if you have a mostly-moribund code base already, then it's usually "no".
Hey, reasonable people can disagree! :)
EDIT: "You should not use it because you read about it on the Internet, or because it's the new hotness.". That's a bit of a cheap shot, at least when leveled at the posters in this thread, I think. Hopefully most professional developers are slightly more responsible than that. (Again, experience may differ, so...)
Hey, reasonable people can disagree! :)
EDIT: "You should not use it because you read about it on the Internet, or because it's the new hotness.". That's a bit of a cheap shot, at least when leveled at the posters in this thread, I think. Hopefully most professional developers are slightly more responsible than that. (Again, experience may differ, so...)
I find that if I look at features I write and ask "Could I have developed feature X faster if I had already done refactor Y?", then the answer is usually "yes" as well. The problem is that this isn't the question you're actually faced with when you make a decision (it is the question you're faced with when you're an engineer that actually has to write the code, which is why engineers and management usually differ on the worth of refactoring). It's "If I do refactor X, will it save time on the feature Y that I actually end up launching next?" And for that question, the answer is usually "no".
In other words, we suffer from hindsight bias. For any given feature, there is usually some combination of refactorings that will make it easier. The problem is that these refactorings are only evident in hindsight, once we've actually started to write the feature. If you speculatively do the refactoring, it surely will make some features easier to add, but those features are probably not the ones that you actually end up adding.
The way I solve this in my personal programming (where I am both engineer and manager, so my incentives are aligned) is to do any refactorings I wish I had immediately before writing the code. That way, I know exactly what I'm aiming for and exactly what will make it easier, and there's no guesswork involved. Over time, this also seems to produce optimally-compact code, albeit sometimes non-intuitive to someone newly introduced to the project.
Unfortunately, while this seems optimal from a project perspective, it runs counter to the incentives of both the engineers (who want to seem like really fast & reliable coders to management, and not say "This feature will be delayed because of decisions we previously made") and managers (who want to hear "This feature will be delivered tomorrow", and not delayed because of decisions previously made). Solving this incentive mismatch is an open problem; companies with technical management often do better at it but there's still a big information loss here.
In other words, we suffer from hindsight bias. For any given feature, there is usually some combination of refactorings that will make it easier. The problem is that these refactorings are only evident in hindsight, once we've actually started to write the feature. If you speculatively do the refactoring, it surely will make some features easier to add, but those features are probably not the ones that you actually end up adding.
The way I solve this in my personal programming (where I am both engineer and manager, so my incentives are aligned) is to do any refactorings I wish I had immediately before writing the code. That way, I know exactly what I'm aiming for and exactly what will make it easier, and there's no guesswork involved. Over time, this also seems to produce optimally-compact code, albeit sometimes non-intuitive to someone newly introduced to the project.
Unfortunately, while this seems optimal from a project perspective, it runs counter to the incentives of both the engineers (who want to seem like really fast & reliable coders to management, and not say "This feature will be delayed because of decisions we previously made") and managers (who want to hear "This feature will be delivered tomorrow", and not delayed because of decisions previously made). Solving this incentive mismatch is an open problem; companies with technical management often do better at it but there's still a big information loss here.
The way you went meta in this comment: I wish I could find more kinds of comments like this on the internet. This I can refer to in 5 years.
Very informative comment, thanks.
I certainly agree that local optimization (as in your response to my "example") usually wins in entrenched situations, but I disagree that it's "hindsight bias". Hindsight bias usually applies when you're responding to a future situation based on previous (idealized!) experience, but if you're already in the middle of a project and deciding what to do, then you're not really in the same situation as if you're starting a new project based on previous experience. (That's a bit mangled, I hope my intention makes sense.)
I'll state plainly that I tentatively buy into the refactor-early-refactor-often mantra, assuming that the language can support that reasonably.
For me, I really think that every situation is "global" vs. "local" optimization thing, and I'll argue towards "global" whenever I can, even if it reduces productivity in the short term. Michael C. Feathers' "Working Effectively with Legacy Code" was very instructive in this regard.
I certainly agree that local optimization (as in your response to my "example") usually wins in entrenched situations, but I disagree that it's "hindsight bias". Hindsight bias usually applies when you're responding to a future situation based on previous (idealized!) experience, but if you're already in the middle of a project and deciding what to do, then you're not really in the same situation as if you're starting a new project based on previous experience. (That's a bit mangled, I hope my intention makes sense.)
I'll state plainly that I tentatively buy into the refactor-early-refactor-often mantra, assuming that the language can support that reasonably.
For me, I really think that every situation is "global" vs. "local" optimization thing, and I'll argue towards "global" whenever I can, even if it reduces productivity in the short term. Michael C. Feathers' "Working Effectively with Legacy Code" was very instructive in this regard.
I do not see why you were downvoted. I earn my living writing C++ for a living for mission critical CAD applications and I cannot imagine me or any one of my colleagues use an automatic converter.
C++11 is nice. For new code. I see no reason to use this for old, working code.
C++11 is nice. For new code. I see no reason to use this for old, working code.
This whole "automatic converter" thing is a bit of a straw man. The libraries used by clang-modernize and clang-format are the same clang uses to "work" with your code. If you don't trust them then you've pretty much lost anyway.
What you get out of it is extra performance — that's it, really.
---
Here's a talk where Google's LLVM team leader introduces both tools: https://www.youtube.com/watch?v=JSjoCisIHcM
What you get out of it is extra performance — that's it, really.
---
Here's a talk where Google's LLVM team leader introduces both tools: https://www.youtube.com/watch?v=JSjoCisIHcM
I was actually (I think) the first reference customer of the tooling libraries underneath clang-modernize and clang-format inside Google, and worked with Chandler and Manuel to get a proof of concept out in December 2010. My code was long gone long before it was upstreamed to the open-source Clang project, and was really just a barely-working prototype. It was promising enough (and encouraging enough that an outside engineer from Search had personally invested time in writing it) to get the project staffed up as an actual Google project, though.
The real reason we wanted it was because we had just redesigned the search page entirely [1] and launched Google Instant [2], and the former was launched to "Everything except for IE6 and RTL languages", the latter was launched to "Modern browsers that can handle the performance requirements, if the user has turned it on", and the resulting combination of conditional branches in the code made it virtually impossible to launch anything else. I was leading a short mini-project to get the new interface launched everywhere and clean up all of the dead code paths that had only serviced the old Google interface.
Simultaneously, Chandler and Manuel had come up with this library to do pattern-matching on top of the Clang AST, and they were looking for a reference customer or at least some reason to exist as a project. So they were like "Let us help you with that - we can let you write tools that will fix your 1000+ conditional branches automatically."
Ironically, my project actually failed. (At least the part where we used automated tools to remove dead code - we did succeed in launching the new interface everywhere, so it was considered a success by management). The old code was removed manually by engineers over the next 2 years. But what it did show was that a.) there was demand for these automated refactoring tools inside the company and b.) the primary blocker to effectively writing these tools was the need to reformat source code as you add or remove expressions, which is why clang-format was developed.
[1] http://googleblog.blogspot.com/2010/05/spring-metamorphosis-...
[2] http://googleblog.blogspot.com/2010/09/search-now-faster-tha...
The real reason we wanted it was because we had just redesigned the search page entirely [1] and launched Google Instant [2], and the former was launched to "Everything except for IE6 and RTL languages", the latter was launched to "Modern browsers that can handle the performance requirements, if the user has turned it on", and the resulting combination of conditional branches in the code made it virtually impossible to launch anything else. I was leading a short mini-project to get the new interface launched everywhere and clean up all of the dead code paths that had only serviced the old Google interface.
Simultaneously, Chandler and Manuel had come up with this library to do pattern-matching on top of the Clang AST, and they were looking for a reference customer or at least some reason to exist as a project. So they were like "Let us help you with that - we can let you write tools that will fix your 1000+ conditional branches automatically."
Ironically, my project actually failed. (At least the part where we used automated tools to remove dead code - we did succeed in launching the new interface everywhere, so it was considered a success by management). The old code was removed manually by engineers over the next 2 years. But what it did show was that a.) there was demand for these automated refactoring tools inside the company and b.) the primary blocker to effectively writing these tools was the need to reformat source code as you add or remove expressions, which is why clang-format was developed.
[1] http://googleblog.blogspot.com/2010/05/spring-metamorphosis-...
[2] http://googleblog.blogspot.com/2010/09/search-now-faster-tha...
That's a pretty cool story you got there :)
clang-format is actually my favourite out of the two. I never had a real use case for clang-modernize (I did try it once though; just to see the magic happen). clang-format however impresses me pretty much every day. It doesn't really do anything Go's "fmt" command can't do, but it just looks so much more impressive given C++'s complex syntax.
clang-format is actually my favourite out of the two. I never had a real use case for clang-modernize (I did try it once though; just to see the magic happen). clang-format however impresses me pretty much every day. It doesn't really do anything Go's "fmt" command can't do, but it just looks so much more impressive given C++'s complex syntax.
More maintainable and idiomatic code.
Idiomatic presumes there is some gold standard of style you can use with C++. Dude, there is no such thing as "idiomatic C++". I've seen lots of idiotic C++, sure, but idiomatic... every team must select the subset and style they use by themselves. With expert users some specific patterns start to emerge that they've found lead to least horrible code.
What makes you think that this "modernization" will make it more maintainable, leave alone more idiomatic?
Generated code is unlikely to be more maintainable.
Code is code. I doubt a computer program could do worse than my undergrads, indeed it will probably be functionally correct. Today I fixed a bug where a condition std::thread member used a condition variable in the constructor, problem was that the std::thread came before the condition variable in the structure declaration. No computer would make that mistake.
I'm really impressed with this tooling. Effectively Resharper for C++. There's a huge market opportunity for C++ tooling.
Resharper exists in a C++ version. Just preview, but still.
How's your astroturfing day going so far?
I don't understand this reaction. If the thread had several posts from green users like these, maybe it would be appropriate to jump to this conclusion.
A more charitable explanation that I also consider to be likely is that jbHawk was a long-time HN reader who simply never felt the need to have an account until this post about a pretty neat tool which inspired them to comment.
A more charitable explanation that I also consider to be likely is that jbHawk was a long-time HN reader who simply never felt the need to have an account until this post about a pretty neat tool which inspired them to comment.
Im such a user. Sometimes I feel the urge to comment, but it happens so rarely that I won't recall my username or password. So I probably have 20 accounts on HN and 40 on Reddit, each with just a few posts.
I don't get why to make this change and the justification (after following 2 links deep: Want Speed? Pass by Value) is a 404.
Move constructors are great and it's awesome that a bunch of what used to be copy-constructor overuse in C++03 can now be done without deep copies in C++11. But I don't understand why explicitly move from something that is explicit and guaranteed to be cheap (pass by reference) to something that might be cheap if everything has reasonable move-ctors or (if not all ducks are in a row) might simply degrade to incurring the C++03-style over-copies. Does not seem like a strict improvement to me. Seems instead like blindly applying this to existing code will slow it down in some cases, possibly dramatically.