А
стрингвью в 20м стаyдарте выглядит как говно, по сравнения со span
А функшн реф?
Size: a a a
2020 February 25
AZ
А функшн реф?
А его нет ещё
AZ
стрингвью в 20м стаyдарте выглядит как говно, по сравнения со span
Люблю консистентность между стрингвью и спаном
AZ
Каждый раз глаза болят
АВ
логичнее слайсы делать через
operator()(from, to), конечно жеУ меня в библиотеке Intra кстати так и сделано, но в будущей версии я решил поменять всё же на метод Slice, чтобы не было путаницы с функторами.
АВ
стрингвью в 20м стаyдарте выглядит как говно, по сравнения со span
А в моей либе StringView наследуется от Span и умеет всё тоже самое. Отличие в основном только в том, что он сравнивает строки по значению, а не по ссылкам.
АК
А в моей либе StringView наследуется от Span и умеет всё тоже самое. Отличие в основном только в том, что он сравнивает строки по значению, а не по ссылкам.
Только тут косяк - он наследуется от Span<char>, а должен от Span<const char>
АК
А в моей либе StringView наследуется от Span и умеет всё тоже самое. Отличие в основном только в том, что он сравнивает строки по значению, а не по ссылкам.
Да и "отличие" звучит как лютый архитектурный косяк
АВ
У меня бывает неконстантный StringView, а бывает константный.
typedef GenericStringView<const char> StringView;наследуется соответственно от Span<const char>.
SR
У меня бывает неконстантный StringView, а бывает константный.
typedef GenericStringView<const char> StringView;наследуется соответственно от Span<const char>.
Ебааать
SR
Вот он
SR
Std libastral
SR
Даёшь Константность в ретроградный Меркурий
АВ
Да и "отличие" звучит как лютый архитектурный косяк
А косяк в чём? Span - это когда нужно работать с ссылками на любые данные, а StringView, когда нужно работать со строками, но при этом избежать оверхеда контейнеров.
АК
А косяк в чём? Span - это когда нужно работать с ссылками на любые данные, а StringView, когда нужно работать со строками, но при этом избежать оверхеда контейнеров.
Разная семантика оператора сравнения для struct B : A {} и A
АК
А косяк в чём? Span - это когда нужно работать с ссылками на любые данные, а StringView, когда нужно работать со строками, но при этом избежать оверхеда контейнеров.
Если span<T> у меня сравнивается как указатели, я ожидаю, что
struct view : span<char> будет аналогичное поведениеАВ
Если span<T> у меня сравнивается как указатели, я ожидаю, что
struct view : span<char> будет аналогичное поведениеПросто не обращай внимания на то, что тут наследование. Я его сделал просто чтобы не реализовывать по новой те же методы. Если бы я не наследовался, а сделал это по-другому с неявными кастами, поведение бы не изменилось, просто пришлось бы больше кода писать.
std::vector ведь тоже неявно кастится к std::span и можно не заметить, как семантика поменялась.
std::vector ведь тоже неявно кастится к std::span и можно не заметить, как семантика поменялась.
АК
Просто не обращай внимания на то, что тут наследование. Я его сделал просто чтобы не реализовывать по новой те же методы. Если бы я не наследовался, а сделал это по-другому с неявными кастами, поведение бы не изменилось, просто пришлось бы больше кода писать.
std::vector ведь тоже неявно кастится к std::span и можно не заметить, как семантика поменялась.
std::vector ведь тоже неявно кастится к std::span и можно не заметить, как семантика поменялась.
я о том и говорю - из-за лени вместо композиции (нужна ли она тут вообще?) используется наследование. я бы предложил сделать общий базовый класс и от него отнаследовать span/view отдельно
да, вектор неявно кастится, но он не отнаследован от span (по крайней мере публично), поэтому не является расширением span'а
да, вектор неявно кастится, но он не отнаследован от span (по крайней мере публично), поэтому не является расширением span'а
АВ
я о том и говорю - из-за лени вместо композиции (нужна ли она тут вообще?) используется наследование. я бы предложил сделать общий базовый класс и от него отнаследовать span/view отдельно
да, вектор неявно кастится, но он не отнаследован от span (по крайней мере публично), поэтому не является расширением span'а
да, вектор неявно кастится, но он не отнаследован от span (по крайней мере публично), поэтому не является расширением span'а
Вообще я планировал переделать StringView, чтобы это был не Span, а именно коллекция символов. Чтобы независимо от формата хранения это был рендж элементов типа char32_t, даже если под капотом UTF-8 или UTF-16. Так что скорее это и будет композиция.
TS
Вообще я планировал переделать StringView, чтобы это был не Span, а именно коллекция символов. Чтобы независимо от формата хранения это был рендж элементов типа char32_t, даже если под капотом UTF-8 или UTF-16. Так что скорее это и будет композиция.
у тебя нет стримов?