swprintf в MinGW

@Хатобато · Регистрация: 26.07.2015

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

Пишу:

C++
1
2
3
wchar_t s[300];
int i=10;
swprintf(s, 20, "%i",i);

Компилятор показывает ошибку:

invalid conversion from 'int' to 'const wchar_t*' [-fpermissive]|

У ГНУсов сказано:

В Windows эта функция не принимает размер буфера в качестве второго аргумента.

Но если написать без указания размера, как в sprintf, тоже показывает ошибку: вторым аргументом требует size_t.

@COKPOWEHEU · 02.04.2024, 13:39

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

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

Что такое "временные файлы"? Они же наверное не просто для красоты создаются, а чтобы другие программы прочитать могли.

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

Что до строк в приложении, на это ещё влияет среда разработки (ОС), фреймворк(и) и немного используемые библиотеки.

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

@Хатобато · 03.04.2024, 07:42 **[ТС]**

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

Если вы вспомните, я вам еще на первых страницах советовал использовать UTF-16. Также скинул кучу материала, где я объяснял природу юникода в Windows.

Высказывание не сдержало предложения использовать другие функции. По тексту инструкции Microsoft, функции fgetws и fputws аналогичны fgets и fputs, но предназначены для широких строк. Т.е, и в случае с utf-16 применяться должны эти же функции. А тут выяснилось, что смысл их применения ограничивается случаями, в которых требуется перекодировка, а в сотальных случаях это не целесообразно, так как они работают очень медленно.

fgetws — это версия функции fgets для расширенных символов.
fgetws считывает аргумент str wide-character в виде многобайтовой строки или в виде строки с расширенным символом при stream открытии в текстовом режиме или двоичном режиме соответственно.
https://learn.microsoft.com/ru... w=msvc-170

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

И ... это неверно!

Проверено: работает, и работает быстро.

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

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

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

Про неё и речь! Именно: оказывается, что именно utf-8 использовать не стоит, так как потребуется перекодирование. Текст (например, список путей к файлам) в кодировках utf-16 или ansi может быть напрямую передан функциям Windows.

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

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

А что до приложений - смотреть по задаче. Если обработка не планируется (считать строки, вывести строки или там локализация) проще в том же utf-8.

Не уверена, что стандартный Блокнот и другие подобные программы не будут работать с utf-8 медленнее.

Добавлено через 16 минут
Кстати, показательно проталкивание двух идей, которые приведут к замедлению работы: хранение текстов в utf-8 и отказ от BOM в пользу "эвристики". Пишут, что раньше Microsoft предлагала хранить в utf-16, но теперь присоединилась к сторонникам utf-8. Отказу от BOM пока сопротивляется, но может вскоре так же сдаться.

Добавлено через 29 минут
В дополнение к ответу на

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

Ну в смысле что мешает пользоваться обычной utf-8?

Из-за этого же возник и первый вопрос в этой теме! Компилятор MinGW работает только с ansi и utf-8. Пока в тексте программы используется ansi, проблем не возникает, но они возникают при переходе к unicode: в тексте - utf-8, а WinAPI ждут utf -16. Поэтому, для латиницы требуется ставить L, а для кириллицы - ещё и локаль.

@COKPOWEHEU · 03.04.2024, 09:12

Сообщение от Хатобато

Именно: оказывается, что именно utf-8 использовать не стоит

Кто тот вредитель, что так вас обманул?

Сообщение от Хатобато

Текст (например, список путей к файлам) в кодировках utf-16 или ansi может быть напрямую передан функциям Windows.

Ну вот для функций windows и перекодируйте, если они стандартного utf-8 не понимают, основной-то код зачем уродовать?

Сообщение от Хатобато

Не уверена, что стандартный Блокнот и другие подобные программы не будут работать с utf-8 медленнее.

Ну так проверьте. Все равно, повторяю, почти все текстовые файлы сейчас хранятся в utf-8. Что-то другое вы можете получить только с доисторических систем или сайтов. Вот там да, могут быть любые окаменелости, хоть usc-16, хоть cp1251, хоть koi8-r, хоть utf-16.

