lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Removing empty messages from static_assert()


From: Greg Chicares
Subject: Re: [lmi] Removing empty messages from static_assert()
Date: Fri, 9 Feb 2018 23:12:52 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 2018-02-09 22:17, Vadim Zeitlin wrote:
> On Fri, 9 Feb 2018 21:04:09 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-02-09 19:52, Greg Chicares wrote:
> GC> > On 2018-02-09 16:36, Vadim Zeitlin wrote:
> GC> > [...]
> GC> >>  Would you mind if I submitted a trivial patch removing all of these ""
> GC> >> from static_assert?
> GC> 
> GC> [...] I'll apply it when I see it.
> 
>  Thanks, here is the PR with the (as announced, trivial, changes):
> 
>       https://github.com/vadz/lmi/pull/66
> 
> I've only tested its compilation (with MinGW and MSVS 2017 too) because
> it's really not supposed to have any run-time effects.

I did this, because it was so easy to do:

/opt/lmi/src/lmi[0]$for z in `grep --files-with-match static_assert *.?pp`; do 
<$z >../stash/$z sed -e '/static_assert/s/, "");/);/' ; done         

[where 'stash/' is a physical directory, not something built into git]

and everything matched except (of course) the multiline instances.
My command touched 38 files vs. your PR's 37; the difference is only
'premium_tax.cpp', which had only the "terse" form already, and was
accordingly unchanged.

I'll run the usual battery of automated tests anyway, then push.

After updating your page here:
  https://github.com/vadz/lmi/pulls
four PRs will remain. Ignoring the two that are "experimental" or
"postponed" leaves only two:

18 "Census view optimizations", which is deep and requires intense
review--but I really want to merge it when I have the time.

56 "Better fix for USE_SO_ATTRIBUTES=1 build", which I took a fresh
look at the other day, just to see whether I could clear it easily.
I can't. I started re-reading our discussions here, and I'm just not
happy about exporting some classes (mc_enum and tn_range, IIRC) that
I had deliberately not exported years ago. I understand your reasons
for doing this, but many years ago I tested all of this with three
different msw compilers, and all of them accepted everything the
way it is; I take that as strong evidence that these changes are
not needed. Maybe someday I'll try building for something-linux-gnu
and that'll convince me that this has been wrong all these years;
I'll postpone this PR until then.

BTW, I'll try no longer to CC you on mailing-list messages, but
CC myself to increase the likelihood that I'll receive my own
messages. I could re-add the CC to you, but that's probably just
a nuisance.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]