Any tools for "refactoring" C++ code?

[Robert Hutchings]

As I read the C++ 11 and C++ 14 changes, I was wondering if there are
any tools one could use to update older code to incorporate the 2011 and
2014 updates? Or is just a manual "do it yourself" thing?

[Vincenzo Mercuri]

I don't think such a tool exists or will ever exist. However,
in case you are concerned about performance, you could get
significant improvements just by recompiling your "old" code
with a compiler that supports at least C++11.

--
Vincenzo Mercuri

[Robert Hutchings]

I found this:
http://www.klocwork.com/products-services

[Marcel Koeppen]

Hi,

Clang C++ Modernizer can run some transformations on old code to make
it use range based for-loops, nullptr, auto, etc.

http://clang.llvm.org/extra/clang-modernize.html

Marcel

[Jorgen Grahn]

What would be the point of automating it? You don't learn anything
from that.

On the other hand, I'd welcome practical tips -- like "these are the
areas where your C++98 code is most likely to benefit from a touchup"
or "introduce C++11 features it in this order to make the most of them".

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Robert Hutchings]

On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
> On Sat, 2014-11-15, Robert Hutchings wrote:
>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>> any tools one could use to update older code to incorporate the 2011 and
>> 2014 updates? Or is just a manual "do it yourself" thing?
>
> What would be the point of automating it? You don't learn anything
> from that.
>
> On the other hand, I'd welcome practical tips -- like "these are the
> areas where your C++98 code is most likely to benefit from a touchup"
> or "introduce C++11 features it in this order to make the most of them".
>
> /Jorgen
>

Good point! Automating it might not be very educational...

[David Thornley]

On 11/15/2014 2:39 PM, Jorgen Grahn wrote:

> On Sat, 2014-11-15, Robert Hutchings wrote:
>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>> any tools one could use to update older code to incorporate the 2011 and
>> 2014 updates? Or is just a manual "do it yourself" thing?
>
> What would be the point of automating it? You don't learn anything
> from that.
>

On the other hand, some code bases are large enough that going through
and doing everything yourself is going to take a while.

> On the other hand, I'd welcome practical tips -- like "these are the
> areas where your C++98 code is most likely to benefit from a touchup"
> or "introduce C++11 features it in this order to make the most of them".
>

Some of the advances seem more like better ways to write the same thing,
and those I suppose you can just add as you modify things, like the
new for loop and "auto". I don't see any strong reason to go through
and convert "boost::shared_ptr" to "std::shared_ptr".

Some of them are for better correctness. We found several bugs from
just adding "override" to virtual functions. Changing NULL or 0
(when used as the null pointer constant) to "nullptr" might chase out
a few. I'm not real sure about "unique_ptr" vs. "auto_ptr", but
you might be able to get around that with a global replace.

Some of them might improve performance. Besides just compiling with
a modern compiler (which will bring in the better library), you might
add move constructors and assignment operators to your classes.

I'm not coming up with much more off the top of my head. A lot of
the new functionality is better suited to be used as you write
new code rather than changing old code.

[Robert Hutchings]

There is a product called "Understand" from www.scitools.com. This is
more of an code-analyzer and cross-referencing type tool. Probably best
to update older code as needed and then -perhaps- introduce C++ 11/14
concepts as appropriate.

[Öö Tiib]

On Sunday, 16 November 2014 20:50:35 UTC+2, David Thornley wrote:
> On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
> > On Sat, 2014-11-15, Robert Hutchings wrote:
> >> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
> >> any tools one could use to update older code to incorporate the 2011 and
> >> 2014 updates? Or is just a manual "do it yourself" thing?
> >
> > What would be the point of automating it? You don't learn anything
> > from that.
> >
> On the other hand, some code bases are large enough that going through
> and doing everything yourself is going to take a while.

It is quite likely going to take a while anyway. Regardless if refactoring
is done manually or with a tool we need retesting and fixing. Something
always breaks with refactoring. If the code-base is not small ...
say 300 000 lines of code then it may even take some man months to make
it to work again.

If you only to moderately modernize the classes that you have to
maintain anyway (because of defect fix or improvement needed) then that
is not too large work even when whole code base is large.

> > On the other hand, I'd welcome practical tips -- like "these are the
> > areas where your C++98 code is most likely to benefit from a touchup"
> > or "introduce C++11 features it in this order to make the most of them".
> >
> Some of the advances seem more like better ways to write the same thing,
> and those I suppose you can just add as you modify things, like the
> new for loop and "auto". I don't see any strong reason to go through
> and convert "boost::shared_ptr" to "std::shared_ptr".

Several families of smart pointers side-by-side will always cause
quirks. *If* to replace those ('shared_ptr'/'weak_ptr') at
all then better in whole code-base.

'std::unique_ptr' is the best smart pointer. It is better than
'boost::scoped_ptr' and it cooperates somewhat with 'std::shared_ptr'.
Lot of 'shared_ptr' usages were actually where 'unique_ptr' is more
appropriate (and far more efficient). So if to review 'shared_ptr'
usages anyway then it is little work to replace it with 'std' version.

> Some of them are for better correctness. We found several bugs from
> just adding "override" to virtual functions. Changing NULL or 0
> (when used as the null pointer constant) to "nullptr" might chase out
> a few. I'm not real sure about "unique_ptr" vs. "auto_ptr", but
> you might be able to get around that with a global replace.

The 'auto_ptr' was quite confusing to people. On most cases when I used
it (as performance optimization) some other maintainer later misunderstood
what is going on. So it is good idea to hunt out all 'auto_ptr' if
there are any left. Likely there aren't many.

> Some of them might improve performance. Besides just compiling with
> a modern compiler (which will bring in the better library), you might
> add move constructors and assignment operators to your classes.

Better is to try first to rewrite the classes in a way that
compiler-generated copy and move will do the right thing.

[Richard]

[Please do not mail me a copy of your followup]

Marcel Koeppen <use...@marzelpan.de> spake the secret code
<dqbkjb-...@medusa.orcus.marzelpan.de> thusly:

This is the one you want to use; it's awesome.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Robert Hutchings <rm.hut...@gmail.com> spake the secret code
<m48etn$1cn$1...@dont-email.me> thusly:

>On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
>> On Sat, 2014-11-15, Robert Hutchings wrote:
>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>> any tools one could use to update older code to incorporate the 2011 and
>>> 2014 updates? Or is just a manual "do it yourself" thing?
>>
>> What would be the point of automating it? You don't learn anything
>> from that.

Any refactoring you can perform automatically is 100x more useful than
any refactoring you must perform manually. The larger the code base,
the higher the multiplier on the usefulness.

Doing it once or twice is all it takes to learn something. Doing it
hundreds or thousands of times across your code base is just drudgery.

[Richard]

[Please do not mail me a copy of your followup]

David Thornley <da...@thornley.net> spake the secret code
<Sp-dndnE16FybPXJ...@posted.visi> thusly:

>I'm not coming up with much more off the top of my head. A lot of
>the new functionality is better suited to be used as you write
>new code rather than changing old code.

Switching to move semantics might have far-reaching changes through
your code.

Many people use shared_ptr<T> simply because move semantics for T
didn't exist and they wanted a function that returned a vector or
something like that. I've even seen people get obsessive about
returning strings and insisting that everything be shared_ptr<string>.

[Ian Collins]

Richard wrote:
> [Please do not mail me a copy of your followup]

Why would I?

> David Thornley <da...@thornley.net> spake the secret code
> <Sp-dndnE16FybPXJ...@posted.visi> thusly:
>
>> I'm not coming up with much more off the top of my head. A lot of
>> the new functionality is better suited to be used as you write
>> new code rather than changing old code.
>
> Switching to move semantics might have far-reaching changes through
> your code.
>
> Many people use shared_ptr<T> simply because move semantics for T
> didn't exist and they wanted a function that returned a vector or
> something like that. I've even seen people get obsessive about
> returning strings and insisting that everything be shared_ptr<string>.

That's never really been a problem. RVO has been a saviour in that area
for a long time.

--
Ian Collins

[Robert Hutchings]

