sc/inc/tokenarray.hxx | 1 +
sc/source/core/tool/token.cxx | 6 ++++++
sc/source/filter/inc/tokstack.hxx | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
New commits:
commit 94eed3f5bb675d60239414ad2289bde7cc4d4f8e
Author: Tor Lillqvist <t...@collabora.com>
Date: Tue Mar 10 09:04:57 2015 +0200
Fix issue in re-use of ScTokenArray objects from a TokenPool
The TokenPool::operator[] is used to initialise and take into use an object
from the pool. Which is a fascinating thing as such and probably not
entirely
in good style. Anyway, the objects in the pool are of type ScTokenArray, a
class derived from FormulaTokenArray. The operator[] called the
FormulaTokenArray::Clear() function to initialise the object. This left the
fields added in ScTokenArray uninitialised, having whatever value the
previous
use of the object had set. Which of course is bad.
In practice, this showed up in the handling of formulas in the .xls input
filter. If an earlier (or the first?) formula had happened to be one for
which
we don't want to use OpenCL, the meVectorState of its ScTokenArray object in
the pool had been set to FormulaVectorDisabled. When the same pool object
was
later re-used for another formula, it kept that same meVectorState, even if
there was no reason to. Thus formula groups that should have been OpenCL
accelerated weren't. This can have a significant impact on performance of
document loading and recalculation for large documents.
I added a function to ScTokenArray to clear (initialise) such an object,
both
the FormulaTokenArray part and the ScTokenArray-specific part, and call that
instead. This fixes the issue.
I named the added function ClearScTokenArray() to make it clear that it is a
separate function. Sure, possibly Clear() should be made into a virtual of
FormulaTokenArry and overridden in ScTokenArray, and the overriding Clear()
would first call the base class's Clear(). But I can't be sure that there
aren't other calls of FormulaTokenArray::Clear() that *must* mean the base
class one. Better safe than sorry.
And of course, I did *not* want to name the function in ScTokenArray also
"Clear()", like in the base class, without it being virtual. That is
horrible
style in my opinion, even if there certainly is precedence for such even in
the very same classes, i.e. the Clone() function...
Change-Id: I0e0e13e5ca705603005a1e0a46866f095cd2ac4d
Reviewed-on: https://gerrit.libreoffice.org/14824
Reviewed-by: Michael Meeks <michael.me...@collabora.com>
Tested-by: Markus Mohrhard <markus.mohrh...@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrh...@googlemail.com>
diff --git a/sc/inc/tokenarray.hxx b/sc/inc/tokenarray.hxx
index 54f1d1e..cd32952 100644
--- a/sc/inc/tokenarray.hxx
+++ b/sc/inc/tokenarray.hxx
@@ -57,6 +57,7 @@ public:
/// Assignment with references to FormulaToken entries (not copied!)
ScTokenArray( const ScTokenArray& );
virtual ~ScTokenArray();
+ void ClearScTokenArray();
ScTokenArray* Clone() const; /// True copy!
// An estimate of the number of cells referenced by the token array
diff --git a/sc/source/core/tool/token.cxx b/sc/source/core/tool/token.cxx
index 7710f30..1d2a0a6 100644
--- a/sc/source/core/tool/token.cxx
+++ b/sc/source/core/tool/token.cxx
@@ -1595,6 +1595,12 @@ ScTokenArray& ScTokenArray::operator=( const
ScTokenArray& rArr )
return *this;
}
+void ScTokenArray::ClearScTokenArray()
+{
+ Clear();
+ meVectorState = FormulaVectorEnabled;
+}
+
ScTokenArray* ScTokenArray::Clone() const
{
ScTokenArray* p = new ScTokenArray();
diff --git a/sc/source/filter/inc/tokstack.hxx
b/sc/source/filter/inc/tokstack.hxx
index 9bf137d..63b5e7b 100644
--- a/sc/source/filter/inc/tokstack.hxx
+++ b/sc/source/filter/inc/tokstack.hxx
@@ -362,7 +362,7 @@ inline const TokenId TokenPool::LastId( void ) const
const inline ScTokenArray* TokenPool::operator []( const TokenId nId )
{
- pScToken->Clear();
+ pScToken->ClearScTokenArray();
if( nId )
{//...only if nId > 0!
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
