Vector<string> в string

@dimmarvel · Регистрация: 04.04.2018

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

Как преобразовать vector<string> в string?

C++
1
2
vector <string> test;
string str;

к примеру test в str
Думаю легко и я видимо не умею гуглить...

@S_el · 04.05.2019, 21:03

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

для списка, например?

Для чего угодно. Шаблоны как-никак.

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

Не у всех есть такой оператор по определению.

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

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

Посимвольно это не путь к победе.

А, это уже вопрос терминологии. Символы тоже разные бывают, как их лучше представлять зависит от кодировки.
Значит и как переносить - тоже. С практической точки зрения важны только удобство и производительность(именно в таком порядке т.к. большинство - пользователи, а не разработчики). Вот решение notAll - самое удобное, а с точки производительности - наоборот.

IGPIGP · 04.05.2019, 21:40

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

Для чего угодно. Шаблоны как-никак.

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

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

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

C++
1
2
3
4
5
6
7
8
template<class T>
list<T> operator+(const list<T>& rhs, const list<T>& lhs)
{
list<T> ret;
    ret.insert(ret.end(), rhs.begin(), rhs.end());
    ret.insert(ret.end(), lhs.begin(), lhs.end());
    return ret;
}

rvo спасёт от копирования при возврате. Остальное нужно будет сделать вручную и опять же insert. Но будет создаваться локальный объект. Не думаю, что это быстрее. Кроме всего в пространстве кода появится оператор не стандартный...
С другой стороны, если бы был += (с ссылкой на объект результат), то всё копировалось бы в зарезервированную область. У списка её нет, но это частный случай, неудачный для пояснения ситуации. А выполнить += свободной операцией нельзя, ей нужен объект.

Добавлено через 5 минут

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

А, это уже вопрос терминологии.

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

@S_el · 04.05.2019, 22:43

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

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

Стоп. Мы сейчас о чем конкретно говорим?

IGPIGP · 05.05.2019, 00:14

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

Стоп. Мы сейчас о чем конкретно говорим?

Рад вашему вопросу. Прочтите его и подумайте о том, что я могу на него ответить. S_el, спросите конкретно и я постараюсь ответить. Что касается push_back то я не говорил намёками или сложными гиперболами. Я предложил вам написать код по задаче и увидеть, что работа += для string и push_back для неё же, похожа только с точки зрения самых общих выражений. Оба что-то в строку добавляют. При этом я не утверждаю, что строку к строке нельзя добавить посимвольно. Это просто не нужно с моей точки зрения.

@S_el · 05.05.2019, 00:23

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

Это просто не нужно с моей точки зрения.

Не нужно. Речь шла про возможное универсальное решение, на которое я отвлекся. Посмотрел в справочнике и действительно std::string не имеет перегрузку метода push_back для другой строки, но имеет функцию append.
А посимвольное копирование это про внутреннюю реализацию что для insert что для чего-то другого.

IGPIGP · 05.05.2019, 00:31

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

но имеет функцию append

и для этого пришлось бы специализироваться. Но insert реализуют все и это позволяет решать всё в одной реализации. А вот контейнер списков в список так не преобразуется. У списков нет метода reserve и код не скомпилируется. Вот как могла бы выглядеть специализация для контейнера списков:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
template< typename T, template<typename, typename> class Container >class ContainerTemplate<list<T>, Container>:public Container<list<T>, allocator<list<T>>>
{
public:
  list<T>  whole_inlet_containers2container()
  {
      list<T> result;
      for(auto a:*this)result.insert(result.end(), a.begin(), a.end());
      return result;
  }
};
 
//клиентский:
//ContainerTemplate<list<int> , vector> li{{{1,2,3},{4,5,6}}};//и этот
     ContainerTemplate<list<int> , list> li{{{1,2,3},{4,5,6}}};//и этот варианты работают с специализацией на list<T>
    auto _sum= li.whole_inlet_containers2container();
    for(auto a:_sum)
       cout<<a<<' ';

можно бы и со slice реализовать, но это разрушает исходник, хотя и намного быстрее. Важно, что можно сделать именно то, что нужно.

@S_el · 05.05.2019, 09:15

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

У списков нет метода reserve и код не скомпилируется. Вот как могла бы выглядеть специализация для контейнера списков:

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

IGPIGP · 05.05.2019, 09:54

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

Спискам он и не нужен

Это спорный вопрос? Нет. Это не вопрос. Глупо выделять поэлементо то что можно выделить пулом. При массовых операциях это единственный разумный подход. S_el, тут тоже просматривается желание работать "курочка-по-зёрнышку".
У списков есть resize имеющий ту же семантику. Но боль в том, что вся стандартная библиотека - зверинец разношерстной фауны. Присмотритесь. Разные названия для сходных семантик, разные порядки задания аргументов(!)... Метод копирования требует пары для интервала источника а затем итератор назначения а метод вставки - сначала итератор назначения а потом пару итераторов источника. Это значит, что эффективно работать без применения таких вот трюков (не простых) нельзя. И это сделано людьми для людей. Вот более полная специализация для списка, которая учитывает заблаговременную аллокацию путём ресайз (нужно раскомментировать вызов) :

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
template< typename T, template<typename, typename> class Container >class ContainerTemplate<list<T>, Container>:public Container<list<T>, allocator<list<T>>>
{
public:
    ContainerTemplate(const list<list<T>>& contList)
    {
     for(const auto & a:contList) this->push_back(a);
    }
 
    size_t inlet_whole_length(){
        size_t result(0);
            for(auto it: *this)
            {
                result+=it.size();//этот вызов медлителен и обесценивает всю функцию
            }
        return result;
      }
 
  list<T>  whole_inlet_containers2container()
  {
      list<T> result;
     // result.resize(inlet_whole_length());//интересно, что если раскомментировать то
      //получается более медленно. Причина скорее всего в медленном подсчёте длин списков
      //который требует последовательного прохождения
      for(auto a:*this)result.insert(result.end(), a.begin(), a.end());
      return result;
  }
};

он показывает, что резервирование не имеет смысла по другой причине. Весь алгоритм (и без того не быстрый для списка) становится в полтора раза медленнее. Но из-за того что при подсчёте общей длины каждый вызов size() на списке приводит к проходу данного списка от начала и до конца. Список стл (оговорюсь, - для MigGW) не умеет хранить свою длину а арифметика итераторов не применима для него (как для вектора, скажем). И это еще одна "светлая" частичка стандартной библиотеки. Этот разговор трудно остановить начав, но нужно остановить. Тема тут другая и она огромна. Бесплатные средства и жизнь. Вот почему специализация стратегий - путь к победе.

@S_el · 05.05.2019, 13:58

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

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

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

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

Этот разговор трудно остановить начав, но нужно остановить. Тема тут другая и она огромна. Бесплатные средства и жизнь. Вот почему специализация стратегий - путь к победе.

Да, давайте остановим.

IGPIGP · 05.05.2019, 14:16

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

Поэтому предпочитаю даже не пытаться создать универсальное решение там, где это не нужно.

Специализация шаблонов вообще и стратегий в частности, это как раз возможность скрыть за универсальностью вызова специальные (оптимальные для...) решения. S_el, вы вправе решать для себя как поступить, но вся стандартная библиотека (и boost и платные) это набор универсальных решений. Вы имели неосторожность предложить push_back вместо insert как лучший способ обобщения и ошиблись. Это бывает. Но если вам не нравится решение которое быстрее std::accumulate и оптимально работающее на
вектор строк -> строка
векторе списков -> список
список строк -> строка
список векторов -> вектор
список списков -> список
хух... хорошо, что нету строк векторов/списков (из коробки).
то или со временем вы измените своё мнение или нет.
Стратегии на наследовании потребовали бы кучи наследников и их комбинаций.
А стратегия на шаблонах, легко конфигурируются на типах при использовании, легко расширяется в процессе разработки по мере надобности не затрагивая клиентский и уже наработанный библиотечный код.

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

Да, давайте остановим.

Я имел ввиду обсуждение недостатков стандартной библиотеки. А по теме, готов говорить, если интересно. В ней много чего можно обсудить.

@S_el · 05.05.2019, 14:26

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

вы вправе решать для себя как поступить, но вся стандартная библиотека (и boost и платные) это набор универсальных решений.

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

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

Но если вам не нравится решение которое быстрее std::accumulate и оптимально работающее на

Почему не нравится? Нравится, я это уже отмечал. Если бы я писал библиотеку, которая упрощала бы жизнь пользователям то может и сам бы поступил также(в первом приближении). Однако когда мне нужно просто сшить строки то я резервирую память и сшиваю как было сделано в самом первом ответе.

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

Вы имели неосторожность предложить push_back вместо insert как лучший способ обобщения и ошиблись. Это бывает.

Ошибся и признал это. Узнал что-то новое и пошел дальше.

IGPIGP · 05.05.2019, 15:17

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

Ошибся и признал это. Узнал что-то новое и пошел дальше.

Всё верно. Но вы делаете суждения о том что хорошо, а что нет в части обобщений.

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

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

Однако мы же говорим о интерфейсах, если конкретизировать

универсальное решение

и я сказал о том, что со временем вы либо измените точку зрения либо нет. Тут я и имел ввиду, что на фразу в которой я возблагодарил создателя за то что метод insert стал обобщением и сократил количество специализаций вы рискнули сказать, что push_back универсальнее как интерфейс. А как вы можете оценить универсальность если склонны ошибаться в том, что это такое?
S_el, я не говорю, о том, что нужно писать библиотеки на каждом шагу. Но обилие хардкода в современном мэйнстриме зашкаливает. Это не только генерённый код. Это код, который пишут вполне квалифицированные программисты под давлением сроков и прессинга. Истина где-то есть, но я не стал бы искать её в этой теме, говоря об уровне абстракции для конкретного случая. Всё хорошо, когда оно хорошо.

@S_el · 05.05.2019, 16:27

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

Тут я и имел ввиду, что на фразу в которой я возблагодарил создателя за то что метод insert стал обобщением и сократил количество специализаций вы рискнули сказать, что push_back универсальнее как интерфейс.

Понимаете в чем дело insert это универсальное решение для вставки. Для добавления в конец универсальное решение должно называть либо push_back или, как уже выяснили, append. Любое более специализированное решение будет не менее эффективным более общего. Поэтому за вставку в любую позицию приходится чем-то платить. И если все что вам нужно это добавить что-то в конец использовать insert - избыточно.
Поэтому нет, я не мог сказать что push_back универсальнее чем insert и действительно не говорил это. Вот моя цитата:

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

я бы использовал push_back для вставки в конец, т.к. здесь только это и требуется.

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

IGPIGP · 05.05.2019, 19:26

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

я бы использовал push_back для вставки в конец, т.к. здесь только это и требуется.

Как выяснилось не требуется. А высказывание достаточно безапеляционно.

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

Понимаете в чем дело insert это универсальное решение для вставки. Для добавления в конец универсальное решение должно называть либо push_back

Может быть. Я говорил, что с терминологией и именами беда в программировании. Но на деле это не так.

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

Любое более специализированное решение будет не менее эффективным более общего.

Если вставлять в конец то не должно быть разницы, хотя это вопрос реализации. Кому-то же показалось, что списку не нужно хранить размер и теперь нельзя эффективно выделить место.
Это потому что кто-то решил что список не должен выделять "сладкие" сплошные куски (они-де для массивов-векторов), а списки могут и побомжевать отдельными кускочками. Зачем же это резервировать. Пусть дескать берут то, что есть на данный момент. Но у списков есть важная черта, - возможность работать с адресами (валидность итераторов после любых операций не удаляющих по этим адресам). Это пошло побоку. Люди думают за других!
Так же и accumulate не делает резервирования и если не сделать руками то код будет слабый. С insert та же проблема. Если реализовано хорошо то не должно быть разницы между пушами и вставкой. Просто пуши - синтаксический сахар использующий инсёрт максимально эффективно для данного типа контейнера. Поэтому ваши рассуждения звучат для меня странно.
А теперь такое же уверенно-категоричное суждение:

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

Спискам он и не нужен, весь смысл reserve в получении блока памяти

Есть ресайз. И пусть он (может выделять кусками) и называется по иному, но он инкапсулирует пачку вызовов к OS для заказа свободной памяти и их выполнение. Потом остаётся лишь писать. Это очень хорошо. Он оказался не нужен в большинстве современных бесплатных библиотек для двусвязного списка по смешной причине. Съэкономили на счётчике длины и операции его инкрементирования/декрементирования при вставке/удалении! Поэтому он есть. Но смысла в нём нет. Жаль.

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

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

Я не соберался этого делать. Наоборот. Вы вступили в предметное обсуждение в момент когда запузырились фекалии в теме. Я был этому рад. Тем более, что всегда относился к вам с симпатией встречая в разных разделах. Неудачные суждения о посимвольном копировании и о пуш-бэке не вызвали особых эмоций. С кем не бывает? Главное, - наш общий интерес к теме. Она действительно интересна в данном контексте. Потому что найти способ собрать строки в строку не представляется проблемой и внешний контейнер вообще не при чём. Но концовка меня ошеломила:

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

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

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

Мой ответ значительно мягче, чем мог бы быть.

Добавлено через 27 минут

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

Поэтому он есть. Но смысла в нём нет. Жаль.

Тут я чуть перегибаю, потому, что это замедляет лишь при небольших объектах. Конечно, ресайз на списке с объектами в сотни и более байт будет занимать такое же время как и на малых объектах (плюс - минус кэш, конечно, но это трудно обсуждать), а выделение одним пулом будет гораздо быстрее.

@S_el · 05.05.2019, 20:05

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

Как выяснилось не требуется. А высказывание достаточно безапеляционно.

Правильно. И конкретно в этом случае я ошибся, что и написал выше.

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

Так же и accumulate не делает резервирования и если не сделать руками то код будет слабый.

Так как accumulate это алгоритм из заголовочника numeric, т.е. основное предназначение работа с числами.

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

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

Так и я к вам с симпатией отношусь. Ну разошлись у нас взгляды на детали реализации - что с того. Лично я кое-что полезное из темы почерпнул.

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

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

Хе-хе. На самом деле нет. Когда я пишу о своих предпочтениях, это всего лишь мои предпочтения. Это не совет и не рекомендация. Ваш ответ отлично подойдет в качестве иллюстрации общего решения, но для большинства кейсов он избыточен.

IGPIGP · 05.05.2019, 20:24

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

Так как accumulate это алгоритм из заголовочника numeric, т.е. основное предназначение работа с числами.

Однако можно было бы сделать общее решение и это не усложнило бы работу с числами. А теперь есть соблазн для тех кто не желает париться и вникнуть в детали. Может на java лучше писать тогда? Ведь используется перегрузка оператора сложения и это не позволит использовать резерв эффективно так как не ссылка а значение возвращается.

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

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

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

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

Ваш ответ отлично подойдет в качестве иллюстрации общего решения, но для большинства кейсов он избыточен.

Он по затратам труда не выше частного решения. Посмотрите внимательно и увидите - 10-15 строк описания алгоритма. Важно, что он широко применим и расширяем. А. Александреску сравнивает частные наколеночные решения, с магическими числами. Такие решения трудно сопровождать, понимать, и они повторяются в самых разных вариантах замусоривая и увеличивая код. Это снижает общую читаемость всего. Я начал это понимать недавно, но чем дальше тем больше.

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

Так и я к вам с симпатией отношусь. Ну разошлись у нас взгляды на детали реализации - что с того. Лично я кое-что полезное из темы почерпнул.

Думаю, это стоит любого (разумного) хода событий и любых (разумных) затрат энергии.

@S_el · 05.05.2019, 21:05

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

Однако можно было бы сделать общее решение и это не усложнило бы работу с числами.

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

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

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

Это не так. Если бы у меня было негативное отношение - я бы высказался более предметно(например, указал бы что вы итерируете по значению, создавая тем самым копии элементов) - наоборот я одобрил ваш ответ нажав на соотв. кнопку. Ваше решение в первую очередь ценно не общностью подхода, но демонстрацией того, что для эффективной реализации следует всегда держать в голове то, что постоянная реаллокация памяти существенно замедляет работу программы. Просто в силу того, что с этим сталкивается практически каждый программист C++. Что до моего замечания к выбранному методу то это не более чем комментарий к детали реализации, которая решается при проектировании.
Я не согласен с выбранным вами подходом исключительно из практических(скорость написания, удобство, ...), а не академических соображений, но именно это - дело вкуса. Кому-то нравятся значащие отступы (Python, F#), кто-то (например я) - такой подход терпеть не может. Кого-то раздражает что экспортируемые вещи в Go начинаются с заглавной буквы, а кто-то - восторгается таким изящным подходом. Поэтому наша дискуссия не про содержание (здесь я с вами солидарен), но исключительно про форму. Вы меня убедили что insert - грамотный выбор для решаемой вами задачи(получить краткое, но эффективное решение) и сделан из практических соображений(нет у строк перегрузки для push_back и желание получить более универсальное решение).

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

Он по затратам труда не выше частного решения.

Для вас - да, а для начинающих программистов?

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

Я начал это понимать недавно, но чем дальше тем больше.

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

IGPIGP · 05.05.2019, 22:26

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

например, указал бы что вы итерируете по значению, создавая тем самым копии элементов

Ссылка не поможет так как элемент копируется в конец суммирующего результата. Значение будет скопировано с использованием переноса и одна копия всё ровно будет.
Тут есть аналогия с тем, что многие думают, что += для строк работая по ссылке имеет дело с одной исходной строкой. А это сбывается лишь если память загодя зарезервирована. Иначе ссылка как демон, она вроде есть, ан - хвать и нету ея! (Ионан Васильевич меняет прошивку кмоп ).

@S_el · 05.05.2019, 23:30

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

Ссылка не поможет так как элемент копируется в конец суммирующего результата. Значение будет скопировано с использованием переноса и одна копия всё ровно будет.

Одна, а не две. Для малых строк заметной разницы не будет, но если объединяемые строки большие, а элементов много, то лишнее копирование сыграет свою роль.
Пример на векторах - https://ideone.com/ej4mM5

IGPIGP · 05.05.2019, 23:43

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

Одна, а не две.

И правда! Интересно однако. Значит что-то о константных ссылках я ещё не понимаю. Мне казалось, что компилятор видя гибель временного объекта в итерации должен включить перемещающее копирование (а для строк и пр. контейнеров, оно реализовано). Выходит, ошибался. Спасибо)

Новые блоги и статьи Все статьи Все блоги /
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .
Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .