Displaying 6 results from an estimated 6 matches for "iterator_facade_base".
2017 Jun 04
4
Should we split llvm Support and ADT?
Fair enough, i sort of regret mentioning that specific method of splitting
originally.
For the record, i think any splitting should make sense on its own merit
without considering tablegen, and hopefully the end result of "tablegen
eventually depends on less stuff" would happen naturally
On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote:
>
> >
2017 Jul 06
2
Should we split llvm Support and ADT?
...ef, ArrayRef, and various other things like STLExtras and iterator.h basically can be summarized as "things that are either already already planned for, or wouldn't be entirely out of place in the STL itself". For example, StringRef is std::string_view. ArrayRef is std::array_view. iterator_facade_base is a better version of std::iterator.
>
> So I would drop my suggestion to split the libraries in such a way that it might benefit TableGen, and instead re-word my suggestion to include only classes such as StringRef, ArrayRef, and other STL-like utilities that can benefit utilities like o...
2017 Jul 06
3
Should we split llvm Support and ADT?
...ef, ArrayRef, and various other things like STLExtras and iterator.h basically can be summarized as "things that are either already already planned for, or wouldn't be entirely out of place in the STL itself". For example, StringRef is std::string_view. ArrayRef is std::array_view. iterator_facade_base is a better version of std::iterator.
>>
>> So I would drop my suggestion to split the libraries in such a way that it might benefit TableGen, and instead re-word my suggestion to include only classes such as StringRef, ArrayRef, and other STL-like utilities that can benefit utilitie...
2017 Jul 06
2
Should we split llvm Support and ADT?
...like STLExtras and iterator.h basically can be summarized as "things that
>>> are either already already planned for, or wouldn't be entirely out of
>>> place in the STL itself". For example, StringRef is std::string_view.
>>> ArrayRef is std::array_view. iterator_facade_base is a better version of
>>> std::iterator.
>>>
>>> So I would drop my suggestion to split the libraries in such a way that
>>> it might benefit TableGen, and instead re-word my suggestion to include
>>> only classes such as StringRef, ArrayRef, and other...
2017 Jul 06
2
Should we split llvm Support and ADT?
...ator.h basically can be summarized as "things that
>>>>> are either already already planned for, or wouldn't be entirely out of
>>>>> place in the STL itself". For example, StringRef is std::string_view.
>>>>> ArrayRef is std::array_view. iterator_facade_base is a better version of
>>>>> std::iterator.
>>>>>
>>>>> So I would drop my suggestion to split the libraries in such a way
>>>>> that it might benefit TableGen, and instead re-word my suggestion to
>>>>> include only classes...
2017 Jul 06
2
Should we split llvm Support and ADT?
...summarized as "things
>>>>>>> that are either already already planned for, or wouldn't be entirely out of
>>>>>>> place in the STL itself". For example, StringRef is std::string_view.
>>>>>>> ArrayRef is std::array_view. iterator_facade_base is a better version of
>>>>>>> std::iterator.
>>>>>>>
>>>>>>> So I would drop my suggestion to split the libraries in such a way
>>>>>>> that it might benefit TableGen, and instead re-word my suggestion to
>>&...