- 1
- 2
- 3
- 4
n = strlen(pName);
name = new char[n + 1];
memset(name, 0, n + 1);
memcpy(name, pName, n);-
C++ / Говнокод #13914
+8
боянчик. std::string наверное религия не позволяет. а strdup() слишком С. oh wait...
Запостил:
Dummy00001,
09 Октября 2013
Follow us!
Слишком POSIX. В стандартах c/c++ такой функции нет...
А вот нахрена там memset я так и не понял... Ради зануления одного байтика в конце? :)
это прогрев выделенного буфера, чтобы новые данные в него затем быстро писались
это же неправильный способ. Все же знают, что надо прогревать белым шумом.
Ты фашист.
Вот еще полутоновый, с французским звучанием
http://higgs.rghost.ru/46926704/image.png
код в одном потоке с формой.
походу знатный баян, ему место в С разделе.
в теории memcpy должен быть ощутимо шустрее strcpy. А один проход по строке так или иначе делать придётся, чтобы посчитать длину буфера.
тагда зачем она туда впихнута, если для определенных целей есть своя функция ее и нада юзать, непойму.
memcpy в данном случае вполне адекватная замена strcpy/strncpy: мы знаем размер блока данных, который нам надо скопировать.
ну это вопрос скорее к разрабам либы.)
тормозишь? в отличии от memcpy(), strcpy()/strncpy() останавливаются на нулевом символе.
Где сдесь это используется, в этом примере, конкретно?
Ща миня ,заминусуют...
ты наехал на libc. ее никто сильно не любит, но она есть и работает.
> Ща миня ,заминусуют...
А то як жэ!
Как ни парадоксально, но strcpy/strncpy/strcat/strncat юзабельны только для буферов, размер которых задан на этапе компиляции. В противном случае длину один хрен приходится хранить или замерять, и тогда memcpy работает быстрее, да и юзать его проще.
В ненужности оного действа если мы и так знаем где он стоит. А мы знаем, т.к. длину строки или хранили или замерили.
Откуда я его знаю?
Он вбит намертво на этапе компиляции? Ну так я выше и написал, что в таких случаях эти функции имеют право на жизнь.
Я вычислил его на основе длины той строки, которую буду в него копировать (и, возможно, выделил под него память)? Ну и зачем я тогда буду замерять ее второй раз? Длина мне и так известна.
Мне похуй, что строка обрежется, лишь бы не было buffer overrun'ов и оверхеда на замер/хранение длины строк. Ну вот в этом случае strncpy прокатит.
копирование блоков памяти известного размера делается по 4/8/16/больше байт подряд - потому что на ноль проверять не надо и размер заранее известен и нет шансов случайно выйты за пределы буффера.
на современных системах, с кэшами и прочими оптимизациями на уровне CPU, народ очень очень сильно изгаляется для того что бы достичь максимального бэндвидса шины памяти - именно для чего memcpy() и оптимизируется. типичная реализация memcpy() на порядок сложнее типичной реализации strcpy().
я сравнивал memcpy() vs. strcpy(), а не strlen()+memcpy() vs. strcpy().
можно было бы как-нибудь бенчнуть, но мне лень. лично я все равно предпочитаю snprintf() для таких целей (потому что отдельно-стоящее копирование строк редко встречается).
Например храня ее рядом с самой строкой. Или как побочный эффект во время расчета длины буфера, в который будем копировать.
Т.е. strlen + malloc + memcpy vs strlen + malloc + strcpy.
Вот в этой ситуации strcpy всяко проиграет.
P.S. А strcat/strncat вообще Шмелиэль изобрел. Разве так трудно было вернуть указатель на терминатор, а не бесполезный указатель на начало буфера? ;)
Ну так strcpy для сишных строк сделали, а не для пасцалевских :)
А второй мой аргумент (как побочный эффект во время расчета длины буфера) опровергать не будем? :)
Ну а куда деваться. Либо длина ограничена во время компиляции, либо ты получишь buffer overrun (strcpy без замера), либо у тебя обрежется конец строки (strncpy без замера), либо так как ты описал (strlen + malloc + mempy), либо ты хранишь длину аля пасцаль-строка.
Ну и кто мешает юзать паскалевскую строку? Ну кроме того, что придется запилить несколько простейших функций для работы с ними. Сишка это все-таки не инструмент для прикладника, в котором все из коробки, как в том же питоне...
> В Сишке строк нет.
Угу. Есть только строковые литералы. И несколько функций по обработке массивов как строк ;)
не тру. А вообще строки нужны только на уровне view. как правило если в проге где то еще есть строки - она говно
Ты же пишешь на шарпе, изучай F#, потом и до Haskell, глядишь, доберёшься.
Польза от него в основном образовательная, море бесплатного фана и вынос мозга гарантированы. Я иногда пишу на нём небольшие одноразовые утилитки по работе. Собственно, по причине (пока ещё?) низкой потребности в Хаскеле я и предлагаю начать с F#.
:D
Я сначала тоже хотел похоже написать, но вспомнил, что на порядок вычисления аргументов полагаться нельзя.
Но ведь царь должен знать свой компилятор, поэтому волен свободно пользоваться ub по своему усмотрению.
char name = alloca(strlen(pName));
Что оно делает в emacs 23?