5 ms·

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.

glass_of_water 12y ago
More maintainable and idiomatic code.
- yaur 12y ago
  Generated code is unlikely to be more maintainable.
  - frozenport 12y ago
    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.
- huhtenberg 12y ago
  What makes you think that this "modernization" will make it more maintainable, leave alone more idiomatic?
- fsloth 12y ago
  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.
makecheck 12y ago
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.
- nostrademons 12y ago
  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.)
  - lomnakkus 12y ago
    > 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++.)
fsloth 12y ago
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.
- teamhappy 12y ago
  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 https://www.youtube.com/watch?v=JSjoCisIHcM
  - nostrademons 12y ago
    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-googles-new-look.html http://googleblog.blogspot.com/2010/05/spring-metamorphosis-... [2] http://googleblog.blogspot.com/2010/09/search-now-faster-than-speed-of-type.html http://googleblog.blogspot.com/2010/09/search-now-faster-tha...

glass_of_water 12y ago

More maintainable and idiomatic code.

yaur 12y ago
Generated code is unlikely to be more maintainable.
- frozenport 12y ago
  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.
huhtenberg 12y ago
What makes you think that this "modernization" will make it more maintainable, leave alone more idiomatic?
fsloth 12y ago
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.

makecheck 12y ago

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.

nostrademons 12y ago
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.)
- lomnakkus 12y ago
  > 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++.)

fsloth 12y ago

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.

teamhappy 12y ago
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 https://www.youtube.com/watch?v=JSjoCisIHcM
- nostrademons 12y ago
  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-googles-new-look.html http://googleblog.blogspot.com/2010/05/spring-metamorphosis-... [2] http://googleblog.blogspot.com/2010/09/search-now-faster-than-speed-of-type.html http://googleblog.blogspot.com/2010/09/search-now-faster-tha...