On Tue, Dec 11, 2007 at 12:00:10AM +0100, Stefan Schimanski wrote:
>>> + /// Create lazy MacroData which only queries the macro template when
>>> needed
>>> + MacroData(Buffer const & buf, DocIterator const & pos);
>>>
>>
>> This works?
>>
> Why shouldn't it? What exactly is your doubt?
See below.
[...]
>>> +MacroData::MacroData(Buffer const & buf, DocIterator const & pos)
>>> + : buffer_(&buf), pos_(pos), queried_(false), numargs_(0),
>>> + optionals_(0), lockCount_(0), redefinition_(false),
>>> + type_(MacroTypeNewcommand)
>>> {
>>> - defaults_.resize(optionals);
>>> }
>>>
>>
>> This seems to rely for a certain time on the validity of the passed and
>> stored DocIterator. We have almost no guarantee for that, though.
>> Could you please elaborate a bit on what assumptions are made here and
>> why they will be fulfilled?
>>
> The DocIterator exists until the next Buffer::updateMacros call which
> currently happens before the next metrics calculations. So the timeframe is
> not that long.
>
> But for the case that the iterator gets invalid, the worst thing that can
> happen is that the fixIfBroken call in MacroData::updateData will chop off
> the invalid part. Then the DocIterator does not point to a math macro
> definition anymore and the MacroData returns some default values and
> complains in the console about a nasty BUG. The user will see unfolded
> macros then, but nothing is supposed to break for him.
Ok then. But add the first paragraph above as comment to the code.
>>> - /// macro table
>>> - typedef std::map<unsigned int, MacroData, std::greater<int> >
>>> PositionToMacroMap;
>>> - typedef std::map<docstring, PositionToMacroMap> NameToPositionMacroMap;
>>> - NameToPositionMacroMap macros;
>>> + /// macro tables
>>> + typedef std::pair<DocIterator, MacroData> ScopeMacro;
>>> + typedef std::map<DocIterator, ScopeMacro, std::greater<DocIterator> >
>>> PositionScopeMacroMap;
>>>
>>
>> Does this 'inverted logic' make things much clearer in the
>> implementation? If not (and I don't see it...) I'd think it'd
>> be better to stick with the default...
>>
> Later on I need the upper_bound algorithm. Logically I have to find the
> biggest element in the order below some x. The upper_bound algorithm gives
> me the smallest above x, so that's what I want with inverted order.
> The lower_bound algorithm though will give me x, if x is in the order.
> Unfortunately our order (of DocIterators) is well-founded, but there is no
> biggest element smaller than an x. So some work-around via lower_bound(x-1)
> does not work.
>
> Possibly some magic with STL's algorithms and an order functor or so might
> do what I want. If so without any performance hit, I am open to use that.
>> [...]
What about lower_bound on reverse iterators (i.e. map<>.rbegin() etc)?
Andre'
