а это не философия, это реальность, строки надо не только генерировать, но и отдавать, хранить и передавать, да-да, ты прекрасно осведомлен, просто напоминаю

а этот тред - про их конкатенацию на языке C. тоже просто напоминаю.

Тебя носом в книжку ткнуть?

и все несовместимы друг с другом :)

Что понимать под совместимостью? QString, например, умеет в/из std::string и std::wstring. Как и различные кодировки. Этого недостаточно?

Тебя носом в книжку ткнуть?

Не позорься уже, посмотри реальный код в различных *libc.

а этот тред - про их конкатенацию на языке C. тоже просто напоминаю.

когда я пришел в тред - ты уже рассуждал на другую тему, тоже просто напоминаю

ВНЕЗАПНО: есть php написанный на сишке

Ты упоролся? Предлагаешь, если нужно в программе на Си конкатенировать строки, отказываться от Си и писать на тормозящем php?

Сишкак как раз и нужна, если задача _нестандартная_.

Я тебя разочарую, большинство кода - стандартные. И как раз stl собирает в себе инструменты для решения стандартных задач, при том, вполне удачно.

нет, это конвертация. дополнительный оверхед. в нормальных языках — строковой тип 1, и его используют все программы.

когда я пришел в тред - ты уже рассуждал на другую тему, тоже просто напоминаю

что и сейчас делать продолжаю. отвечая на вопросы анонимов. хотя тема C++ мне вообще неинтересна.

Какой ты толстый [1, 2].

и все несовместимы друг с другом :)

Отлично совместимы, через всё тот же const char *.

потому что есть libc, которого вполне достаточно. и это хорошо.

И это тред - результат достаточности :)

Прямо как у Высоцкого:

сорок душ посменно воють,
раскалились до бела
во как сильно беспокоють
треугольные дела
(с) :)

Ну так и есть: calloc = malloc + memset

Код не читай — сразу отвечай.

Ну таки я склонен считать, что ты ошибаешься опять.

нет, это конвертация. дополнительный оверхед. в нормальных языках — строковой тип 1, и его используют все программы.

Это очевидно не случай С и С++. По различным и очевидным причинам.

а ты их в нужном формате в поток выводи, в чем проблема?

Какой ты толстый

Блин, я бегло и неверно прочитал твой пост, решил, что ты имел ввиду, что calloc всегда не malloc + memset, извини.

Там того оверхеда ничтожно мало, тем более по сравнению с «нормальными языками».

Я не специалист по тредам, но судя по коду (strlcat, strlcpy) должно быть thread safe.

PS: в линуксах оно, оказывается, доступно через libbsd.

Всё у вас самодельное. Жесть какая. Зато не скучно поди, да?

Ну ты код открой по первой ссылке. Там malloc + calloc.

просто меня смущает

Шок от С. Как склеивать строки? (комментарий)

Принимается.

http://bstring.sourceforge.net/

Це не наші єноти… ©

А ты видел промышленные научные приборы, которые в количестве > 1 экземпляра нафиг никому не вперлись?

Даже у пиндосов так. Только у пиндосов деньги есть: у них просто научники, если им чего-то не хватает, заказывают изготовление. А мы сами. Я и чертежи черчу, и железо сверлю-пилю, и азот в криостат заливаю, и электронику паяю, и прошивки микроконтроллерам пишу, и веб-морду тоже делать буду для управления прибором...

Вот так всякой хренью занимаешься, а на науку и времени не остается!

тьфу, malloc + memset

Там написано про ситуации в которых память не очищается. Хм? Я всегда считал, что так и поступает calloc, память может быть уже обнулена.

Ты о чем? Реализация calloc — это по сути malloc + memset.

Он либо прикидывается, либо и правда не читал.

Про контекст ветки обсуждения…

Какой ты толстый [1, 2]

Ну так и есть: calloc = malloc + memset

Ты какой-то тупенький, а не толстый.

Здаётся мне, что Эдик путает нитебезопастность и атомарность.

Все эти функции нитебезопастны, т.к. у них нет внутреннего состояния. Вызвав одну и туже функцию два раза на разных данных, то каждая будет работать со своими данными и не смешивать их.

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

Меня ломает все читать.

Собственно, про то и вопрос, та же strtok опасна в этом отношении, а в бсдшных манах это явно не оговаривается и не ясно, чего ждать.

А где было про атомарность?

И каким раком memset может быть атомарным? Офигительно, конечно, было бы атомарно обнулить пару гигов оперативы...

Есть потокобезопасная strtok, которая использует не внутренний статический буфер, а твой.

Ты хочешь сказать, что даже не читаешь, на что отвечаешь? Совсем заняться нечем?

Иногда читаю.

Это будет strtok_r().

Во-во. Надо будет свою c-cgi-lib обновить, как буду очередную веб-морду делать: заменить все strtok на эти, т.к. собираюсь на вебсокеты переходить, а там не принцип "1 клиент == 1 процесс", а потоки. Т.е. уже обычную strtok использовать нельзя будет.

Офигительно, конечно, было бы атомарно обнулить пару гигов оперативы...

А не через mmap ли это и COW по пейджфолту делается?

А где было про атомарность?

Тут:

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

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

В общем, я к тому, что если подходить с этой стороны, то вообще ни одна функция, работающая с более чем одним байтом, не «потокобезопастна». (Хотя на самом деле речь про атомарность.) И не важно, что там в мане стоит.

Как оно сразу обнулится по-твоему?

Можно еще один нубский вопрос? Чем отличются

const char* s =  "Sabakabarabaka";

и

char s[] = "Sabakabarabaka";

У первого sizeof s == 8. У второго - 15

Очень просто же

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

int main(int argc, char* argv[])
{
    char* stringOne = "123";
    char* stringTwo = "321";
    int resultStringSize = strlen(stringOne) + strlen(stringTwo) + 1;
    char resultString[resultStringSize];
    int charIndex = 0;
    for (int i = 0; i < strlen(stringOne); i++) {
        resultString[charIndex] = stringOne[i];
        charIndex++;
    }
    for (int i = 0; i < strlen(stringTwo); i++) {
        resultString[charIndex] = stringTwo[i];
        charIndex++;
    }
    resultString[charIndex] = 0;
    printf("%s", resultString);
    return 0;
}

Для еще большей оптимизации замени циклы на while и вычисляй strlen внутри них

Первое — это указатель на строку, и имеет соответственно размер указателя. Второе — это массив, и размер соответсвующий.

Две разные сущности. Не надо их путать с array decay (_[] -> *_), который происходит при передаче аргументов в функцию.

for (int i = 0; i < strlen(stringOne); i++)

И сразу же получаем O(n^2). Кстати, может знает кто, какой-нибудь компилятор уже научился оптимизировать такой говнокод?

отличаются типом. 1й указатель, 2й массив.

кто-нибудь из компиляторов умеет оптимизировать такой говнокод?

вероятно, если использовать restrict char *stringOne

но лучше не полагаться на компилятор.

(в конкретном примере выше, это указатель на константную строку, и компилятор это знает, но сумеет ли оптимизнуть, или нет - хз)