On 11/16/2014 10:35 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Marcel Koeppen <use...@marzelpan.de> spake the secret code
> <dqbkjb-...@medusa.orcus.marzelpan.de> thusly:
>
>> On 2014-11-15 15:02:29 +0000, Robert Hutchings said:
>>
>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>> any tools one could use to update older code to incorporate the 2011
>>> and 2014 updates? Or is just a manual "do it yourself" thing?
>>
>> Clang C++ Modernizer can run some transformations on old code to make
>> it use range based for-loops, nullptr, auto, etc.
>>
>> http://clang.llvm.org/extra/clang-modernize.html
>
> This is the one you want to use; it's awesome.
>

I will definitely check this out. Thanks!

[Scott Lurndal]

Really? Can you elaborate a bit? How does recompilation
of unmodified code improve by using a compiler that supports
newer syntax that the program doesn't even use?

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<mSoaw.427825$Lq6.3...@fx29.iad> thusly:

You could benefit from the improved performance of move semantics.
Methods/function that return std::string would benefit and they are
pretty common. Methods that return containers would also benefit, but
they are less common for people who are sensitive to performance in
a pre-move semantics code base.

There may be other examples of improvements in the standard library
classes that can yield improved performance simply by using the new
compiler.

Compilers often get better at producing code from one release to
another as well, so using a newer compiler can make your code faster
or smaller (depending on options) "for free".

[Jorgen Grahn]

On Mon, 2014-11-17, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Robert Hutchings <rm.hut...@gmail.com> spake the secret code
> <m48etn$1cn$1...@dont-email.me> thusly:
>
>>On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
>>> On Sat, 2014-11-15, Robert Hutchings wrote:
>>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>>> any tools one could use to update older code to incorporate the 2011 and
>>>> 2014 updates? Or is just a manual "do it yourself" thing?
>>>
>>> What would be the point of automating it? You don't learn anything
>>> from that.
>
> Any refactoring you can perform automatically is 100x more useful than
> any refactoring you must perform manually. The larger the code base,
> the higher the multiplier on the usefulness.
>
> Doing it once or twice is all it takes to learn something. Doing it
> hundreds or thousands of times across your code base is just drudgery.

You don't answer my question, though: what is the point? You now have
converted your code to a dialect of C++ which few people understand,
and you yourself haven't learned to use it.

(And what could possibly be a hundred times more useful than learning
something?)

[woodb...@gmail.com]

On Monday, November 17, 2014 1:08:06 PM UTC-6, Jorgen Grahn wrote:
> On Mon, 2014-11-17, Richard wrote:
> > [Please do not mail me a copy of your followup]
> >
> > Robert Hutchings <rm.hut...@gmail.com> spake the secret code
> > <m48etn$1cn$1...@dont-email.me> thusly:
> >
> >>On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
> >>> On Sat, 2014-11-15, Robert Hutchings wrote:
> >>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
> >>>> any tools one could use to update older code to incorporate the 2011 and
> >>>> 2014 updates? Or is just a manual "do it yourself" thing?
> >>>
> >>> What would be the point of automating it? You don't learn anything
> >>> from that.
> >
> > Any refactoring you can perform automatically is 100x more useful than
> > any refactoring you must perform manually. The larger the code base,
> > the higher the multiplier on the usefulness.
> >
> > Doing it once or twice is all it takes to learn something. Doing it
> > hundreds or thousands of times across your code base is just drudgery.
>
> You don't answer my question, though: what is the point? You now have
> converted your code to a dialect of C++ which few people understand,

After many conferences the past 3 years where half of the
talks cover new language features, I think more than a few
understand it.

> and you yourself haven't learned to use it.
>

From my experience automating things, you learn
how to use whatever it is you are automating.

> (And what could possibly be a hundred times more useful than learning
> something?)
>

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Öö Tiib]

Standard library of C++ does use the new and more efficient
features. So if your code did use something from standard library
then it will likely be faster despite you change no byte of it.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnm6khsa.1...@frailea.sa.invalid> thusly:

>On Mon, 2014-11-17, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Robert Hutchings <rm.hut...@gmail.com> spake the secret code
>> <m48etn$1cn$1...@dont-email.me> thusly:
>>
>>>On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
>>>> On Sat, 2014-11-15, Robert Hutchings wrote:
>>>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>>>> any tools one could use to update older code to incorporate the 2011 and
>>>>> 2014 updates? Or is just a manual "do it yourself" thing?
>>>>
>>>> What would be the point of automating it? You don't learn anything
>>>> from that.
>>
>> Any refactoring you can perform automatically is 100x more useful than
>> any refactoring you must perform manually. The larger the code base,
>> the higher the multiplier on the usefulness.
>>
>> Doing it once or twice is all it takes to learn something. Doing it
>> hundreds or thousands of times across your code base is just drudgery.
>
>You don't answer my question, though: what is the point?

