Быстрый способ создания строковой переменной из значений нескольких строковых переменных

@kalabuni · Регистрация: 18.04.2012

Студворк — интернет-сервис помощи студентам

К примеру, в javascript'e из трёх исходных строковых переменных создать одну конкатенированную рекомендуется следующим способом:
надо поместить значения исходных переменных в массив, а затем "соединить" его элементы методом join (), используя пустой разделитель ''
Эта операция y = [x1, x2, x3].join (''); выполнится много быстрее, чем последовательная конкатенация трёх значений в одну переменную

А как с этим обстоит дело в C++ ?
Имеется ли в нём аналог метода join () и имеет ли вообще смысл этим заморачиваться?

Извиняюсь за ламерский вопрос, но этот раздел вроде как для таких вопросов и предназначен, так?

PS. спрашивал об этом же у "явщика", тот ответил, что для работы со строками у него есть класс "стринг-билдер", который всё это вполне эффективно делает, а как именно - ему совсем неинтересно

@kalabuni · 29.12.2017, 16:47 **[ТС]**

bedvit, а водительские права обладателя горбатого запорожца должны отличаться от прав владельца мерседеса S-класса?

@TRam_ · 30.12.2017, 02:24

kalabuni, в данном случае сравнивается землепроходческий комплекс с канавокопателем. А ещё есть кирка и лопата (ассемблер).

Добавлено через 2 минуты
И у каждого свои особенности транспортировки и обслуживания на месте работ. И канавокопателем тоннель никак не прокопаешь, хотя киркой с лопатой это сделать можно.

Добавлено через 8 часов 16 минут
В общем сравнил выполнение соединения строк по сравнению с по-символьным добавлением. Оказалось что был неправ, и что там даже не в 6 раз больше производительность, а на степень от числа элементов. Сравнивал

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    arr[0][0] += s[0];
    arr[0][0] += s[1];
 
    for(std::size_t i = 2; i < s.size(); i++)
    {
        arr[0][i-1] += arr[0][i-2][1];
        arr[0][i-1] += s[i];
    }
 
    for(std::size_t i = 1; i < arr.size(); i++)
    {
        for(std::size_t j = 0; j < str_len - i - 1; j++)
        {
            arr[i][j] += arr[i-1][j];
            arr[i][j] += arr[i-1][j+1][i];
        }
    }

со старым

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    for(std::size_t i = 0; i < s.size(); i++)
    {
        const char &p_s = s[i];
 
        for(std::size_t j = 0; j < n; j++)
        {   
            std::size_t min_val = 0;
            if(i > (j + 1))
                min_val = i - (j + 1);
 
            std::size_t max_val = i + 1;
            if((max_val + (j + 1)) > str_len)
                max_val = str_len - (j + 1);
 
            for(std::size_t k = min_val; k < max_val; k++)
                arr[j][k] += p_s;
        }
    }

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

Добавлено через 18 минут
Вот только пользы от этого не так уж много - потому что время выделения памяти под строки в 5 раз больше времени собственно обработки массива более медленным способом, а время освобождения памяти в 10 раз больше времени выделения. Итого получается, что собственно копирование строк приходится либо 0.2% собственно времени работы с массивами, либо 1.5% ... Если конечно их каждый раз перевыделять под новую длину строки.

Добавлено через 8 минут
Но это только для случая большого числа массивов. Если массивов мало (до 10), и они (видимо) помещаются в кэш процессора, то такого резкого преимущества копирования строк перед копированием символов не наблюдается - они сравнимы, отличаются раза в 1.5-2 . И время выделения/освобождения тоже становится сравнимым с собственно обработкой (т.е. доля времени на обработку строк увеличивается до 20 - 30%).

@kalabuni · 30.12.2017, 05:30 **[ТС]**

Сообщение от TRam_

Оказалось что был неправ, и что там даже не в 6 раз больше производительность, а на степень от числа элементов.

очень рад, и совсем не тому, что вы признали свою неправоту, а тому, что моя картина мира не оказалась разрушенной -- си++ оказался таки нормальным языком программирования, а не чем-то таким, чего я понять в принципе не в состоянии

скачал и установил вижал-студию 2013, решил с нового года заняться таки освоением Си++, так что общаться в этом разделе, надеюсь, ещё будем.

