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

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

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Учёным и волонтёрам проекта «Einstein@home» удалось обнаружить четыре гамма-лучевых пульсара в джете Млечного Пути Programma_Boinc 01.01.2026 Учёным и волонтёрам проекта «Einstein@home» удалось обнаружить четыре гамма-лучевых пульсара в джете Млечного Пути Сочетание глобально распределённой вычислительной мощности и инновационных. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .