Re: [lmi] static_assert and :argdo [Was: Replacing boost with std C++11]

[Vadim Zeitlin]

On Wed, 11 Jan 2017 09:50:41 +0000 Greg Chicares <address@hidden> wrote:

GC> >  FWIW I'd use
GC> > 
GC> >   perl -0777 -i'' -pe 
's/BOOST_STATIC_ASSERT(\s*)\(\(([^;]+)\)\);/static_assert\1(\2);/' *.?pp
GC> 
GC> I reviewed so many regexes in 'test_coding_rules.cpp' earlier today
GC> that it's hard to look at that. But let's see...oh, I guess plain
GC> '(' is for grouping, and '\(' is a literal left parenthesis; with
GC> sed, I'm used to the opposite meanings. Okay, thanks, I see. Due to
GC> my extensive experience with sed, I tend not to automate changes
GC> that extend across '\n' boundaries.

 IMO using sed for multiline replacements is an exercise in masochism. I
know it can be done and I even knew how to do it but I was very glad when I
finally could forget everything I knew about sed pattern space and hold
command because I convinced myself that it was not quite a crime against
humanity to use a few extra microseconds to start Perl instead of sed in
this case -- I'm sure that the gains from optimizing the time of writing
such one lines with Perl rather than sed compensate at least thousandfold
what I lost on stopping to optimize the script running time.

GC> Anyway, some of these assertions had a "Double parentheses" comment,
GC> and some didn't. And I wanted to use 'J' to join lines together, iff
GC> that didn't make the line too long. And one was a conjunction that
GC> could be improved by splitting it into two assertions. So there are
GC> good reasons for considering each one separately in an editor, yet
GC> the doubled parentheses could have been handled automatically.

 Yes, I usually start with a global search-and-replace and then review the
changes manually and refine them if necessary.

GC> BTW, here's often a tidy
GC> solution to be found at stackoverflow:
GC> 
GC> 
http://stackoverflow.com/questions/2084210/remove-a-pair-of-parentheses-brackets-or-braces-in-vim
GC> |   %x``x

 Yes, I often use this and put it inside some register and then apply it
using "@" when I have to remove many pairs of parentheses.

GC> > for this. This even seems to work correctly. And I only had to do "git
GC> > reset --hard HEAD" once while testing it.
GC> 
GC> I've had unhappy experiences with that.

 Of course, "git reset --hard" is one of the (very few) truly dangerous git
commands that can lose changes irreversibly, so you must always run "git
status" before doing it. In this particular case I knew I had no changes
before starting to experiment, however, so I didn't risk anything.

GC> Now I just trash the files with
GC> 'nautilus' and restore them with 'git checkout -- .' because it seems
GC> less likely that I'll lose anything useful by accident (and I can
GC> un-trash them if anything goes wrong). Or am I mistaken--are these:
GC>   git reset --hard HEAD
GC>   git checkout -- .
GC> equally likely to throw away a useful local change that I had forgotten
GC> about (so that I wouldn't have moved it to trash)?

 Yes, "git checkout -- ." is dangerous too and, unless I'm missing
something, isn't really different from "git reset --hard" if you have no
saved changes in the index. I tend to avoid using "." with "git checkout
--" and use it only with the individual files, IMHO it's much simpler to
accidentally do "git checkout -- ." than "git reset --hard", but maybe it's
just because I trained myself to subconsciously pause whenever I type
"--hard" and ask myself whether I'm sure of what I'm doing.

GC> And now I read about 'git checkout --patch', which sounds safer;

 I admit I hadn't even known about this option but now that I do know about
it, I don't see what does it do -- isn't it redundant when the path is
specified?

VZ