Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> | Because we would need to re-read the textclasses (I think) and
| Lars> this | would invalidate the pointers. Am I wrong?
>
| Lars> But we are not doing that now anyway...
>
| I thought it was one of the justifications for switching from numeric
| layout to string layout. Remember that you did that because it was the
| only way to fix the problems we had with class switching, according to
| you. And now you come back to a solution which is even more fragile
| wrt class switching. Are you sure that all the relevant issues have
| been fixed? When did a miracle happen?
the ptr version is does exacly the same as the named layout version.
(except that it is safer since the layouts cannot be deleted unless
the buffer has been closed)
| Don't get me wrong: I think that having directly the layout pointer is
| great. However, I am not sure how you fixed the problems.
What problems?
| And I am not
| sure that shared_ptr have any use here.
sure it has... You cannot do it with references, bald pointers are way
to fragile.
| Normally, we delete lyxlayout
| when the class is deleted. Now, with your boost magic, we can delete
| the textclass, and some layouts will still be here, if we have a
| leak.
Yes, and we won't crash...
| Is this really something we want?
Yes... isn't it?
Now it will even be easy to put in safegueards on the textclass, we
can check if any of its layouts is in use before we delete it...
| Lars> Perhaps not... eh yes. You are not allowed to keep a LyXLayout*,
| Lars> or a LyXLayout&, both can be deleted under you and result in a
| Lars> crash.
>
| Could you give us a concrete scenario for this?
Obj * raw_obj = 0;
{ // begin scope
shared_ptr<Obj> shared_obj(new Obj);
raw_obj = shared_obj.get();
} // end scope
raw_obj->use_it(); // boom!
--
Lgb