а покуда начальный философский вопрос: полагаю, что строгая статическая типизация в СИ++ и необходимость слежения за распределением / выделением памяти -- это не самоцель и не "фишка" языка, а тяжёлое наследие зачаточной компьютерной эры, когда необходимо было заботиться о каждом байте кошмарно маленькой оперативной памяти размером в 64К. Прав я или нет?

@TRam_ · 30.12.2017, 14:23

Сообщение от kalabuni

Прав я или нет?

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

Но вообще автоматически удаляемые динамически создаваемые объекты тут тоже можно сделать. Как те, которые внутри себя умеют динамически создавать/уничтожать объекты при своём создании/уничтожении (как например использовавшийся в коде выше std::vector) или динамически создающие и потом автоматически удаляющие самих себя (механизм "умные указатели", работают на основе счётчика действующих указателей на данный объект).

@kalabuni · 30.12.2017, 14:52 **[ТС]**

Сообщение от TRam_

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

спс, вроде понятно стало

@bedvit · 31.12.2017, 13:37

kalabuni, а если бы негр с лишней хромосомой да на "боярке"... Если серьёзно, отметил некоторые объективные особенности языков. Права могут отличатся, если это принципиально разные транспортные средства (особенности выделения пямяти и т.д), к примеру мерседес и вертолёт или трактор. Разные рычаги дергать надо

Математика везде одна, разные особенности инструмента.
P.S. Не приверженец одного языка, считаю что у каждого свои достоинства.

@kalabuni · 31.12.2017, 14:14 **[ТС]**

bedvit, не понимал бы я про "наличие объективных особенностей у языков", не пришёл бы сюда за консультацией

но здесь меня попытались убедить, что законы логики в cи++ какие-то принципиально иные, чему я не поверил, и оказался прав.

в разных языках по разному осуществляются процедуры, но сам порядок действий (не последовательность, а именно порядок), определяемый алгоритмом -- он неизменен: чтобы приготовить глазунью, сначала надо разбить яйцо, а уже потом жарить белок с желтком, не размешивая их, но никак не наоборот
а вот с какого именно конца яйцо лучше разбивать: "с острого или с тупого" (с) Дж. Свифт -- это как раз особенность конкретного языка

@TRam_ · 31.12.2017, 14:47

Сообщение от kalabuni

чтобы приготовить глазунью, сначала надо разбить яйцо, а уже потом жарить белок с желтком, не размешивая их, но никак не наоборот

Но можно разбить все яйца для глазуньи сразу и их так пожарить, а можно жарить по-одному, и это тоже получится глазунья.

@kalabuni · 31.12.2017, 14:53 **[ТС]**

TRam_, ну давайте поупражняемся в остроумии

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

@TRam_ · 31.12.2017, 15:06

Сообщение от kalabuni

но вот снять носки, не сняв до этого обувь

Если обувь - шлёпанцы, то снять носки через них особого труда не составляет, хотя и не удобно.

Речь не совсем об этом. А о том, что организовывать интерпретируемый язык приходится иным способом, нежели компилируемый. Потому что интерпретируемый требует постоянной работы с идентификаторами данных или действий (с которыми нужно много возиться, и из-за этого они сильно влияют собственно на ход выполнения задачи), а компилируемый готовит непосредственно инструкции процессору, которые выполняются независимо от контекста остальных действий или данных.

@bedvit · 31.12.2017, 15:09

Не пременительно к Вашему алгоритму и с моим небольшим опытом: если объект (переменная, структура, класс и т.д.) схожим образом взаимодействует с памятью, имеет схожие механизмы реализации в разных языках - для него и алгоритм использования будет аналогичен для разных языков (производительность, механизм использования), в обратном случае так сказать нельзя (что не утверждает отсутствие общего одинаково быстрого алгоритма) - тогда и учитываются разные особенности реализации.
+Оптимизации для каждого языка свои, стек или куча, указатели, каким способом параллелим алгоритм (если возможно) и прочие (в т.ч. на этапе компиляции).
В С# к примеру можно использовать unsafe и т.д.
Поправьте меня, если где-то заблуждаюсь.

