- 1
- 2
- 3
- 4
string buf;
...
char c_buf[MAX_LEN];
strncpy(c_buf, buf.c_str(), MAX_LEN);-
C++ / Говнокод #3190
+144
в чём ошибка?
Запостил:
skor4ik,
10 Мая 2010
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
?а переполнения действительно не будет
код strncpy(c_buf, buf.c_str(), MAX_LEN - 1); тоже не верный
почему? в этом и есть загадка
char c_buf[MAX_LEN + 1];
strncpy(c_buf, buf.c_str(), MAX_LEN);
c_buf[MAX_LEN] = 0;
cbuf := buf;
Нормально там все.
нужно использовать memcpy
http://www.cplusplus.com/reference/string/string/c_str/
вот код для примера:
string s("qwerty");
s[3]='\0';
printf("%s\n", s.c_str());
cout << s << endl;
cout << "s size:"<<s.size() << endl;
null-байт не является концом строки, c_str() просто возвращает указатель на начало буфера, гарантируя ноль в конце, а не на си-строку.
> Generates a null-terminated sequence of characters
Привет :)
зы: Надеюсь не сильно ошибся, сделав предположение относительно самых часто используемых вами языков. :)
> string::c_str
> Generates a null-terminated sequence of characters
Строка заканчивается нулём. Там не написано, что посреди строки не может быть null символа. Если не написано, то он может, взависимости от того, что поместили в std::string.
По уму надо кодировать в utf8. А нахрена у utf8 нули посередине, я не знаю.
Только вот говнокодом будет не использование strncpy, а вставка этого нуля.
Но если дело тупо в этих трех строчках, то надо так:
string buf;
...
char c_buf[MAX_LEN];
strncpy(c_buf, buf.c_str(), MAX_LEN-1);
c_buf[MAX_LEN-1]='\0';
Самое страшное, что тут может случиться это усечение строки. Но для того strncpy() и придумана.
Если говорить о теме наличия нулей в string'е, то сам дурак, если зная это копируешь в С-строку.
не в С-строку, а в неконстантный буффер, а буфферы используются постоянно =)
>Самое страшное, что тут может случиться это усечение строки. Но для того strncpy() и придумана.
верно, оно и случается, суть в том, что для копирования буффера из std::string в буффер си нужно использовать memcpy вместо strncpy, но большинство новичков не задумываясь используют strncpy, так как думают, что string содержит null-байт только на конце.
уже хорошо, а чем плохо использовать std::string для хранения буфера?
Говнокод там, где использовали strncpy - строковые функции, не предназначенные для бинарных данных.
Чтобы не вводить в заблуждение читающего код хотя бы. А если будете использовать другой тип символа в std::basic_string, то надо еще char_traits для него определить. А оно вам надо?
Про шурупы забитые молотками я думаю говорить не стоит.
>Чтобы не вводить в заблуждение читающего код хотя бы.
достаточно написать комментарий, что здесь стринг используется для хранения буффера (под буффером я тут понимаю массив байтов)
Для копирования области памяти в С++ следует использовать memcpy и не задумываться о каких-то там нулях, так как размер буфера памяти хранится где-то сугубо отдельно.
Для копирования строк в формате BSTR следует пользоваться специальными функциями, так как данные строки не являются совместимыми со строками С++.
Читать из буфера произвольные даннные в бинарном формате в строку, а потом использовать ее как строку С++, если она заведомо содержит не строковые данные, может только тупорылый мудак, который вообще ничего не понимает в программировании. Читать бинарные данные в std::string может только двоичный мудак с фимозгом рака.
зы: Нелюблю писать С++, тк очень длительно. Неужели нельзя было назвать С+. Когда Страус упал и умер, то плюс раздвоился?
Fix
Зачем программисты задумываются над ней?
Потому-что ищут наиболее оптимальный путь реализации. При этом не брезгуют выбором наиболее оптимального алгоритма. В функциональных языках алгоритм - единственное, на что влияет программист.
В свете этого программа на С++ по скорости может выиграть у программы, написанной на ФЯП.
Не могу спорить, что ФЯП программы легче распараллеливаются автоматически, но с ручной качественным распараллеливанием С++ная программа выиграет у ФЯПнутой программы.
Не могу спорить, что ФЯП программы легче писать, не задумываясь о мелочах реализации, а значит быстрее.
Это практически единственное (плюс структуры данных), что имеет значение при разработке.
>>с ручной качественным распараллеливанием С++ная программа выиграет у ФЯПнутой программы.
Действительно, зачем Ericsson Эрланг? Надо все на асме переписать. Прямо сейчас. Через 50 лет встретимся.
А вот с ручным распараллельванием и всякими SSE MMX 3DNow! можно получить приличную скорость и на пользовательской машине.
Да и программиста проще найти. Вы на ФЯП пишете для заказчиков или таких заказчиков нет?
зы На F# пишу прямо сейчас.
Да и о ФЯП в целом, но хочу их увеличить, да и пишу в на императивных языках (пока), в частности приемущественно на С++.
1)Если не такой секрет, то расскажите о каких-нибудь ваших проектах и на каком ФЯП писали? Очень интересна их область использования.
2)В F# пишите ли вы программы с графическим пользовательским интерфейсом(GUI) и удобно ли это?
3)F# позволяет экспортировать функции, что-бы пользоваться ими из неманаджет кода, например на С++?
- Летит N самолетов ... нет, N мало, возьмём M.
- Летит N самолетов ... нет, N мало, возьмём M, и оба реактивные.
ifstream fin("file.txt", ios_base::in);
stringstream stream_buf;
stream_buf << fin.rdbuf();
string buf = stream_buf.str();
теперь buf содержит бинарное содержимое файла