These uses are inefficient (a loop really) and require that pit_type
is ptrdiff_t.
Instead, RandomAccesslist::constIterator is renamed to iterator_at and
a version adding a non-const iterator is added. Additionally, the
method retirns end() when position is equal to the size of the
container (see #11861).
lyx::next and lyx::prev are removed, and std::prev is used in the few
places where the code requires it (for no good reason IMO).
These uses are inefficient (a loop really) and require that pit_type
is ptrdiff_t.
Instead, RandomAccesslist::constIterator is renamed to iterator_at and
a version adding a non-const iterator is added.
lyx::next and lyx::prev are removed, and std::prev is used in the few
places where the code requires it (for no good reason IMO).
As it was, the comparison buffer was sharing a DocumentClass with
one of the compared buffers. I don't fully understand why this was
causing a problem, since we use a shared_ptr. But this patch creates
a new DocumentClass for the new buffer.
N_() is a preprocessor macro to mark translatable static strings. It is not a
good idea to also name a class member variable N_: It did only work in the
other build configurations because gettext.h was not included.
Newer boost versions use complicated type traits for boost::next and
boost::prior, which do not work with the RandomAccessList iterators.
The long term solution is to use std::next and std::prev, for now supply
simple replacements for compilers that do not support C++11 yet.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
(P.S. Compare this to the fact that you're not supposed to refer to x and ++x in one statement.)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33137 a592a061-630c-0410-9148-cb99ea01b6c8
The feature should now be up and running, although it might have some performance issues. Please test with small changes :S as it scales quadratic with the size of a single change.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32930 a592a061-630c-0410-9148-cb99ea01b6c8
I hope I'm not reinventing the wheel too much here. This might change anyway if this appears to be a performance bottleneck.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32929 a592a061-630c-0410-9148-cb99ea01b6c8
