lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Switch to using C++11 uniform initialization in the ctor initi


From: Greg Chicares
Subject: Re: [lmi] Switch to using C++11 uniform initialization in the ctor initializer lists?
Date: Tue, 28 Aug 2018 11:58:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-08-25 17:41, Vadim Zeitlin wrote:
> On Fri, 24 Aug 2018 01:15:42 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-08-24 00:23, Vadim Zeitlin wrote:
> GC> [...]
> GC> >         https://github.com/vadz/lmi/compare/uniform-init?expand=1
> GC> > 
> GC> >  With these changes the code compiles and the unit tests pass. I've also
> GC> > manually looked at all occurrences of vector-typed members followed by 
> "{"
> GC> > (actually " *{") in the code and confirmed that they were correct (i.e.
> GC> > used either default or copy ctors) and that () were used for everything
> GC> > else. But, again, I could have missed something, so I plan on redoing 
> this
> GC> > tomorrow -- unless you beat me to it. 
> 
>  Hello again,
> 
>  Finally I didn't redo it, but I think I did all I reasonably could to
> ensure that these changes don't introduce any problems, so I'd like to ask
> you to merge the uniform-init branch, with its single commit, from Github.

Comparing these two branches:
  odd/uniform_i12n    [mine]
  xanadu/uniform-init [yours]
I see 112 files changed, of which only 34 differ when whitespace is ignored.

In 'tier_view_editor.hpp', I now think your version is better here:

inline tier_entity_adapter::tier_entity_adapter
    (std::vector<double>& limits
    ,std::vector<double>& values
    )
    :limits_ (&limits)
    ,values_ (&values)

because that code just initializes a member with a (non-const) reference
of the same type.

I don't understand these files well enough to modify them extensively:
  database_view_editor.cpp
  multidimgrid*.?pp

Other than that, there are a few places where I used '{}' whereas you
didn't; many places where I used '()' for constructor arguments; and
some whitespace changes. None of these discrepancies affects correctness.

Therefore, if you're highly confident that the changes you've made to the
product-editor code are all correct, I'm willing to cherry-pick and push
your xanadu/uniform-init branch now...

>  I'd like to avoid doing white-space changes in the initializer list right
> now as it risks conflicting with my other changes, so I'd prefer to commit
> this one first, so that I could rebase over it and submit the PDF
> pagination changes too, that I've finally finished (this is the good news;

...and hold my odd/uniform_i12n branch back until you've submitted those
pagination changes.

> the bad news is that I couldn't avoid the need for another wxWidgets update
> as I just couldn't do what we needed without extending wxHTML a little).
Okay. I think I should look at your very recent work on installation of
wxPdfDoc, in the hope that we can rebuilt it and wxWidgets at the same
time. We were thinking of upgrading the compiler as well, but you
mentioned in personal email that the MinGW-w64 gcc-8.x package that has
just appeared in a staging area of debian isn't as stable as you'd like,
and it hasn't even made it into debian "unstable" yet:
  https://packages.debian.org/sid/g++-mingw-w64
  Package: g++-mingw-w64 (7.3.0-18+20.3)
so I guess we should postpone any compiler upgrade.



reply via email to

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