One might as well ask:

Since C++ can be transformed into C, what is the point?

The point is that using C++ allows us to get the job done at a higher
level of abstraction than C, without losing the efficiencies of C. We
get the compiler to do more work for us so that we can work in a
manner that is expressive and intention revealing without having to
shove a thousand implementation details up into your face in every
function.

If there was no point to these features in C++11, they wouldn't have
been introduced.

As far as the transformations performed by clang-modernize:

- use of range-based for loops makes loops easier to read;
intent is clearly revealed without excessive syntax
- use of nullptr makes pointer use more explicit;
intent is clearly revealed without ambiguous syntax
- use of auto removes unnecessary syntactic noise;
using nested iterator typedefs to declare iterators just makes for
syntactic noise that gets in the way of clearly reading the intent
- use of override makes explicit when methods are being overridden and
more clearly reveals intent; this can result in bugs being found if
the intention was to override a method in the base but the method
name was misspelled or the signature didn't completely match
- use pass by value; the intention is more clearly revealed. We don't
need to chase through implementation details to discover that the
only reason references were used was to achieve some sort of hand
optimization that the compiler can do for us automatically with move
semantics, copy elision and return value optimization.
- replace auto_ptr with unique_ptr; replace error-prone semantics of
auto_ptr with well defined semantics of unique_ptr. This one may be
a toss up depending on your team and your code base.

>You now have
>converted your code to a dialect of C++ which few people understand,

Few people? LOL. C++11 has been around for about 3 years and none of
the above transformations, with the possible exception of the auto_ptr
-> unique_ptr change, are going to throw any decent programmer into a
tizzy. Every time I've shown existing C++ programmers these new
features through examples they always got it within a few seconds.

SECONDS.

These features aren't rocket science and don't take very long to learn.

We're not talking esoteric guru level template metaprogramming here.

It's syntactic sugar for the most part.

[Öö Tiib]

Note that "Loop Convert" and "Use-Auto" are just eye-candy
but "Use-Nullptr" and "Add-Override" improve safety and
"Pass-By-Value" and "Replace-AutoPtr" even improve performance.

[Scott Lurndal]

A remote possibility, I would expect. Given that the run-time
component (e.g. libstdc++.so.6 on linux) is dynamically linked,
most benefit would accrue sans recompilation by simply updating
the library to a newer version.

In any case, simply switching to a new compiler is not feasible
for most real-world projects; given internal dependencies, third-party
dependencies, the effort required to requalify any non-trivial
application with the new compilation tools and the cost of labor.

[Ian Collins]

Scott Lurndal wrote:
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>> On Monday, 17 November 2014 17:54:07 UTC+2, Scott Lurndal wrote:
>>> Vincenzo Mercuri <inv...@world.net> writes:
>>>> Il 15/11/2014 16:02, Robert Hutchings ha scritto:
>>>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>>>> any tools one could use to update older code to incorporate the 2011 and
>>>>> 2014 updates? Or is just a manual "do it yourself" thing?
>>>>
>>>> I don't think such a tool exists or will ever exist. However,
>>>> in case you are concerned about performance, you could get
>>>> significant improvements just by recompiling your "old" code
>>>> with a compiler that supports at least C++11.
>>>
>>> Really? Can you elaborate a bit? How does recompilation
>>> of unmodified code improve by using a compiler that supports
>>> newer syntax that the program doesn't even use?
>>
>> Standard library of C++ does use the new and more efficient
>> features. So if your code did use something from standard library
>> then it will likely be faster despite you change no byte of it.
>
> A remote possibility, I would expect. Given that the run-time
> component (e.g. libstdc++.so.6 on linux) is dynamically linked,
> most benefit would accrue sans recompilation by simply updating
> the library to a newer version.

No, it wouldn't.

Consider the use of move constructors - how could these appear in the
object code without recompilation?

> In any case, simply switching to a new compiler is not feasible
> for most real-world projects; given internal dependencies, third-party
> dependencies, the effort required to requalify any non-trivial
> application with the new compilation tools and the cost of labor.

