lmi
[Top][All Lists]
Advanced

[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.



reply via email to

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