> Le 4 nov. 2019 à 21:16, Hans Åberg <haber...@telia.com> a écrit :
>
>
>> On 4 Nov 2019, at 18:12, Akim Demaille <a...@lrde.epita.fr> wrote:
>>
>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez <matthew.fernan...@gmail.com> a
>>> écrit :
>>>
>>> The std::less implementation you suggest is to also lexicographically
>>> compare the filenames themselves? I’m not sure this makes sense, because
>>> source positions from two different files aren’t really orderable at all.
>>
>> The point of defining std::less is to have an easy means to insert positions
>> in a sorted container, say std::map. Now, the order in itself is well
>> defined, but my not reflect the order the user would like to see.
>>
>> To be clear: I don't have a problem with std::less which I see as an
>> implementation detail, but operators such as <= and the like are different:
>> they express a total
(I meant "natural" here).
>> order that we can't implement easily.
>
> The total order is expressed via std::less in containers such as std::map,
> with undefined results if not fulfilling the specs for that.
Yes, but that's not my point. I mean: it is not important std::less "means"
something natural, what matters is only that it's total and well-defined
(unless, of course, you make this order visible to the user). So I wouldn't
mind defining std::less for position and locations.
But operator<= is expected to mean something natural (in addition to well
defined and total). So I would not define such an operator (except with a
global offset/counter).
>> In addition, think of C where you also have main.c that #include "foo.h"
>> somewhere, which results in main.c:1 (i.e., line 1) < foo.h:1 < ... <
>> foo.h:42 < ... < main.c:3.
>
> Here the files are stacked, and if the nested files are closed after being
> read, the location pointers are dead.
W00t? Typical parsers generate ASTs and typical ASTs are decorated with
locations.