Whether to update the compiler depends on project priorities. It there
is sufficient benefit form new features, then the update will be
justified. You don't have to update all of the project components in
one pass.

--
Ian Collins

[Öö Tiib]

On Monday, 17 November 2014 23:34:40 UTC+2, Scott Lurndal wrote:
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
> >On Monday, 17 November 2014 17:54:07 UTC+2, Scott Lurndal wrote:
> >> Vincenzo Mercuri <inv...@world.net> writes:
> >> >Il 15/11/2014 16:02, Robert Hutchings ha scritto:
> >> >> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
> >> >> any tools one could use to update older code to incorporate the 2011 and
> >> >> 2014 updates? Or is just a manual "do it yourself" thing?
> >> >
> >> >I don't think such a tool exists or will ever exist. However,
> >> >in case you are concerned about performance, you could get
> >> >significant improvements just by recompiling your "old" code
> >> >with a compiler that supports at least C++11.
> >>
> >> Really? Can you elaborate a bit? How does recompilation
> >> of unmodified code improve by using a compiler that supports
> >> newer syntax that the program doesn't even use?
> >
> >Standard library of C++ does use the new and more efficient
> >features. So if your code did use something from standard library
> >then it will likely be faster despite you change no byte of it.
>
> A remote possibility, I would expect. Given that the run-time
> component (e.g. libstdc++.so.6 on linux) is dynamically linked,
> most benefit would accrue sans recompilation by simply updating
> the library to a newer version.

How? Big part of C++ standard libraries is implemented in include
files. C++ library can't be replaced without recompiling.

> In any case, simply switching to a new compiler is not feasible
> for most real-world projects; given internal dependencies, third-party
> dependencies, the effort required to requalify any non-trivial
> application with the new compilation tools and the cost of labor.

I did not say that it is cost-free. I said that Vincenzo was correct
that recompiling C++98 code with C++11 compiler does often improve
product's performance. If serious maintenance works are in plan anyway
then the switch is possibly worth it. Also most of the developers
actually like to switch to more modern tools. It tends to add to
success when the involved engineers do like what is going on.

[Jorgen Grahn]

On Mon, 2014-11-17, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnm6khsa.1...@frailea.sa.invalid> thusly:
>
>>On Mon, 2014-11-17, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Robert Hutchings <rm.hut...@gmail.com> spake the secret code
>>> <m48etn$1cn$1...@dont-email.me> thusly:
>>>
>>>>On 11/15/2014 2:39 PM, Jorgen Grahn wrote:
>>>>> On Sat, 2014-11-15, Robert Hutchings wrote:
>>>>>> As I read the C++ 11 and C++ 14 changes, I was wondering if there are
>>>>>> any tools one could use to update older code to incorporate the 2011 and
>>>>>> 2014 updates? Or is just a manual "do it yourself" thing?
>>>>>
>>>>> What would be the point of automating it? You don't learn anything
>>>>> from that.
>>>
>>> Any refactoring you can perform automatically is 100x more useful than
>>> any refactoring you must perform manually. The larger the code base,
>>> the higher the multiplier on the usefulness.
>>>
>>> Doing it once or twice is all it takes to learn something. Doing it
>>> hundreds or thousands of times across your code base is just drudgery.
>>
>>You don't answer my question, though: what is the point?
>
> One might as well ask:
>
> Since C++ can be transformed into C, what is the point?
>
> The point is that using C++ allows us to get the job done at a higher

...
[snip]

You seem to misunderstand my question: I don't question the usefulness
of C++ or C++11. My question above was

What would be the point of automating it?

^^^^^^^^^^^^^^^^

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code

<slrnm6m0u1.1...@frailea.sa.invalid> thusly:

>You seem to misunderstand my question: I don't question the usefulness
>of C++ or C++11. My question above was
>
> What would be the point of automating it?

Automated refactorings can be applied over a large code base quickly
and are (usually) less error prone.

Specifically, with clang-modernize you should read the documentation
on the provided refactorings. Not all of them are perfect; replacing
auto_ptr with unique_ptr or applying the call-by-value transformations
might best be applied with some oversight.

Some people consider excessive use of 'auto' to be obfuscating.

