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

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

Новые блоги и статьи Все статьи Все блоги /
Нейросеть на алгоритме "эстафета хвоста" как перспектива. Hrethgir 06.05.2026 На десерт, когда запущу сервер. Статья тут https:/ / habr. com/ ru/ articles/ 1030914/ . Автор я сам, нейросеть только помогает в вопросах которые мне не известны - не знаю людей которые знали-бы. . .	Асинхронный приём данных из COM-порта Argus19 01.05.2026 Асинхронный приём данных из COM-порта Купил на aliexpress термопринтер QR701. Он оказался странным. Поключил к Arduino Nano. Был очень удивлён. Наотрез отказывается печатать русские буквы. Чтобы. . .	попытка написать игровой сервер на C++ pyirrlicht 29.04.2026 попытка написать игровой сервер на плюсах с открытым бесконечным миром. возможно получится прикрутить интерпретатор питон для кастомизации игровой логики. что есть на текущий момент:. . .	Контроль уникальности выбранного документа-основания при изменении реквизита Maks 28.04.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРемонтСпецтехники", разработанного в КА2. Задача: уведомлять пользователя, если указанная заявка (документ-основание). . .
Благородство как наказание Maks 24.04.2026 У хорошего человека отношения с женщинами всегда складываются трудно. А я человек хороший. Заявляю без тени смущения, потому что гордиться тут нечем. От хорошего человека ждут соответствующего. . .	Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .