On Friday 11 July 2008 19:20:34 rgheck wrote:
> Oh, OK. I guess it's just a no-op in that case?
The C++ standard requires that the compiler deals with "delete 0". I am not in
the mood to examine g++ but I would expect this to be a no-op. :-)
And while only tangentially related I found this FAQ f
Andre Poenitz wrote:
On Fri, Jul 11, 2008 at 01:19:26PM -0400, rgheck wrote:
+if (bparams)
+delete bparams;
+}
/// Which kind of operation are we recording for?
UndoKind kind;
/// the position of the cursor
Obviously, this isn't a big deal. Yours should wo
On Fri, Jul 11, 2008 at 01:19:26PM -0400, rgheck wrote:
> +if (bparams)
> +delete bparams;
> +}
> /// Which kind of operation are we recording for?
> UndoKind kind;
> /// the position of the cursor
>
> Obviously, this isn't a big deal. Yours should work. But this
On Fri, Jul 11, 2008 at 01:05:33PM -0400, rgheck wrote:
> Andre Poenitz wrote:
>>> Index: src/BufferParams.h
>>> ===
>>> --- src/BufferParams.h (revision 25523)
>>> +++ src/BufferParams.h (working copy)
>>> @@ -15,8 +15,9 @@
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
OK, I see. Well, I think it works that way, but only because
doRecordUndo() only gets called with isFullBuffer being true at
this one point in the code. If it ever got called that way from
elsewhere, you'd have a p
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
OK, I see. Well, I think it works that way, but only because
doRecordUndo() only gets called with isFullBuffer being true at
this one point in the code. If it ever got called that way from
elsewhere, you'd have a problem.
I don
rgheck wrote:
Abdelrazak Younes wrote:
OK, I see. Well, I think it works that way, but only because
doRecordUndo() only gets called with isFullBuffer being true at this
one point in the code. If it ever got called that way from
elsewhere, you'd have a problem.
I don't see this could happen b
Andre Poenitz wrote:
Index: src/BufferParams.h
===
--- src/BufferParams.h (revision 25523)
+++ src/BufferParams.h (working copy)
@@ -15,8 +15,9 @@
#ifndef BUFFERPARAMS_H
#define BUFFERPARAMS_H
+#include "Citation.h"
+#include
On Thu, Jul 10, 2008 at 03:36:03PM -0400, rgheck wrote:
> Jean-Marc Lasgouttes wrote:
>> Le 10 juil. 08 à 18:42, rgheck a écrit :
>>> Well, here's a patch I suggested previously. JMarc thought it might be
>>> better to use a shared_ptr here. I have no strong views. You?
>>
>> I do not think buffer
Abdelrazak Younes wrote:
OK, I see. Well, I think it works that way, but only because
doRecordUndo() only gets called with isFullBuffer being true at this
one point in the code. If it ever got called that way from elsewhere,
you'd have a problem.
I don't see this could happen but we should ma
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params(
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing de
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere,
Jean-Marc Lasgouttes wrote:
Le 10 juil. 08 à 18:42, rgheck a écrit :
Well, here's a patch I suggested previously. JMarc thought it might
be better to use a shared_ptr here. I have no strong views. You?
I do not think bufferparams has been considered a problem with undo
until recently. The pro
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere, shouldn't it?
Well, h
Abdelrazak Younes wrote:
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere, shouldn't it?
Well, here's a patch I
On Thu, Jul 10, 2008 at 06:24:29PM +0200, Abdelrazak Younes wrote:
>> No, that's how the MathData and the ParagrapghList are handled, too.
>> Just delete them when the UndoElement is dropped from the stack.
>
> OK, I'll do that later if you don't beat me at it. Have to go pick up my
> daughter...
rgheck wrote:
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere, shouldn't it?
Well, here's a patch I suggested previously. JMa
Andre Poenitz wrote:
On Thu, Jul 10, 2008 at 06:19:06PM +0200, Abdelrazak Younes wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere, shouldn't
Le 10 juil. 08 à 18:42, rgheck a écrit :
Well, here's a patch I suggested previously. JMarc thought it might
be better to use a shared_ptr here. I have no strong views. You?
I do not think bufferparams has been considered a problem with undo
until recently. The problem IMO is with
the docume
Andre Poenitz wrote:
But if the idea is to store the params _because they change_,
that should be a copy, i.e.
otherstack.top().bparams = new BufferParams(buffer_.params())
with a corresponing delete somewhere, shouldn't it?
Well, here's a patch I suggested previously. JMarc thought it m
Abdelrazak Younes wrote:
rgheck wrote:
rgheck wrote:
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
Actually, never mind. We can't do it that way. The whole point here
is that the BufferParams could change,
Andre Poenitz wrote:
On Thu, Jul 10, 2008 at 06:19:06PM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Thu, Jul 10, 2008 at 06:09:28PM +0200, Abdelrazak Younes wrote:
Index: src/Undo.cpp
===
--- src/Undo
On Thu, Jul 10, 2008 at 06:19:06PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> On Thu, Jul 10, 2008 at 06:09:28PM +0200, Abdelrazak Younes wrote:
>>
>>> Index: src/Undo.cpp
>>> ===
>>> --- src/Undo.cpp(revision 255
Andre Poenitz wrote:
On Thu, Jul 10, 2008 at 06:09:28PM +0200, Abdelrazak Younes wrote:
Index: src/Undo.cpp
===
--- src/Undo.cpp(revision 25531)
+++ src/Undo.cpp(working copy)
@@ -73,7 +73,7 @@
MathD
rgheck wrote:
rgheck wrote:
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
Actually, never mind. We can't do it that way. The whole point here is
that the BufferParams could change, and we want a copy of how
On Thu, Jul 10, 2008 at 06:09:28PM +0200, Abdelrazak Younes wrote:
> Index: src/Undo.cpp
> ===
> --- src/Undo.cpp (revision 25531)
> +++ src/Undo.cpp (working copy)
> @@ -73,7 +73,7 @@
> MathData * ar, Buffe
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 06:43:53PM -0400, rgheck wrote:
/// Only used in case of full backups
-BufferParams bparams;
+BufferParams & bparams;
I know it was my doing at some point of time, but can't bparams be
a plain pointer si
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 06:43:53PM -0400, rgheck wrote:
/// Only used in case of full backups
- BufferParams bparams;
+ BufferParams & bparams;
I know it was my doing at some point of time, but can't bparams be
a plain pointer similar to the Mat
On Wed, Jul 09, 2008 at 06:43:53PM -0400, rgheck wrote:
>
> Does this seem worth doing? It does save the construction of a BufferParams
> for every undo, and Abdel seems to think it's safe
>
> rh
>
>
> Index: Undo.cpp
> ===
> ---
rgheck wrote:
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
Actually, never mind. We can't do it that way. The whole point here is
that the BufferParams could change, and we want a copy of how they were
whe
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
rh
Index: Undo.cpp
===
--- Undo.cpp (revision 25523)
+++ Undo.cpp (working copy)
@@ -70,11 +70,25
33 matches
Mail list logo