Сообщение от Хатобато

Пишут, что раньше Microsoft предлагала хранить в utf-16, но теперь присоединилась к сторонникам utf-8.

Потому что utf-16 объективно было плохим решением. Оно объединяет недостатки и utf-8 и utf-32, но не достоинства. Так же, как в utf-8, один символ кодируется несколькими переменными, то есть сделать str[x] уже нельзя. Так же, как в utf-32, требуется больше места для хранения. А вот плюсов ни одного.

Сообщение от Хатобато

Отказу от BOM

Что приятно, в utf-8 этот BOM не особо-то нужен, поскольку он наполовину (0-127) совместим с однобайтными кодировками. А вот utf-16 несовместим.
---
Проверил скорость:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#include <time.h>
#include <sys/time.h>
 
unsigned long get_time_ms(){
  struct timeval tv;
  unsigned long time_ms;
  gettimeofday(&tv,NULL);
  time_ms = tv.tv_usec/1000 + tv.tv_sec*1000;
  return time_ms;
}
 
#define ITERS 1000
 
int main(){
  setlocale(LC_ALL, "");
  FILE *fin = fopen("a.txt", "rt");
  if(fin == NULL){fprintf(stderr, "Can not open\n"); return 0;}
  FILE *fout = fopen("b.txt", "wt");
  if(fout == NULL){fprintf(stderr, "Can not open\n"); fclose(fin); return 0;}
  unsigned long t1 = get_time_ms();
  
#if UTF8
  char buf[4000];
  for(int i=0; i<ITERS; i++){
    while(1){
      char *res = fgets(buf, sizeof(buf)/sizeof(buf[0]), fin);
      if(res == NULL)break;
      fputs(buf, fout);
    }
    rewind(fin);
  }
#elifdef UTF32
  wchar_t buf[1000];
  for(int i=0; i<ITERS; i++){
    while(1){
      wchar_t *res = fgetws(buf, sizeof(buf)/sizeof(buf[0]), fin);
      if(res == NULL)break;
      fputws(buf, fout);
    }
    rewind(fin);
  }
#else
  #error define either UTF8 or UTF32
#endif
 
  fclose(fin);
  fclose(fout);
  unsigned long t2 = get_time_ms() - t1;
  printf("dt = %lu ms / %i iters => %.3f ms/it\n", t2, ITERS, (float)t2/ITERS);
}

Исходный файл из полумегабайта 1000 раз построчно копируется в выходной. В результате переработать приходится пол-гигабайта. Сначала в родной кодировке, потом в utf-32 (wchar_t). Вот на основной машине:

Code
1
2
3
4
5
6
$ gcc main.c -Os -DUTF8
$ ./a.out 
dt = 2003 ms / 1000 iters => 2,003 ms/it
$ gcc main.c -Os -DUTF32
$ ./a.out 
dt = 75338 ms / 1000 iters => 75,338 ms/it

utf-8 выигрывает в 38 раз
Вот на виртуалке с winXP:

Code
1
2
3
4
5
6
7
# $ i686-w64-mingw32-gcc main.c -Os -DUTF8
C:\dev>a.exe
dt = 9303 ms / 1000 iters => 9,303 ms/it
 
# $ i686-w64-mingw32-gcc main.c -Os -DUTF32
C:\dev>a.exe
dt = 82138ms / 1000 iters => 82,138 ms/it

Выигрыш utf-8 в 9 раз. Возможно, потому что в винде wchar_t считается utf-16.

Сообщение от Хатобато

WinAPI ждут utf -16

Ну да, с winapi всегда были проблемы. Лишний повод поменьше их использовать.

@SmallEvil · 03.04.2024, 10:37

Сообщение от Хатобато

Сообщение от SmallEvil
И ... это неверно!
Проверено: работает, и работает быстро.

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

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

Сообщение от Хатобато

Про неё и речь! Именно: оказывается, что именно utf-8 использовать не стоит, так как потребуется перекодирование.

