5 ms·

Modernize your C++ code

jbHawk 12y ago
I'm really impressed with this tooling. Effectively Resharper for C++. There's a huge market opportunity for C++ tooling.
- eps 12y ago
  How's your astroturfing day going so far?
  - k__ 12y ago
    Context?
    - ldesegur 12y ago
      New account created in the last few hours. One post only raving about the OP. Hmmmm....
  - tomjakubowski 12y 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.
    - waitwaitwhay 12y ago
      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.
- waitwaitwhay 12y ago
  Resharper exists in a C++ version. Just preview, but still.
huhtenberg 12y 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 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.
JSno 12y ago
if c++ initially came out with c++11 syntax and features. It might be a good language. Now. c++ became a monster including so many different styles, conventions, usages. It's too hard to choose it unless you have legacy system to support.
fsloth 12y 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 12y 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 12y 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 12y 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 12y ago

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

eps 12y ago
How's your astroturfing day going so far?
- k__ 12y ago
  Context?
  - ldesegur 12y ago
    New account created in the last few hours. One post only raving about the OP. Hmmmm....
- tomjakubowski 12y 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.
  - waitwaitwhay 12y ago
    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.
waitwaitwhay 12y ago
Resharper exists in a C++ version. Just preview, but still.

huhtenberg 12y 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 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.

JSno 12y ago

if c++ initially came out with c++11 syntax and features. It might be a good language. Now. c++ became a monster including so many different styles, conventions, usages. It's too hard to choose it unless you have legacy system to support.

fsloth 12y 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 12y 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 12y 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 12y 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 12y ago