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

[Greg Chicares]

On 2017-01-10 22:13, Vadim Zeitlin wrote:
> On Tue, 10 Jan 2017 21:50:28 +0000 Greg Chicares <address@hidden> wrote:
[...]
>  Me too. I've never used Vim from command line

The elaborate command I posted was vim abuse, but starting a session
with '--cmd', e.g.:

> GC>   vim --cmd "vim static_assert *.?pp"

seems very useful. And after doing this (suboptimally, repeating the pair
of commands with ':'-UpArrow-UpArrow-Enter):
  :%s/BOOST_STATIC_ASSERT/static_assert/gc
  :w | cnf
on every file, I realized I hadn't added a C++11-required string literal
(and that "Press Enter" prompt was annoying)...so I was glad to figure out
that I could cycle back through the same set of files and do this:
  :w | silent cNf | g/static_assert/s/);/, ""&/c
Best of all, after one '@:', I could just '@@' to repeat. However...

> GC> to make context-dependent changes like this:
> GC> 
> GC> -    // Assert that the static_cast doesn't engender undefined behavior.
> GC> -    // Double parentheses: don't parse comma as a macro parameter 
> separator.
> GC>      static_assert
> GC> -        ((
> GC> +        (
> GC>          std::is_base_of
> GC>              <MemberSymbolTable<ClassType>
> GC>              ,ClassType
> GC>              >::value
> GC> -        ));
> GC> +        );
> 
>  FWIW I'd use
> 
>       perl -0777 -i'' -pe 
> 's/BOOST_STATIC_ASSERT(\s*)\(\(([^;]+)\)\);/static_assert\1(\2);/' *.?pp

I reviewed so many regexes in 'test_coding_rules.cpp' earlier today
that it's hard to look at that. But let's see...oh, I guess plain
'(' is for grouping, and '\(' is a literal left parenthesis; with
sed, I'm used to the opposite meanings. Okay, thanks, I see. Due to
my extensive experience with sed, I tend not to automate changes
that extend across '\n' boundaries.

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

I strive always to verify global changes like this, e.g. with
  grep 'Double parentheses' *.?pp |less -S
  grep 'static_assert((' *.?pp |less -S
and indeed I left double parentheses in a couple of places that an
automated command wouldn't have missed. BTW, here's often a tidy
solution to be found at stackoverflow:

http://stackoverflow.com/questions/2084210/remove-a-pair-of-parentheses-brackets-or-braces-in-vim
|   %x``x

> for this. This even seems to work correctly. And I only had to do "git
> reset --hard HEAD" once while testing it.

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

And now I read about 'git checkout --patch', which sounds safer; but
I'm not going to experiment with that right now because I have a large,
carefully-tested static_assert changeset ready to commit.