I'm not aware of anyone complaining about the range for loop
transformation however.

Having done lots of refactoring of C++ code by hand, I can tell you
that being able to apply refactorings in an automated manner is almost
always preferable.

The only caveat is that you have to be able to trust your refactoring
tool. Many refactoring tools do refactorings on an ad-hoc basis and
can introduce errors. This is why I created a test suite for C++
refactoring tools:
<https://github.com/LegalizeAdulthood/refactor-test-suite>
<http://legalizeadulthood.wordpress.com/2014/06/13/refactoring-test-results-for-vax-10-8-2036-0-built-2014-05-22/>
<http://legalizeadulthood.wordpress.com/2010/02/02/c-refactoring-tools-test-suite-available/>

Since clang-modernize uses a *real* C++ parser that is used by a
production quality compiler in order to extract information about the
source code, it is much more reliable and trustworthy than tools that
use ad-hoc parsing or a parser that isn't used to actually compile
real-world C++ code.

[Jorgen Grahn]

On Tue, 2014-11-18, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnm6m0u1.1...@frailea.sa.invalid> thusly:
>
>>You seem to misunderstand my question: I don't question the usefulness
>>of C++ or C++11. My question above was
>>
>> What would be the point of automating it?
>
> Automated refactorings can be applied over a large code base quickly
> and are (usually) less error prone.

I suspect we have wildly different philosophies.

I'm conservative.

I've spent a lot of time in maintenance, so I value the history: going
back through the version control tool and seing all changes, one by
one, and the rationales for them. And I really like it when code only
changes when it /has/ to change. (That doesn't mean I don't do
refactoring, or don't want to use C++11.)

I also see source code as a message from one human to another, and
distrust anything written by a machine, intended for reading by a
human. You need a tone, and good taste, to write code.

Lastly, I see refactoring as a way to become more familiar with the
code. I can find things out, or make improvements that a program
cannot make, while doing the refacotoring.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code

<slrnm6puj4.1...@frailea.sa.invalid> thusly:

>On Tue, 2014-11-18, Richard wrote:
>>
>> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
>> <slrnm6m0u1.1...@frailea.sa.invalid> thusly:
>>>

>>> What would be the point of automating it?
>>
>> Automated refactorings can be applied over a large code base quickly
>> and are (usually) less error prone.
>
>I suspect we have wildly different philosophies.

Not really.

>I've spent a lot of time in maintenance, so I value the history: going
>back through the version control tool and seing all changes, one by
>one, and the rationales for them.

Automated refactoring tools are othogonal to having good history. I
don't see this as being any sort of problem for refactoring, whether
it is applied by a tool or by hand.

>And I really like it when code only
>changes when it /has/ to change.

That raises an interesting point of when to apply this sort of stuff.
If you have a library or code base to which you aren't doing any
active development (i.e. few, if any new features added) and you are
still supporting it, then I wouldn't say to apply clang-modernize to
it, but I would suggest evaluating the switch to a new compiler. The
longer you stay on older compilers, the more difficult it is to switch
when you are forced to switch.

If you have a project that is still under active development, then I
see no reason to lag behind on C++11 features that make your code
easier to understand and therefore easier to modify and maintain.

>I also see source code as a message from one human to another, and
>distrust anything written by a machine, intended for reading by a
>human. You need a tone, and good taste, to write code.

In the context of clang-modernize I don't see the problem here either.
The whole point of many of the C++11 features was to make code easier
to read and easier to understand.

>Lastly, I see refactoring as a way to become more familiar with the
>code. I can find things out, or make improvements that a program
>cannot make, while doing the refacotoring.

Nothing in clang-modernize is prohibiting this either.

Your objections have been stated very abstractly, while the benefits of
a tool like clang-modernize -- and so far this is the ONLY tool that has
come up in this thread -- are very specific and focused. If you want
to continue saying that you think clang-modernize would be a bad idea
to apply to your code, then I suggest that you clarify your specific
objections to the specific transformations that clang-modernize can
apply to a source file.

[woodb...@gmail.com]

I think this is an interesting article, but am
not sure it gives automation a fair assessment.

http://online.wsj.com/articles/automation-makes-us-dumb-1416589342


Brian
Ebenezer Enterprises - Heavenly code.
http://webEbenezer.net