Конструктор string_view от пары указателей

dmitriy@izvolov.ru
dmitriy@izvolov.ru

Собственно предложение тривиальное:

constexpr basic_string_view(const CharT* b, const CharT* e);

По удачному стечению обстоятельств итераторы std::string_view также являются указателями на символ, так что они автоматически подпадают под этот случай.

Возможно, ещё не помешал бы конструктор от итераторов std::string, но тут я уже не уверен.

 

С точки зрения теории пара указателей всегда взаимозаменяема с указателем и размером, но с точки зрения практического кода бывает удобнее, поэтому я считаю, что нужны оба варианта.

Возьмём простой пример:

#include <iostream>
#include <string_view>
#include <vector>

#include <boost/algorithm/string/split.hpp>

int main ()
{
    std::string_view view("qwe;rty");

    std::vector<std::string_view> tokens;
    boost::split(tokens, view, [] (auto c) {return c == ';';});

    for (auto x: tokens)
    {
        std::cout << x << std::endl;
    }
}

К сожалению, он не компилируется:

/usr/local/include/boost/range/iterator_range_core.hpp:873:55: error: invalid conversion from ‘boost::range_detail::extract_const_iterator<boost::iterator_range<const char*>, true>::type {aka const char*}’ to ‘std::basic_string_view<char>::size_type {aka long unsigned int}’ [-fpermissive]
             return SeqT( boost::begin( r ), boost::end( r ) );
                                             ~~~~~~~~~~^~~~~

Если же вышеуказанный конструктор добавить, то всё прекрасно компилируется и работает.

3
рейтинг
8 комментариев
yndx-antoshkka
Идея в принципе хорошая, но надо её сильно доработать:
* итераторы basic_string_view могут быть чем угодно, не только указателями. Поэтому такая сигнатура может работать на одной стандартной библиотеке и не работать на другой. Такое поведение недопустимо
* Если заменить пару указателей на пару итераторов, то наталкиваемся на старую проблему - в стандартной библиотеке нет категории итераторов которая говорит, что данные располагаются в памяти последовательно. Получается, что можно будет случайно создать string_view от std::deque<char> и схлопотать неприятностей
* Если добавить множество сигнатур, для итераторов std::string, std::vector, std::array, то получается плохо масштабируемое решение, не работающее с пользовательскими контейнерами

Нужно придумать как обойти все выше озвученные проблемы
yndx-antoshkka
Antervis
yndx-antoshkka, "в стандартной библиотеке нет категории итераторов которая говорит, что данные располагаются в памяти последовательно" - а как же RandomAccessIterator?
Antervis
dmitriy@izvolov.ru
yndx-antoshkka, можем ли мы декомпозировать проблему на две части:
1. Конструктор с указателями;
2. Конструктор с итераторами?

Насчёт первого из них всё выглядит так, как будто его просто забыли добавить. Я имею в виду, что он нужен независимо от варианта с итераторами.
Со вторым действительно всё сложнее. А работы над подобной категорией итераторов в принципе уже ведутся?
dmitriy@izvolov.ru
dmitriy@izvolov.ru
Antervis, итератор деки является произвольным.
dmitriy@izvolov.ru
Antervis
dmitriy@izvolov.ru, я вас понял. Однако, подходящая категория итераторов все-таки существует: ContiguousIterator. В motivation части его propolsal'а даже указано, что он нужен для реализации string_view от пары итераторов:
open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf
Antervis
dmitriy@izvolov.ru
Antervis, действительно, спасибо за уточнение.
Возможно, Антон имел в виду, что невозможно на этапе компиляции проверить, что итератор непрерывный. В предложении действительно упоминается contiguous_iterator_tag, но в текущем черновике стандарта я его не вижу.
dmitriy@izvolov.ru
zamazan4ik@tut.by
dmitriy@izvolov.ru, его в Стандарт ещё не включили ведь, эту категорию итераторов.
zamazan4ik@tut.by
dmitriy@izvolov.ru
zamazan4ik@tut.by, и не включат, как я понял. Вот тут нашёл объяснение: stackoverflow.com/questions/42851957/contiguous-iterator-detection

Так что надо ждать концептов.
dmitriy@izvolov.ru
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).