> All good reasons but make sure you give consideration to _why_ you
> need to identify insets. And then think long and hard about what
> happens when you add a new inset. How will that affect the code? If
> you find you are using dynamic_cast<> as a sort of switch statement or
> if..else if..e
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Anyway, besides the RTTI stuff, did you get the editor working?
Asger> Other comments?
It compiled flawlessly (but broke with rtti disabled). It seems to
work well, but you probably know much better that we do what to do
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I think that's a bad solution, because we add an extra method
Asger> to all insets. We want to minimize that. Also, I don't think
Asger> it's as clear as the dynamic_cast solution. It's not obvious
Asger> what semantics
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> So tell me: what are those wonderful things I miss about rtti?
Asger> I think RTTI gives better *compile time* type checking than
Asger> another solution. I.e. static_cast will gladly cast a void
Asger> pointer into the inse
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| What do you mean? that the InsetParagraph name should not be owned by
| the inset itself, but by some external code (meaning that the inset
| cannot print its name?)?
Yes, perhaps.
Lgb
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| (do static virtual methods exist?)
No.
for a static method the class works more like a namespace.
Lgb
> Only Asger knows for sure, but it seems to me that we could have code
> which is as readable (and as fast by being clever enough) as pure rtti
> code. This is not true in general, but should work there. Instead of
> doing
> InsetChunk * inset2 = dynamic_castinset1;
> if (inset2 !=0)
> So tell me: what are those wonderful things I miss about rtti?
I think RTTI gives better *compile time* type checking than
another solution. I.e. static_cast will gladly cast a void pointer
into the inset hierarchy at compile time, while dynamic_cast will
complain at compile time.
That's the
> The code generated with rtti on is larger even when you do not use
> rtti. If I understnad correctly, it is because new methods are added
> silently to all classes (which brings us back to tags). While this
> code is useful for the inset hierarchy, it will be a simple waste of
> resource for all
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Anyway, we will need a tag to be able to write the inset to a
Lars> file | \begin_inset InsetParagraph | | \end_inset | | This one
Lars> has better to be unique...
Lars>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Actually this kind of bloat I refuse to care about. Same goes
Lars> with "bloat" in exceptions.
Lars> If the problem could be solved more elegantly without rtti is a
Lars> completely different matter. I can certainly be persua
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Anyway, we will need a tag to be able to write the inset to a file
| \begin_inset InsetParagraph
|
| \end_inset
|
| This one has better to be unique...
Yes should this id decide the type, or should the type decide the id?
Lgb
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The code generated with rtti on is larger even when you do not use
| rtti. If I understnad correctly, it is because new methods are added
| silently to all classes (which brings us back to tags). While this
| code is useful for the inset hierarch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | |
Lars> Lars> But using dynamic_cast you also make sure about what kind
Lars> of | Lars> object you have
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> But using dynamic_cast you also make sure about what kind of
| Lars> object you have. When using tags you can have insets lying to
| Lars> you (even more important when/if
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> But using dynamic_cast you also make sure about what kind of
Lars> object you have. When using tags you can have insets lying to
Lars> you (even more important when/if we allow dynamic inclusion of
Lars> insets)
What dynamic i
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Me> If I understand correctly,
| Me> all what dynamic_cast<> does is to set the | result to NULL if
| Me> the pointer is not of the right type. Is that so?
|
| Lars> And it als
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Me> If I understand correctly,
Me> all what dynamic_cast<> does is to set the | result to NULL if
Me> the pointer is not of the right type. Is that so?
Lars> And it also performs the cast.
Sure, but in the way it is used, it seems
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Kristina Devantier <[EMAIL PROTECTED]> writes:
|
| Asger> This time, I implemented the clone and erase operations, so now
| Asger> all methods are complete, modulo bug-fixing. On top of that, I
| Asger> implemented a mini-edito
> "Asger" == Kristina Devantier <[EMAIL PROTECTED]> writes:
Asger> This time, I implemented the clone and erase operations, so now
Asger> all methods are complete, modulo bug-fixing. On top of that, I
Asger> implemented a mini-editor which you can use to test this stuff
Asger> with, without
Hi!
After finishing my last exam (succesfully :-) this semester, I had time to
work a bit more on the proposed data structure layer for the new LyX
kernel.
This time, I implemented the clone and erase operations, so now all methods
are complete, modulo bug-fixing.
On top of that, I implemented a
21 matches
Mail list logo
