Richard Heck wrote: > In fact, the dangling pointer is harmless, since the empty paragraph to > which it is attached almost immediately disappears when we paste the new > content. So we don't really need to reset the paragraphs: We never do > anything with them.
Valgrind would not complain if we really would not do anything with them: The previously dangling layout pointers are used in pasteSelectionHelper() (pars[pit].layout() and pars[pit].getMaxDepthAfter()). > That makes me wonder if the following would not also > silence valgrind with less work: > > DocumentClassConstPtr olddc = buffer->params().documentClassPtr(); > > Then the document class will hang around until olddc goes out of scope > at the end of the routine. That would prevent the dangling pointers as well, but I prefer the other solution, since in this case the used layouts would not be the ones from the current document class. > Another possibility, which would get rid of setDocumentClass, would be > to allow cloneBufferOnly() to take an optional DocumentClassConstPtr > object, and to set the document class when we do the clone if it is > given. Then we do not make a new DocumentClass only immediately to > destory it. Indeed. For the time being I did not want too many changes, one thing we also need to take care of eventually is the missing thread-safety of the static buffer cloning. One thing I always wanted to do is to profile the performance gain of the static buffer: Maybe we can get the same performance by some other optimizations? This would be my preferred solution, if we did not need to use a static buffer then we can easily create a new one from a DocumentClassConstPtr. Georg
