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,
Scott
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
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 generally const
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 gr
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 optimizations whe
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 her
> 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
>> disco
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 optimizations whe
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
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 * buffer_ = 0;
>
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 = d->views_.end();
> + QHash
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;
12 matches
Mail list logo