Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> | Don't get me wrong: I think that having directly the layout
| Lars> pointer is | great. However, I am not sure how you fixed the
| Lars> problems.
>
| Lars> What problems?
>
| The problems with class switching. Is everything safe when one changes
| the class of a document? Cuts and pastes between documents with
| different classes? I remind you again than these were the reasons why
| you said at the time that using strings was the only safe way.
I belive that I was wrong with that statement. Are now safe as well,
well, because we use the layout names when switching classes.
| Lars> Yes, and we won't crash...
>
| Which is not always the best situation. I prefer a crash as soon as
| possible, rather than data loss due to incoherent pointers.
If you get that we also had a bug with the interger and string
version...
| Lars> | Is this really something we want?
>
| Lars> Yes... isn't it? Now it will even be easy to put in safegueards
| Lars> on the textclass, we can check if any of its layouts is in use
| Lars> before we delete it...
>
| This is getting more interesting. Do you plan to do it?
This would only be a failsafe check, it should never trigger.
| Lars> | Lars> Perhaps not... eh yes. You are not allowed to keep a
| Lars> LyXLayout*, | Lars> or a LyXLayout&, both can be deleted under
| Lars> you and result in a | Lars> crash.
>>>
| Lars> | Could you give us a concrete scenario for this?
| [snip]
>
| I know that. I was asking about a concrete scenario in our use of
| _LyXLayout_. What I say is that basically they should be deleted when
| the textclass is deleted and that anything else is just crap.
True, but bald pointers are never safe. One reason is that you can
never know if the object is still there. One other option is to store
a weak_ptr in the layouts.
A weak_ptr is a companion to shared_ptr. when the shared_ptr is
deleted the pointer insed the weak_ptr is set to NULL.
--
Lgb
