Re: [patch] constify

2012-09-17 Thread Scott Kostyshak
On Sun, Sep 16, 2012 at 8:36 AM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: I do not think that the other changes in the patch are contrary to the current style. I made them with the same thought as what Richard has: I trust your decision, go on. It's in. Thanks, Scott

Re: [patch] constify

2012-09-17 Thread Scott Kostyshak
On Sun, Sep 16, 2012 at 8:36 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> I do not think that the other changes in the patch are contrary to the >> current style. I made them with the same thought as what Richard has: > > I trust your decision, go on. It's in. Thanks,

Re: [patch] constify

2012-09-16 Thread Pavel Sanda
Scott Kostyshak wrote: I do not think that the other changes in the patch are contrary to the current style. I made them with the same thought as what Richard has: I trust your decision, go on. Pavel

Re: [patch] constify

2012-09-16 Thread Pavel Sanda
Scott Kostyshak wrote: > I do not think that the other changes in the patch are contrary to the > current style. I made them with the same thought as what Richard has: I trust your decision, go on. Pavel

Re: [patch] constify

2012-09-15 Thread Scott Kostyshak
On Thu, Sep 13, 2012 at 5:57 AM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: Is the patch (attached in the first email) OK to go in? As said I don't think there is any performance profit in those cases so I would stick to the default style we use. IIRC end iterators are generally

Re: [patch] constify

2012-09-15 Thread Scott Kostyshak
On Thu, Sep 13, 2012 at 5:57 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> Is the patch (attached in the first email) OK to go in? > > As said I don't think there is any performance profit in those cases > so I would stick to the default style we use. > IIRC end iterators are

Re: [patch] constify

2012-09-13 Thread Pavel Sanda
Scott Kostyshak wrote: Is the patch (attached in the first email) OK to go in? As said I don't think there is any performance profit in those cases so I would stick to the default style we use. IIRC end iterators are generally const so such changes looks fine for others like exceptions please

Re: [patch] constify

2012-09-13 Thread Pavel Sanda
Scott Kostyshak wrote: > Is the patch (attached in the first email) OK to go in? As said I don't think there is any performance profit in those cases so I would stick to the default style we use. IIRC end iterators are generally const so such changes looks fine for others like exceptions please

Re: [patch] constify

2012-09-12 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 4:23 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: (a) the style is inconsistent This is good enough reason. I did grep sources and we indeed use const_iterator for end in most cases. (3) I've read that compilers can apply more aggressive optimizations

Re: [patch] constify

2012-09-12 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 4:23 PM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> (a) the style is inconsistent > > This is good enough reason. I did grep sources and we indeed use > const_iterator > for end in most cases. > >> (3) I've read that compilers can apply more aggressive

Re: [patch] constify

2012-09-03 Thread Richard Heck
On 09/02/2012 04:23 PM, Pavel Sanda wrote: Scott Kostyshak wrote: (3) I've read that compilers can apply more aggressive optimizations when more of the data is const. I'm not sure if this would apply here and even if it did That was my question because I don't think there is any difference

Re: [patch] constify

2012-09-03 Thread Richard Heck
On 09/02/2012 04:23 PM, Pavel Sanda wrote: Scott Kostyshak wrote: (3) I've read that compilers can apply more aggressive optimizations when more of the data is const. I'm not sure if this would apply here and even if it did That was my question because I don't think there is any difference

Re: [patch] constify

2012-09-02 Thread Pavel Sanda
Scott Kostyshak wrote: @@ -2453,7 +2453,7 @@ void GuiApplication::hideDialogs(string const name, Inset * inset) const Buffer const * GuiApplication::updateInset(Inset const * inset) const { Buffer const * buffer_ = 0; - QHashint, GuiView *::iterator end = d-views_.end(); +

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 8:47 AM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: @@ -2453,7 +2453,7 @@ void GuiApplication::hideDialogs(string const name, Inset * inset) const Buffer const * GuiApplication::updateInset(Inset const * inset) const { Buffer const * buffer_ = 0;

Re: [patch] constify

2012-09-02 Thread Pavel Sanda
Scott Kostyshak wrote: (a) the style is inconsistent This is good enough reason. I did grep sources and we indeed use const_iterator for end in most cases. (3) I've read that compilers can apply more aggressive optimizations when more of the data is const. I'm not sure if this would apply

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 4:23 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: (a) the style is inconsistent This is good enough reason. I did grep sources and we indeed use const_iterator for end in most cases. (3) I've read that compilers can apply more aggressive optimizations

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
What about an iterator object? (that is, I'm no longer asking about iterator vs. const_iterator but now const_iterator vs. const iterator const) Never mind, your previous comment applies to this as well: The fact that end is not modified anywhere in the loop will be quickly discovered by

Re: [patch] constify

2012-09-02 Thread Pavel Sanda
Scott Kostyshak wrote: > @@ -2453,7 +2453,7 @@ void GuiApplication::hideDialogs(string const & name, > Inset * inset) const > Buffer const * GuiApplication::updateInset(Inset const * inset) const > { > Buffer const * buffer_ = 0; > - QHash::iterator end =

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 8:47 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> @@ -2453,7 +2453,7 @@ void GuiApplication::hideDialogs(string const & name, >> Inset * inset) const >> Buffer const * GuiApplication::updateInset(Inset const * inset) const >> { >> Buffer const

Re: [patch] constify

2012-09-02 Thread Pavel Sanda
Scott Kostyshak wrote: > (a) the style is inconsistent This is good enough reason. I did grep sources and we indeed use const_iterator for end in most cases. > (3) I've read that compilers can apply more aggressive optimizations when more > of the data is const. I'm not sure if this would apply

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
On Sun, Sep 2, 2012 at 4:23 PM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> (a) the style is inconsistent > > This is good enough reason. I did grep sources and we indeed use > const_iterator > for end in most cases. > >> (3) I've read that compilers can apply more aggressive

Re: [patch] constify

2012-09-02 Thread Scott Kostyshak
> What about an iterator object? (that is, I'm no longer asking about > "iterator vs. const_iterator" but now "const_iterator" vs. "const > iterator const") Never mind, your previous comment applies to this as well: >> The fact that end is not modified anywhere in the loop will be quickly >>

[patch] constify

2012-09-01 Thread Scott Kostyshak
The attached patch does some constifying that has been hanging around. Scott diff --git a/src/Buffer.cpp b/src/Buffer.cpp index cb856b0..5386520 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -1391,7 +1391,7 @@ bool Buffer::makeLaTeXFile(FileName const fname, ofdocstream ofs;

[patch] constify

2012-09-01 Thread Scott Kostyshak
The attached patch does some constifying that has been hanging around. Scott diff --git a/src/Buffer.cpp b/src/Buffer.cpp index cb856b0..5386520 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -1391,7 +1391,7 @@ bool Buffer::makeLaTeXFile(FileName const & fname, ofdocstream ofs;