Abdelrazak Younes wrote:
Bo Peng wrote:
This makes the use of layout pointers seem kind of fragile. Maybe we
should just store the name of the layout instead, and then use
TextClass::operator[] to find the layout when we need it. There may
be other
benefits to doing it that way, too.
If there's no performance problem, that sounds good. But only if the
changes
are safe and not too intrusive.
The performance impact will be big because this layout pointer is used
everywhere. Even storing layout index is better than storing their
names.
Using names would mean a map or a hash table (better) instead of a
vector (which could lead to index based access). Maybe the perfomance
impact would not be that big... one has to try.
Yes, I'm not at all sure how often we actually need to access a
paragraph's layout. And I thought about converting LayoutList to a
map<string> a while ago, but didn't do it. And index-based access is
also worth a thought, too. That would be OK, as long as we only ever
expanded the list of layouts at the end.
But this would not be unintrusive now, I don't think.
Anyway, my guess is that if layout pointers are used directly, using
list<Layout> or deque<Layout> should not cause significant performance
problem. JMarc may know more about this LayoutList stuff.
The expert nowadays is Richard ;-)
I don't have any problem with the list idea. As I said, the worry was
just that pointers are starting to seem fragile. We've always used
pointers, or something of the sort, I think, but maybe there is a better
way. But certainly the (mislabeled) LayoutList (which has also been
around forever, in one form or another) was never intended to be
dynamic, and that's the root of the problem.
rh
