Возникла проблема со строками. Вообщем, в KDevelop при трассировке участка кода содержащего строку неверно отображается содержимое этой строки. Пример: Код (Text): string test; cout<<test.size()<<endl; test.append("hello\0name",10); cout<<test.size()<<endl; cout<<test<<endl; При пошаговой трассировке для переменной test будет отображено значение "hello", которое не соответствует действительности. Какие есть варианты решения этой проблемы для KDevelop?
Nafanya \0 в строке с какой целью? учитывая что это обозначение конца строки, да и вообще просто убивают такие фразы.
при чем тут KDevelop? у этого автора обычно нет цели, кроме как генерировать стремный код) Код (Text): #include <iostream> #include <string> using namespace std; int main() { string test; cout << test.size() << "\n"; test.append("hello\0name", 10); cout << test.size() << "\n"; cout << test << "\n"; return 0; } компилятор MinGW: кстати такой нехилый потенциальный баг может быть из-за этого... gcc в данном случае поступает более здраво на мой взгляд)
spa В строке лежит сетевой пакет. Соответственно под \0 - подразумеваются нулевые байты сетевого пакета. При отладке KDevelop отображает пакет неправильно. cout<<variable выводит его без нулевых байтов. функцию c_str() просьба не предлагать,хоть char'овский буфер отладчик KDevelop отображает корректно, этот вариант не подходит. Есть ли другие варианты?
да это вряд ли... как ide может так код резать? не валять дурака и не использовать контейнер для нуль-терминированных строк для формирования сетевого пакета... и тем более не выводить их с помощью cout...
Мне во время отладки нужно точно знать, что записано в string, включая нуль-байты (т.к. там пакет). Буду думать дальше... Всем спасибо за советы.
Nafanya Как отметил Rel std::string предназначен для ASCIIZ строк. Вам же нужен буфер данных. Попробуйте vector<char>.
KeSqueer Разве? Мне как-то казалось, что нулем должен заканчиваться только результат c_str(). В остальных случаях ноль на конце никто (вроде бы!) не гарантирует.
Нет, string - это контейнер для объектов произвольного типа. Просто заточен под операции, характерные для строк символов. Nafanya Думаю, дело в KDevelop. Придётся подсунуть в cout свою реализацию streambuf, который бы заменял при выводе '\0' на пробел.
нет... с чего вы вообще это берете? string - контейнер для объектов типа char... Код (Text): typedef basic_string<char> string нет... при чем тут KDevelop? как IDE может влиять на это? +1
Rel Я имел в виду не конкретно std::string, а строковой шаблонный класс вообще - т.е. std::basic_string. Содержимое std::string тоже не ограничивается C-строками - это может быть произвольный набор значений типа char, включая нули. При том, что именно IDE занимается выводом того, что отлаживаемая прога пишет в cout.
Ну надо же! Всю жизнь думал, что cout по дефолту направляется в консоль операционки, а оно вон как, оказывается!
Ursus По дефолту cout направлен в STDOUT_FILENO. А уж что там под STDOUT_FILENO на самом деле -- навскидку не угадаешь. Может быть консоль, терминал, псевдотерминал, пайп, фифо, регулярный файл, сокет...
можно стандартные потоки перенаправить в пайпы и писать/читать их... в чтении из пайпа проблем не должно быть, проблема может быть к выводе текста на контрол, но это надо смотреть исходники KDevelop... если я правильно понял о чем пишет green... то есть если эти ошибки возникают в окошке KDevelop, а не в окошке консоля...
Еще есть вопрос к знатокам потоков (cin,cout). Возможно ли "секретным" флагом переключить cin на неблокируемый ввод? Например, Код (Text): string str; while(true) { cin>>str; //прочий код } - чтобы программа не блокировалась в этом месте кода в случае отсутствия данных. Как только user введет строку и нажмёт Enter, записать это дело в string (например это может случиться на тысячном пробеге цикла).