Смысл хранить файлы в utf-8 - экономия места на носителе.
Какие то необоснованные размышления про "тормоза" - просто глупость.
Если нам нужно заархивировать файл, мы же не плачем : "о он же так систему грузит, ипучий тормоз"

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

Сообщение от Хатобато

Компилятор MinGW работает только с ansi и utf-8.

Это не так. При подаче файлов компилятору можно указать в какой он кодировке.

@Хатобато · 03.04.2024, 11:57 **[ТС]**

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

У вас будут проблемы с переносами строк.

Я уже писала: конец строки определяется правильно.

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

Смысл хранить файлы в utf-8 - экономия места на носителе.

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

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

Какие то необоснованные размышления про "тормоза" - просто глупость.

Время замеряла неоднократно, в разных вариантах: fgetws-fputws везде работают намного медленнее. Тормозят, даже если строки в одном формате сразу передаются между ними.

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

Это не так. При подаче файлов компилятору можно указать в какой он кодировке.

Пока все попытки указать utf-16 приводили к тому, что компилятор видит ошибку в каждом символе. А тут мне посоветовали только использовать utf-8.

@SmallEvil · 03.04.2024, 12:08

Сообщение от Хатобато

Тогда уж лучше хранить в ansi: чем плохо, если всё ограничивается латиницей и кириллицей?

Ну так храните.
Никто вас не заставляет. Только потом не плачьте.

Сообщение от Хатобато

Я уже писала: конец строки определяется правильно.

В вашем конкретном случае.
https://ru.wikipedia.org/wiki/... #В_Юникоде
Если вас это устраивает, опять же, делайте как хотите.
Но потом пеняйте на себя.
Когда ваша программа начнет чудить по полной с другим файлом, вполне валидным по стандарту Юникода.

Добавлено через 1 минуту
То есть, у вас всё работает. вы не хотите ничего узнать, понять как делать правильно ?
Если на этом всё, тогда и говорить не о чем.

@Хатобато · 03.04.2024, 12:21 **[ТС]**

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

Ну вот для функций windows и перекодируйте, если они стандартного utf-8 не понимают, основной-то код зачем уродовать?

Я и делаю для Windows.

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

Ну так проверьте.

А как это сделать? Я же не могу вставить в Блокнот GetTickCount...

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

Выигрыш utf-8 в 9 раз. Возможно, потому что в винде wchar_t считается utf-16.

Вы же для utf-8 выбрали fgets-fputs, а для utf-16 - fgetws-fputws. Я и говорю о том, что они - тормознутые! С utf-8 тоже тормозят... Только utf-16 можно прочитать fgets и передать WinAPi, а utf-8 потребуется перекодировка (т.е., использование fgetws). Строка из файла с utf-16, полученная fgets и переданная MessageBoxW, отображается правильно, а из utf-8 - нет.

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

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

В вашем конкретном случае.

Везде - 13 и 10

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

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

Поняла, как это делать "правильно" (т.е., по инструкции). Но заторможенность бесит.

@SmallEvil · 03.04.2024, 12:27

Сообщение от Хатобато

Но заторможенность бесит.

Это плата за компактность utf8.
За всё приходится платить.
Плюс Юникода, что он унифицирован.
На данный момент для большинства задач он приемлем.
Чего нельзя сказать про старые ASCII кодировки, да и прочие старые.

Добавлено через 1 минуту
Ах да, используя cp1251 для файлов и ВинАпи, вы опять же упретесь в перекодировку, если вам будет нужно использовать те данные в в ОС АПИ

@Хатобато · 03.04.2024, 12:39 **[ТС]**

Очень похожее явление: время от времени, выпускаются новые версии Windows, которые не устанавливаются на старые компьютеры... Но оказывается, что это - не потребность самой Windows (умудряются "подправить" и установить), а волюнтаристски добавленное условие. А от Apple даже получили признание в умышленном торможении работы старых смартфонов.

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

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

Ах да, используя cp1251 для файлов и ВинАпи, вы опять же упретесь в перекодировку, если вам будет нужно использовать те данные в в ОС АПИ

