Может есть какая-нибудь общепринятая либа?

strcat/sptrinf это как бы и есть общепринятая либа, стандарт.

молись_чтобы_хватило

Зачем? Можно посчитать, сколько конкретно нужно.

https://developer.gnome.org/glib/stable/glib-Strings.html

Первый - создать char buf[молись_чтобы_хватило]

strlen

как вы склеиваете строки?

size_t sumlen = strlen(a)+strlen(b);
char *concat = malloc(sumlen);
snprintf(concat, sumlen, "%s%s", a, b);

Элементарщина же!

strcat/sptrinf это как бы и есть общепринятая либа, стандарт
Зачем? Можно посчитать, сколько конкретно нужно

Может есть какая-нибудь общепринятая либа, которая считает длину, выделяет память и склеивает? Или каждый пишет это вручную?

которая считает длину, выделяет память и склеивает?

Нет, т.к. не нужно. А тебе зачем склеивать строки если не секрет. Просто ума не приложу нахрена это понадобилось?

(да, надо еще таки не забывать проверять результат malloc'а, несмотря на здравомыслие Царя)

Или так:

size_t sumlen = strlen(a)+strlen(b);
a = realloc(sumlen);
strcat(a, b);

Элементарщина же!

Поздравляю! В трёх строках «элементарщины» ты умудрился:

• вызвать strlen четыре раза вместо двух;
• создать строку, не оканчивающуюся нулём;
• и тем самым подложить мину либо себе, либо другому.

Посчитать сумму, выделить память, проследить за выделением, склеить. И так делать каждый раз когда захочется склеить строку?

Сколько там интересного в этой глиб. Курю

Может есть какая-нибудь общепринятая либа, которая считает длину, выделяет память и склеивает? Или каждый пишет это вручную?

Обычно на Сях пишут такие программы, где управление памятью более хитрое, чем отдельный malloc на каждый чих. Поэтому «общепринятая либа» решала бы тривиальную задачу, но имела бы крайне низкую гибкость.

libstdc++

либа, которая считает длину, выделяет память и склеивает? Или каждый пишет это вручную?

Тебе три строчки влом написать что ли?

вызвать strlen четыре раза вместо двух;

Где это там 4 раза?

создать строку, не оканчивающуюся нулём;

Врешь! Где? sprintf работал и работает!

УМВР.

это надо уметь. ты, например, не умеешь

Ну так оформи эту шнягу в отдельный макрос или функцию. Чего как маленький-то?

Или ты думаешь, что в "волшебной библиотеке" этого делаться не будет? Там будет еще хуже, т.к. общая библиотека будет еще кучу проверок содержать!

Поясни насчет четырех раз, никак не могу увидеть.

Да и пофиг, что не умею! Работает — и ладно! А если поломается, то починю.

Тебе повезло, что работает. Ты выделяешь на 1 байт меньше, чем надо.

А если поломается, то починю.

А если из-за твоей ошибки у телескопа зеркало отвалится?

во-первых, не работает. во-вторых, std::string быстрее.

у sprintf емнип адовый оверхед, который при подобной работе со строками совершенно не нужен.

к слову, strlcpy() — потокобезопасна?

А, это я проглючил, да.

Если нужно именно что склеить строки — то strlen+memcpy. Оберни в функцию с переменным числом аргументов и всё. Ref: strjoin() в коде systemd.

Если нужно получить аналог asprintf — то snprintf (NULL, 0, ...) вернёт предполагаемый размер.

std::string быстрее

Такого бреда я еще не слышал! Ты еще скажи, что код на жабке будет шустрей ассемблерного работать!

Где это там 4 раза?

Два раза явно и по одному разу на каждое %s. Надо считать длины, запоминать, а потом печатать с помощью %.*s, указывая длину. И то, не факт, что snprintf не будет проверять каждый символ на \0. memcpy не проверяет, и поэтому сработает быстрее.

Врешь! Где?

Ограничивая длину результата суммой длин строк, ты не даёшь snprintf добавить завершающий ноль. Память под него, кстати, ты тоже забыл выделить.

УМВР.

Это не показатель.

Код на жабке исполняется в VM, а std::string — это строка+длина. Поэтому при нормальной реализации и компиляторе, способном к инлайну, будет быстрее. Правда, только при количестве объединяемых строк, равном двум: иначе будут создаваться временные строки.

А если поломается, то починю.

А если из-за твоей ошибки у телескопа зеркало отвалится?

А если из-за его ошибки на нас метеорит упадёт?

у sprintf емнип адовый оверхед

Согласен. В микроконтроллерах printf и ей подобные используются только идиотами либо буржуями (у которых мегабайт-другой флеша в МК).

В данном случае вполне возможно, что шустрей всех будет memmove работать или memcpy.

strlcpy() — потокобезопасна?

Нет, конечно. Если кто-то начал менять буфер во время хоть strcpy, хоть memcpy, на выходе получишь черт-те что. Это ясно.

Спасибо Эдик

fail.c

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(){
  char* a = "Hello ";
  char* b = "World";
  size_t sumlen = strlen(a)+strlen(b);
  char *concat = malloc(sumlen);
  snprintf(concat, sumlen, "%s%s", a, b); 
  printf("%s\n", concat); 
  return 0; 
}

$ gcc fail.c -o fail && ./fail
Hello Worl

Спасибо. Не могу распарсить

 r = new(char, max_length); 

ну у меня тут написано «The strcpy() and strncpy() functions are thread-safe», то же касается и memcpy, а вот про бсдшные варианты ничего нигде не сказано.

Вот не надо глупостей с sizeof, ТС потом скопирует начиная с третей строки и будет удивляться

Если тебе часто нужно вычислять strlen, то запросто можно такое сделать:

typedef struct{
  char *str;
  size_t len;
} string;

и написать свои функции работы с ними:

string *allocstr(size_t L){
  string *S = malloc(sizeof(string));
  if(!S) return NULL;
  S->str = calloc(1, L + 1);
  if(!S->str){
    free(S);
    return NULL;
  }
  S-> len = L;
  return S;
}

void freestr(string *S){
  free((*S)->str);
  free(*S);
  *S = NULL;
}

string *concatstr(string A, string B){
  size_t newL = A->len + B->len + 1;
  if(! realloc(A->str, newL)) return NULL;
  memcpy(A->str + A->len, B->str, B->len);
  A->len = newL;
  return A;
}

и т.д., и т.п.

Да, судя по всему, макрос.

В очень быстром коде нужно учитывать что char* фиксированый длины будет лежать в стеке, а в std::string нужно включить аллокатор специальный. Конечно в глупости «С быстрее С++» только нуб вроде Эдика будет верить, но есть реальные вещи, которые просто нужно помнить и знать как обходить. В С++ увы нужно больше понимать о внутренностях STL чтобы знать откуда ждать горя

пожалуйста

это вполне рабочий вариант. использую постоянно. если строки не константные — sizeof легко и непринужденно заменяется на strlen.

Я прекрасно это понимаю. Моё сообщение было к тому, что плюсовый std::string транслируется как раз во что-то подобное, и поэтому сравнение с жабой неуместно.

О! Массивы переменной длины. И как я о них не подумал. Они же сами уничтожаются когда функция завершается? То-есть, если я засуну этот код в функцию, мне придется в конце делать malloc чтобы вернуть склееную строку?

man strlcpy

man strlcat

А я вот так велосипедил:

char * str_concat (const char *fmt, ...)
{

    va_list items;
    size_t  length;

    va_start (items, fmt);
    length = vsnprintf (0, 0, fmt, items) * sizeof(char) + 1;
    va_end (items);

    char *out = (char *) malloc (length);
    va_start (items, fmt);
    vsnprintf (out, length, fmt, items);
    va_end (items);

    return out;

}

гораздо более эффективно передавать в функцию указатель на выходной буфер, его размер, и размеры входных строк. если понатыкать malloc/free везде — твоя прога на C будет работать со скоростью жабы.

ТСу остается к моему коду еще десяток функций приплюсовать и получится свой велосипед =D

(еще resize нужны и всякие другие вещи + в структуру надо бы добавить реальную длину содержимого, ну или что там по желанию)

Кстати, если еще в объявлении структуры добавить правильно выравнивание, то можно будет тупо писать

string *S = allocstr(X);
// заполняем S, а затем
printf("The string S is %s\n", (char*)S);

// можно макрос оформить, чтобы (char*) не писать

string *S = malloc(sizeof(string));

А тут ты выделил 32 байта, из которых используешь только 16. И кучу фрагментируешь почём зря. Да и вообще, скоро ты так героически реализуешь часть GLib, только без тестов.

Только пользоваться этим будет программист, который редко косячит, а не тот, кто спрашивает как склеивать строки в С. Не нужно новичкам советовать стреляющие в ногу решения

только долгая практика отстрела ног позволяет научиться не косячить.

Велосипед хорош. Когда немножко поосвоюсь с языком - обязательно напишу с десяток велосипедов. Пока рано)

Не, если мы заботимся о лишних выделениях памяти в куче — то всё понятно, плюсовые механизмы тут не к месту, нужно брать сишные массивы и фигачить.