Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modernize your C++ code

jarchitect.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Modernize your C++ code

#11

Post by fsloth »

glass_of_water wrote: post #5
huhtenberg wrote: post #3

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.

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.

Re: Modernize your C++ code

#12

Post by fsloth »

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.

Re: Modernize your C++ code

#13

Post by nostrademons »

makecheck wrote: post #9
huhtenberg wrote: post #3

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 try…

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.)

Re: Modernize your C++ code

#14

Post by teamhappy »

fsloth wrote: post #10
huhtenberg wrote: post #3

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.

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.

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

Re: Modernize your C++ code

#16

Post by nostrademons »

teamhappy wrote: post #14
fsloth wrote: post #10

Earlier quoted context omitted.

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.

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

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...

Re: Modernize your C++ code

#17

Post by lomnakkus »

nostrademons wrote: post #13
makecheck wrote: post #9

Earlier quoted context omitted.

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 try…

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 illustrat…

> 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++.)

Re: Modernize your C++ code

#18

Post by teamhappy »

nostrademons wrote: post #16
teamhappy wrote: post #14

Earlier quoted context omitted.

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

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…

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.

Re: Modernize your C++ code

#19

Post by nostrademons »

lomnakkus wrote: post #17
nostrademons wrote: post #13

Earlier quoted context omitted.

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 illustrat…

> 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…

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.

Re: Modernize your C++ code

#20

Post by lomnakkus »

nostrademons wrote: post #19
lomnakkus wrote: post #17

Earlier quoted context omitted.

> 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…

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),…

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...)

Post reply on HN