#c #feature-detection #random-access #streambuf
#c #обнаружение функций #произвольный доступ #streambuf
Вопрос:
При написании универсальной функции, ссылающейся на an std::streambuf
, я хотел бы проверить, привязан ли предоставленный буфер к чему-либо, поддерживающему произвольный доступ, или нет, и соответствующим образом оптимизировать обработку, т. Е. Проверить, Доступно ли перемещение по потоку с pubseekpos()
помощью или нет.
Возможно, я упустил это из виду в документации. У вас случайно нет кристально чистого решения, кроме позднего обнаружения, работает оно или нет, на основе результата последнего метода (который возвращается -1
в случае неудачи поиска, что может иметь другие причины)?
Доступные документы:
- https://www.cplusplus.com/reference/streambuf/streambuf/pubseekpos/
- https://en.cppreference.com/w/cpp/io/basic_streambuf/pubseekpos
Заранее спасибо. С уважением.
(Редактировать #GIJD после первого комментария)
Даже если я не очень рад этому, ты правильно подметил. То же самое, что «вместо того, чтобы проверять, существует ли файл перед его открытием, откройте его и обработайте error_status / exceptions» (поскольку условие гонки всегда возможно между тестом и открытием в противном случае).
Хорошо, фактический вызов функции сам по себе действительно может быть лучшим доказательством проверки наличия некоторого флага функции (который также может быть установлен неправильно, даже если маловероятно, если код был протестирован должным образом… ну, я просто прочитал то, что написал, да, хорошо, как будто код всегда должным образом тестируется… ХОРОШО, ха-ха, лучше протестировать функцию напрямую (да, да).
Но, тем не менее, возвращаемое значение -1 может означать ошибку, а не отсутствие произвольного доступа, но можно утверждать, что результат тот же, я не смогу выполнить произвольный доступ, если он завершится неудачей, независимо от причины, отсутствия функции или какой-либо ошибки. Таким образом, мне все равно придется вернуться к однопроходному чтению потока.
Спасибо. С уважением.
Комментарии:
1.
pubseekpos
вызываетvirtual seekpos()
функцию-член,. поэтому я думаю, что будет сложно придумать надежную проверку, фактически не протестировав ее.2. См. Редактирование #GIJD выше.
3. Что означает #GIJD?
4. #GIJD ничего не значит, это просто короткая случайная уникальная строка, которую вы можете искать. Своего рода ручная ссылка / ссылка на текст выше. Это способ ссылки на текст, когда у вас нет доступа к гипертексту, апогей в такой вики-подобной среде 🙂 Если есть способ, который я мог упустить из виду, мне интересно.
5. Я вижу. Такая связь здесь не используется в SO, поэтому вопрос выглядит странно с этим в нем. Комментарии также не должны содержать важную информацию о вопросе, и они иногда удаляются. Если это произойдет, это сделает эту ссылку в вопросе еще более запутанной. Я предлагаю отредактировать 🙂