[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] New clang errors fixes
From: |
Greg Chicares |
Subject: |
Re: [lmi] New clang errors fixes |
Date: |
Wed, 27 Sep 2017 11:13:29 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 2017-09-26 21:10, Vadim Zeitlin wrote:
> On Tue, 26 Sep 2017 17:02:58 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> On 2017-09-17 17:35, Vadim Zeitlin wrote:
[...]
> GC> As for std::auto_ptr<>, I guess we're stuck with it as long as we depend
> GC> on boost headers that use it. We could insert pragmata into our code
> GC> directly wherever needed, as is done here.
> GC>
> https://github.com/vadz/lmi/pull/59/commits/f799027a247dbd30e8eddf3e9d5804e7b8064c4d
> GC> or...
> GC>
> GC> > Alternatively, we could have a wrapper header for boost/regex.hpp, but
> this
> GC> > doesn't seem useful from a long term perspective as we know that we will
> GC> > replace it with std::regex sooner or later
> GC>
> GC> I like that idea. That we'll eventually replace it strikes me as an
> GC> argument in favor of this approach: it comes with its own disposal bag,
> GC> as it were, so that we can more easily and cleanly discard it later
> GC> instead of spending energy to find and remove every pragma.
>
> OK, I'll do this then. But, for completeness, another possibility, which
> is a slightly less awful way of doing this:
>
> GC> BTW, I also considered:
> GC> #define auto_ptr unique_ptr
> GC> but it's hard to guess what risks that might entail.
>
> would be to just replace auto_ptr with unique_ptr in the Boost headers we
> use. It's not like we're ever going to update them anyhow...
Can you readily say which occurrence(s) clang objects to? There are
quite a few:
/opt/lmi/third_party/src/boost/boost[0]$grep --directories=recurse auto_ptr *
|wc -l
101
and I can start narrowing them down this way, for example:
/opt/lmi/third_party/src/boost/boost[0]$grep --directories=recurse -w auto_ptr
* |wc -l
94
but a global search and replace may introduce new problems, while
it seems likely that only a small number of lines really need to be
changed.
- [lmi] New clang errors fixes, Vadim Zeitlin, 2017/09/17
- Re: [lmi] New clang errors fixes, Greg Chicares, 2017/09/26
- Re: [lmi] New clang errors fixes,
Greg Chicares <=
- Re: [lmi] New clang errors fixes, Vadim Zeitlin, 2017/09/27
- [lmi] Enabling '-Wshadow' [Was: New clang errors fixes], Greg Chicares, 2017/09/27
- Re: [lmi] Enabling '-Wshadow' [Was: New clang errors fixes], Greg Chicares, 2017/09/28
- Re: [lmi] Enabling '-Wshadow', Vadim Zeitlin, 2017/09/28