C WinAPI - только если попадётся кириллица. Но с этим надо отдельно разобраться: получила вдруг от ansi-версии нормальные имена файлов с кириллицей, а ожидала кракозябры...

@SmallEvil · 03.04.2024, 13:43

Сообщение от Хатобато

C WinAPI - только если попадётся кириллица.

У большинства функций винапи есть две версии функций.
A и W, грубо говоря. Есть ещё c постфиксами 1, 2 и ext.

Сообщение от Хатобато

Поняла, как это делать "правильно" (т.е., по инструкции)

По инструкции - это правильно.
Но можно делать и не по инструкции если понимать с чем работаешь.

Например весь файл в UTF16 можно считать с помощью fread.
При этом разбивать на строки нужно будет самому. Что не во всех случаях (задачах) обязательно.

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

Потому что utf-16 объективно было плохим решением.

В то время (когда нехватка ОЗУ чувствовалась особенно остро, а необходимости в расширенных символах была невеликой), это было хорошим компромисом.
По этой же причине никто не хранит файлы в utf32 - компромис.
Не нужно бросаться в крайности.

@COKPOWEHEU · 03.04.2024, 14:04

Сообщение от Хатобато

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

Именно тем, что все ограничивается латиницей и парой спецсимволов. Ни кириллицы, ни греческого, ни других алфавитов. Думаете почему отказались от тех же cp1251 или koi8-r?

Сообщение от Хатобато

Пока все попытки указать utf-16 приводили к тому, что компилятор видит ошибку в каждом символе.

Теоретически, там есть какой-то флаг компилятора. Но это скорее для совместимости с доисторическим кодом, чем для написания современного.

Сообщение от Хатобато

А как это сделать? Я же не могу вставить в Блокнот GetTickCount...

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

Сообщение от Хатобато

Вы же для utf-8 выбрали fgets-fputs, а для ~~utf-16~~ utf-32 - fgetws-fputws.

Конечно. Цель ведь была именно в сравнении скорости.

Сообщение от Хатобато

С utf-8 тоже тормозят...

Нет. Поскольку utf8 -> utf8 не требует перекодировки, все тормоза вызваны работой с диском, буферизацией и т.п. Неспроста разница получилась аж в 38 раз.

Сообщение от Хатобато

utf-8 потребуется перекодировка (т.е., использование fgetws)

Перекодировка делается не так, а через mbstowcs.

Сообщение от Хатобато

Строка из файла с utf-16, полученная fgets и переданная MessageBoxW, отображается правильно, а из utf-8 - нет.

Вы собираетесь гигабайты текста на messagebox-е отображать?!

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

В то время (когда нехватка ОЗУ чувствовалась особенно остро, а необходимости в расширенных символах была невеликой), это было хорошим компромисом.

Это казалось хорошим компромиссом. Потому что порождает больше проблем, чем решает. Вон взять те же A/W функции - в тех системах, где используется utf-8, они просто не нужны.

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

Не нужно бросаться в крайности.

Как раз здесь обе крайности лучше середины.

@Хатобато · 03.04.2024, 16:03 **[ТС]**

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

У большинства функций винапи есть две версии функций.
A и W, грубо говоря. Есть ещё c постфиксами 1, 2 и ext.

Как ни странно, FindFirstFileA и FindNextFileA с WIN32_FIND_DATAA нормально выдают имена с кириллицей. Видимо, проблема с ними возникает только в lazarus.

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

Именно тем, что все ограничивается латиницей и парой спецсимволов.

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

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

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

Перекодировка делается не так

Под перекодировкой я подразумеваю то, что делают эти функции. Если нужны строки, а кодировка - не utf-16, вряд ли стоит использовать fread, разбивать на строки и перекодировать. Хотя, они работают так медленно, что это может оказаться быстрее.

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

Перекодировка делается не так, а через mbstowcs.

А как указать языковой стандарт для русского?

@COKPOWEHEU · 03.04.2024, 16:34

Сообщение от Хатобато

Но ведь кириллица работает

Да неужели? А если кодировка cp1253 (греческая)?

Сообщение от Хатобато

Под перекодировкой я подразумеваю то, что делают эти функции.

