https://issues.apache.org/ooo/show_bug.cgi?id=124065
--- Comment #10 from Andre <[email protected]> --- (In reply to wujinlong from comment #9) > (In reply to Andre from comment #8) > > (In reply to wujinlong from comment #6) > > > Hi Andre, > > > > > > - Documenting clearly in sc/in/document.hxx that the returned ScRangeName > > > is > > > volatile, ie can change at any time. > > > > Checking that the calling code can handle this volatility is part of the > > change, right? > > > > I don't see this should be part of this fix. Two reasons, It should be if the fix changes existing behavior, and I am thinking that it does. > > 1. There is such volatility issue existing in the original code for a long > time. The original code uses Clone() to make a copy of the ScRangeName > object, and at last the cloned ScRangeName object is set back to the > Document object. OK, I agree that that takes care of the volatility issue. But if I am reading the code correctly, the cloned or modified ScRangeName is set via ScDocFunc::SetNewRangeNames(). There an undo object is created. Without cloning the ScRangeName object, it appears that the undo object references the same ScRangeName twice. This would make the undo operation useless. Any idea how to deal with that? > > The key point is there is performance issue in the code, and we are trying > to fix that by not using Clone(). I want to prevent that we make trade a speed gain for a loss of functionality. > > 2. If we use something like lock to resolve the volatility issue, it might > introduce new performance issues. And we need to do more testing to make > sure of that. > > So in summary, if you think we need to address this volatility issue more > decently, I propose to do that in a separate task. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes.
