Конкатенация в С/С++

Просто компилятор бьёт по рукам, а LOR — нет.

Кстати, осознают ли любители нескучных язычков, что в случае

while(...)
{
..
 total+=str;
...
}

под капотом такая же пердуха, только без возможности что-либо оптимизировать?

total+=str; под капотом такая же пердуха

как минимум нет вызова strlen

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

Или когда в нескучном язычке конструируется строка, то обходится без strlen?

И чего конструируется: из других строк нескучного языка или из других си-строк нелитералов?

как нуль на конце строки влияет копирование len(p2) в p1, без контороля соответветствия len(p1) и len(p2)?
что вы вообще несёте?

Тех кто пишет на C++ видимо не смущает, потому что делают str += "string" и это каждый раз создаёт новую строку.

Вы долбоящер? Там всё написано. Я то уж было думал там что-то с переполнением size_t на какой-то гипотетической сегментированной платформе связано. И словесла то какие: «OoB, UB»… Тьфу.

Тех кто пишет на C++ видимо не смущает

В случае std::string и += там одна destination str capacity которой растёт экспоненциально и квадрата не случается. А в случае std::ostringstream там ещё и изначально что-то порядка 4K преаллоцируют емнип.

делают str += «string» и это каждый раз создаёт новую строку.

Нет, не создается. Вызывается append(cstr, len). Для строковых литералов len вычисляется на этапе компиляции.

Для строковых литералов len вычисляется на этапе компиляции.

А если у тебя там динамическая память?

там запас есть. реализация делается таким образом, чтобы минимизировать количество реаллокаций в обычных случаях, а также дается функция - reserve - чтобы сразу у строки, если оно так надо, зарезервировать большой буфер, чтобы избежать реаллокаций вообще.

вызывается [__builtin_]strlen

в случае std::ostringstream там ещё и изначально что-то порядка 4K преаллоцируют емнип.

В этом случае это лишний расход памяти и получается палка о двух концах.

В этом случае это лишний расход памяти

Не так страшен чёрт как его малютка: это же обычно короткоживущая аллокация. Зато избавляет от проблемы «медленного старта». Я бы не переживал. По крайней мере на моей практике это проблемой никогда не было.

это же обычно короткоживущая аллокация

Короткоживущие аллокации можно сделать на стеке при помощи alloca().

Можно, но не нужно. Тем более в данном случае. Как там: «просто за время пути собачка могла подрасти». И будет оно там висеть мёртвым грузом после первого же resize, не говоря о лишнем геморрое.

путь примерения с лиспом

char *collect(GVariantIter* iter)
{
  // проблемка - нужен буфер неизвестного размера
  // или на каждом шаге реаллоцировать
  // циклы с предрасчётом неспортивно,
  // поэтому путь самурая - рекурсия
  char *buffer=NULL; // тот самый буфер

  void recursion(int offset,GVariant *iter) {
     gchar *str=NULL;
     if (g_variant_iter_loop(iter,"s",&str)) {
        int len=strlen(str);
        recursion(offset+len,iter);
        memcpy(buffer+offset,str,len);
     } else {
        buffer=malloc(offset+1);
        buffer[offset]=0;
     }
  }
  recursion(0,iter);
  return buffer;
}

с руки, как-то так...не проверял ;-)

если ты юзаешь glib, то что мешает пользоваться string builder'ом?

https://docs.gtk.org/glib/struct.StrvBuilder.html