
Modernize your C++ code - StylifyYourBlog
http://www.jarchitect.com/Blog/?p=1566
======
asveikau
> 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
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).

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

------
huhtenberg
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
More maintainable and idiomatic code.

~~~
yaur
Generated code is unlikely to be more maintainable.

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

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

~~~
eps
How's your astroturfing day going so far?

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