Разница в том, что fgetws читает из файла, а mbstowcs - из строки. И перекодировкой можно назвать только последнее.

Сообщение от Хатобато

А как указать языковой стандарт для русского?

Не понял вопрос. Мне казалось, mbstowcs не должен зависеть от локали, это же из юникода-utf8 в юникод-utf32, просто в разных представлениях.

@Хатобато · 03.04.2024, 17:41 **[ТС]**

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

Да неужели? А если кодировка cp1253 (греческая)?

Я же говорю: если нужны экзотичные алфавиты - другая ситуация.

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

Не понял вопрос. Мне казалось, mbstowcs не должен зависеть от локали, это же из юникода-utf8 в юникод-utf32, просто в разных представлениях.

Да. Там приведён набор сходных функций, и только некоторые из них (с "_l" на конце) требуют локаль.

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

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

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

Он захлёбывается на больших файлах, и вряд ли это сильно зависит от скорости чтения с диска. В некоторых случаях просто отказывает из-за величины файла, и предлагает использовать другой редактор.

@COKPOWEHEU · 03.04.2024, 18:44

Сообщение от Хатобато

Я же говорю: если нужны экзотичные алфавиты - другая ситуация.

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

Сообщение от Хатобато

и только некоторые из них (с "_l" на конце)

Что-то мне кажется, что это нестандартные функции от Майкрософта. Если так, ими вообще пользоваться не стоит.
Но да, в документации пишут "NOTES: The behavior of mbsrtowcs() depends on the LC_CTYPE category of the current locale." Значит, тем же setlocale(), без фокусов.

@DrOffset · 03.04.2024, 19:53

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

В то время (когда нехватка ОЗУ чувствовалась особенно остро, а необходимости в расширенных символах была невеликой), это было хорошим компромисом.

Юникод в винде появился в 1993 году, в NT 3.1.
Именно тогда было принято решение применять Utf-16. В то время не было ничего другого, не было Utf-32 (он только с 2003 года), и не было суррогатных пар в Utf-16. Т.е. Utf-16 в то время был как Utf-32 сейчас, одна кодовая единица полностью соответствовала одному символу.
Utf-16 расширили только в 1996 году, в этом же году вышла NT 4.0

Именно по этой причине MS потом перешли на какое-то время на UCS-2, потому что они уже завязались на свойства раннего Utf-16 и нововведение в стандарт юникода им было невозможно поддерживать (код уже написан, систему надо выпускать на рынок, допиливать поддержку юникода под изменишийся стандарт не выгодно; они сделали это позже, к выходу windows xp).

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

В любом случае игнорировать тот факт, что Windows внутри себя использует исключительно Utf-16, не получится. А кто попробует это сделать, получит тормоза на ровном месте из-за постоянных подкапотных перекодировок.

@SmallEvil · 03.04.2024, 20:44

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

В любом случае игнорировать тот факт, что Windows внутри себя использует исключительно Utf-16, не получится. А кто попробует это сделать, получит тормоза на ровном месте из-за постоянных подкапотных перекодировок.

В лучшем случае.
В худшем - не подкапотных, а ручных костылей.

@DrOffset · 03.04.2024, 21:53

Сообщение от Хатобато

Высказывание не сдержало предложения использовать другие функции.

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

Сообщение от Хатобато

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

Признавайтесь, вы же не читали мои ссылки, да?

@COKPOWEHEU · 03.04.2024, 22:46

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

В лучшем случае.
В худшем - не подкапотных, а ручных костылей.

Это ж winapi. Без костылей тут никак.

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

Нужно избавиться от перекодировки, а не использовать другие функции.

Каким образом? Если исходные файлы в юникоде, а виндовые функции понимают только utf-16. Тут увы, без перекодировки не обойтись. Можно только свести ее к минимуму, уменьшив насколько это возможно зависимость от winapi.

@Royal_X · 03.04.2024, 23:46

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

NT 3.1

хорошая ОС, визуально напоминает некоторые сегодняшние дистрибутивы линукса

Новые блоги и статьи Все статьи Все блоги /
Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .
Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .