Modernize your C++ code

http://www.jarchitect.com/Blog/?p=1566

72 32 11 years ago

jbHawk• 11 years ago

I'm really impressed with this tooling. Effectively Resharper for C++. There's a huge market opportunity for C++ tooling.

eps• 11 years ago

How's your astroturfing day going so far?

k__• 11 years ago

Context?

tomjakubowski• 11 years ago

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.

waitwaitwhay2• 11 years ago

Resharper exists in a C++ version. Just preview, but still.

huhtenberg2• 11 years ago

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• 11 years ago

More maintainable and idiomatic code.

yaur• 11 years ago

Generated code is unlikely to be more maintainable.

huhtenberg2• 11 years ago

What makes you think that this "modernization" will make it more maintainable, leave alone more idiomatic?

fsloth3• 11 years 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• 11 years 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.

nostrademons4• 11 years 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.)

plorkyeran• 11 years ago

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.

fsloth3• 11 years 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.

teamhappy2• 11 years 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

fsloth3• 11 years ago

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.

asveikau• 11 years ago

Pass-By-Value: Detect const-ref parameters that would benefit from using the pass-by-value idiom.

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.

StephanTLavavej• 11 years ago

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

exprL• 11 years ago

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.

maxlybbert• 11 years ago

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.

rawnlq• 11 years ago

This post explains when you should and shouldn't use it: https://juanchopanzacpp.wordpress.com/2014/05/11/want-speed-...

Modernize your C++ code

Related Stories