@kalabuni · 31.12.2017, 15:14 **[ТС]**

Сообщение от TRam_

Речь не совсем об этом

ага, раздел форума Алгоритмы нафиг не нужен -- они же, алгоритмы, совершенно не учитывают разницу между интерпретируемыми языками и компилируемыми
Мне войти с предложением к администрации удалить этот ненужный раздел, или вы сами это сделаете?

Новые блоги и статьи Все статьи Все блоги /
Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .	Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .
Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629

	Быстрый способ создания строковой переменной из значений нескольких строковых переменных 26.12.2017, 21:52. Показов 5958. Ответов 71 Метки нет (Все метки) К примеру, в javascript'e из трёх исходных строковых переменных создать одну конкатенированную рекомендуется следующим способом: надо поместить значения исходных переменных в массив, а затем "соединить" его элементы методом join (), используя пустой разделитель '' Эта операция y = [x1, x2, x3].join (''); выполнится много быстрее, чем последовательная конкатенация трёх значений в одну переменную А как с этим обстоит дело в C++ ? Имеется ли в нём аналог метода join () и имеет ли вообще смысл этим заморачиваться? Извиняюсь за ламерский вопрос, но этот раздел вроде как для таких вопросов и предназначен, так? PS. спрашивал об этом же у "явщика", тот ответил, что для работы со строками у него есть класс "стринг-билдер", который всё это вполне эффективно делает, а как именно - ему совсем неинтересно 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	29.12.2017, 16:47 [ТС]
	bedvit, а водительские права обладателя горбатого запорожца должны отличаться от прав владельца мерседеса S-класса? 0

@bedvit 1210 / 261 / 22 Регистрация: 20.05.2016 Сообщений: 1,147 Записей в блоге: 22
	31.12.2017, 13:37
	kalabuni, а если бы негр с лишней хромосомой да на "боярке"... Если серьёзно, отметил некоторые объективные особенности языков. Права могут отличатся, если это принципиально разные транспортные средства (особенности выделения пямяти и т.д), к примеру мерседес и вертолёт или трактор. Разные рычаги дергать надо Математика везде одна, разные особенности инструмента. P.S. Не приверженец одного языка, считаю что у каждого свои достоинства. 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	31.12.2017, 14:14 [ТС]
	bedvit, не понимал бы я про "наличие объективных особенностей у языков", не пришёл бы сюда за консультацией но здесь меня попытались убедить, что законы логики в cи++ какие-то принципиально иные, чему я не поверил, и оказался прав. в разных языках по разному осуществляются процедуры, но сам порядок действий (не последовательность, а именно порядок), определяемый алгоритмом -- он неизменен: чтобы приготовить глазунью, сначала надо разбить яйцо, а уже потом жарить белок с желтком, не размешивая их, но никак не наоборот а вот с какого именно конца яйцо лучше разбивать: "с острого или с тупого" (с) Дж. Свифт -- это как раз особенность конкретного языка 0

@kalabuni супермизантроп 3941 / 2979 / 692 Регистрация: 18.04.2012 Сообщений: 8,629
	31.12.2017, 14:53 [ТС]
	TRam_, ну давайте поупражняемся в остроумии у меня репертуар богатый: "по утрам, надев часы, не забудь надеть трусы", но вполне можно и наоборот но вот снять носки, не сняв до этого обувь, вряд ли получится 0

@bedvit 1210 / 261 / 22 Регистрация: 20.05.2016 Сообщений: 1,147 Записей в блоге: 22
	31.12.2017, 15:09
	Не пременительно к Вашему алгоритму и с моим небольшим опытом: если объект (переменная, структура, класс и т.д.) схожим образом взаимодействует с памятью, имеет схожие механизмы реализации в разных языках - для него и алгоритм использования будет аналогичен для разных языков (производительность, механизм использования), в обратном случае так сказать нельзя (что не утверждает отсутствие общего одинаково быстрого алгоритма) - тогда и учитываются разные особенности реализации. +Оптимизации для каждого языка свои, стек или куча, указатели, каким способом параллелим алгоритм (если возможно) и прочие (в т.ч. на этапе компиляции). В С# к примеру можно использовать unsafe и т.д. Поправьте меня, если где-то заблуждаюсь. 0