У меня есть проект, в котором я передаю данные между клиентом и сервером с помощью сокетов boost.asio. Как только одна сторона соединения получает данные, она преобразует их в std::vector
из std::string
s, который затем передается объекту фактического получателя данных через ранее определенные функции «обратного вызова». Этот способ пока работает отлично, только я сейчас использую такие методы, как atoi()
а также to_string
конвертировать другие типы данных, кроме строк, в отправляемый формат и обратно. Этот метод, конечно, немного расточителен с точки зрения использования сети (особенно при передаче больших объемов данных, чем просто одиночные целые числа и числа с плавающей запятой). Поэтому я хотел бы сериализовать и десериализовать данные. Поскольку фактически любой метод сериализации будет производить байтовый массив или буфер, мне было бы удобно просто использовать std::string
вместо. Есть ли какой-либо недостаток для этого? Я бы не понял, почему должен быть один раз, поскольку строки должны быть не более чем байтовыми массивами.
С точки зрения функциональности, нет никакой разницы.
Однако, как из соображений производительности, так и из соображений ясности кода, я бы рекомендовал использовать std::vector<uint8_t>
вместо этого, поскольку это делает намного более понятным для любого, поддерживающего код, что это последовательность байтов, а не строка.
Вы должны использовать std::string
когда вы работаете со строками, когда вы работаете с двоичным блобом, вам лучше работать с std::vector<uint8_t>
, Там много преимуществ:
ваше намерение ясно, поэтому код менее подвержен ошибкам
вы не передадите свой двоичный буфер как строку в функцию, которая ожидает std::string
по ошибке
Вы можете переопределить std::ostream<<()
для этого типа печатать BLOB-объекты в правильном формате (обычно это шестнадцатеричный дамп). Очень маловероятно, что вы захотите напечатать двоичный блоб в виде строки.
могло быть больше. Только выгода std::string
что я вижу, что вам не нужно делать typedef.
Ты прав. Строки — это не более чем байтовые массивы. std::string
это просто удобный способ управления буферным массивом, который представляет строку. Это оно!
Там нет недостатка в использовании std::string
если вы не работаете над чем-то ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО критичным по производительности, например, над ядром … затем работаете с std::string
будет иметь значительные накладные расходы. Кроме того, не стесняйтесь использовать его.
—
std::string
За кулисами необходимо выполнить несколько проверок состояния строки, чтобы решить, будет ли она использовать оптимизацию с малыми строками или нет. Сегодня почти все компиляторы реализуют небольшие строковые оптимизации. Все они используют разные методы, но в основном необходимо проверить битовые флаги, которые скажут, будет ли строка создана в стеке или куче. Это накладные расходы не существует, если вы используете прямо char[]
, Но опять же, если вы не работаете над чем-то ДЕЙСТВИТЕЛЬНО критическим, например, над ядром, вы ничего не заметите и std::string
гораздо удобнее.
Опять же, это всего лишь ОДНА из вещей, которые происходят под капотом, просто в качестве примера, чтобы показать разницу между ними.
В зависимости от того, как часто вы запускаете сетевые сообщения, std::string
все должно быть в порядке. Это удобный класс, который обрабатывает много char
работать на тебя. Если у вас есть много данных для продвижения, возможно, стоит использовать char
прямой массив и преобразование его в байты, просто чтобы минимизировать дополнительные издержки std::string
есть.
Изменить: если бы кто-то мог прокомментировать и указать, почему вы считаете мой ответ плохим, это было бы здорово и помогло бы мне учиться тоже.