[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further C++ operators for position
From: |
Hans Åberg |
Subject: |
Re: Further C++ operators for position |
Date: |
Tue, 5 Nov 2019 10:44:11 +0100 |
> On 5 Nov 2019, at 07:51, Akim Demaille <address@hidden> wrote:
>
>> Le 4 nov. 2019 à 21:16, Hans Åberg <address@hidden> a écrit :
>>
>>
>>> On 4 Nov 2019, at 18:12, Akim Demaille <address@hidden> wrote:
>>>
>>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez <address@hidden> 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.
The point of implementing it would in use of containers like std::map, which
will assume that std::less can be to define a total order.
> 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).
It is only in C++ they are expected to relate to a total order, common use in
partially ordered sets [1]. In fact, I defined a type “order” with values
unordered, less, equal, greater, and it can be used to define a partial order.
1. https://en.wikipedia.org/wiki/Partially_ordered_set
>>> 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.
Only that when open an included file, one may use yyin = new
std::ifstream(str), where all data, buffers and locations are stacked. Then
after the file has been read, it is closed and the yyin pointer is deallocated.
- Re: Further C++ operators for position, (continued)
- Re: Further C++ operators for position, Akim Demaille, 2019/11/04
- Re: Further C++ operators for position, Christian Schoenebeck, 2019/11/04
- Re: Further C++ operators for position, Matthew Fernandez, 2019/11/04
- Re: Further C++ operators for position, Akim Demaille, 2019/11/04
- Re: Further C++ operators for position, Hans Åberg, 2019/11/04
- Re: Further C++ operators for position, Matthew Fernandez, 2019/11/04
- Re: Further C++ operators for position, Akim Demaille, 2019/11/05
- Re: Further C++ operators for position, Matthew Fernandez, 2019/11/05
- Re: Further C++ operators for position, Akim Demaille, 2019/11/05
- Re: Further C++ operators for position, Akim Demaille, 2019/11/05
- Re: Further C++ operators for position,
Hans Åberg <=
Re: Further C++ operators for position, Hans Åberg, 2019/11/04