The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.58, opennews (?), 14-Янв-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 14-Янв-22, 10:46 
---
// Ранее поддерживались конструкции:
   println!("Hello, {}!", get_person());
   println!("Hello, {0}!", get_person());
   println!("Hello, {person}!", person = get_person());

   // теперь можно указывать
   let person = get_person();
   println!("Hello, {person}!");
---

C in RUST is for Consistency.

Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск языка программирования Rust 1.58"  +3 +/–
Сообщение от Онаним (?), 14-Янв-22, 10:52 
(мысль в следующем: какой уровень костыльности пришлось нагородить для обработки специального оператора в аргументе...)
Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск языка программирования Rust 1.58"  +6 +/–
Сообщение от еуые (?), 14-Янв-22, 10:55 
Это же макрос (восклицательнй знак на конце это показывает),
какие специальные операторы и аргументы?
Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск языка программирования Rust 1.58"  –4 +/–
Сообщение от Онаним (?), 14-Янв-22, 10:55 
Вы видите восклицательный знак в "person = get_person()", или он в хрусте воображаемый?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск языка программирования Rust 1.58"  –3 +/–
Сообщение от Онаним (?), 14-Янв-22, 10:59 
И... вот это макрос?
"Hello, {person}!"
То есть там {}! и он выведет "Hello, motherfucker", а не "Hello, motherfucker!", и для последнего надо писать "Hello, {person}!!"?
Это кошмар.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 14-Янв-22, 11:03 
(я бы понял {person!}, но если вы не ошиблись и там всерьёз {person}! - это просто адешник)
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Аноним (32), 14-Янв-22, 11:23 
Что сказать то хотел?
Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск языка программирования Rust 1.58"  –2 +/–
Сообщение от Аноним (93), 14-Янв-22, 14:22 
что если выполняется условие, то это просто адешник.
внимательнее читайте комментарий.
Ответить | Правка | Наверх | Cообщить модератору

188. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Аноним (32), 15-Янв-22, 01:18 
А ты что сказать хотел? Я не пойму, откуда столько ненормальных на опеннете.
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск языка программирования Rust 1.58"  +1 +/–
Сообщение от Аноним (41), 14-Янв-22, 11:40 
Нет, восклицательный знак есть просто в примере.
И кто додумался сделать такой пример, чтобы вводить людей в заблуждение?(
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

88. "Выпуск языка программирования Rust 1.58"  +3 +/–
Сообщение от Аноним (88), 14-Янв-22, 14:01 
> кто додумался сделать такой пример, чтобы вводить людей в заблуждение?

Растаманы, однако.

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от asv (??), 14-Янв-22, 11:40 
Да неужели?
Он выведет "Hello, motherfucker!".

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

113. "Выпуск языка программирования Rust 1.58"  –2 +/–
Сообщение от Аноним (113), 14-Янв-22, 17:02 
О, прикольно, Онаним один восклицательный знак от другого отличить не может... Это же контекст понимать нужно
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

141. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 14-Янв-22, 20:46 
Ну я и говорю - C is for consistency.
На самом деле речь шла про синтаксис x = y в аргументе, и я это явно выделил.
И даже контекста понимать не нужно, но видимо даже это слишком сложно оказалось.
Ответить | Правка | Наверх | Cообщить модератору

231. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Аноним (231), 15-Янв-22, 13:58 
Прямо как именованные параметры в kotlin и python.
Ответить | Правка | Наверх | Cообщить модератору

236. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 15-Янв-22, 16:38 
Ну там они везде, а хрустанутые их прикостылили к принту каким-то таким исключительным образом, что даже переменные для подстановки использовать не получалось - до этой версии.
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск языка программирования Rust 1.58"  +3 +/–
Сообщение от Ordu (ok), 14-Янв-22, 11:56 
println! -- это макрос. Макросы расширяют синтаксис языка. Ну, типа, чтобы не костылить в язык эллипсис только ради printf, и чтобы не закостыливать в язык целиком writeln (как в паскале), можно этот особый случай не трогать, и дать программисту макросы на такие случаи. Макросы собирают AST кода, из тех аргументов, которые ты им всовываешь.

println! разбирает форматную строку и генерит AST нескольких последовательных вызовов для вывода кусков строк и аргументов. Аргументы все должны иметь трейт Display или Debug, каждый из которых сводится к одному методу.

В макросе есть аргумент "person = get_person()", но это не значит, что этот код реально потом останется после раскрытия макроса, потому что макрос может паттерн-матчингом сопоставлять AST этого выражения с $ident = $expr (выкидывая ошибку компиляции, ежели аргумент не подпадает под допустимые паттерны), и потом искать $ident в форматной строке, и вставлять код для вывода $expr.

То есть, в некотором смысле, это и не раст вовсе -- это стандартная библиотека и её стандартные расширения синтаксиса.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

77. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Совершенно другой аноним (?), 14-Янв-22, 13:36 
> Ну, типа, чтобы не костылить в язык эллипсис только ради printf

как минимум переменное число параметров есть не только в *print*(), но и в *scan*(), *exec*() и даже open(). Да и так, бывает очень удобно использовать и в своих функциях (которые не только обёртки над printf()).

Ответить | Правка | Наверх | Cообщить модератору

111. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 14-Янв-22, 16:39 
> как минимум переменное число параметров есть не только в *print*(), но и в *scan*(), *exec*() и даже open().

Есть не только в printf, да. Но если в printf/scanf без этого сложно обойтись, то в exec и open без проблем вообще. Я вот чесслово не понимаю, нахрена нужно было плодить десяток функций exec*, вполне достаточно было бы одной execve.

> Да и так, бывает очень удобно использовать и в своих функциях

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

На самом деле, если посмотреть на код glibc, или даже на документацию, то безумие становится явным:

man 3 printf:

PRINTF(3)                     Linux Programmer's Manual                     PRINTF(3)

NAME
       printf,  fprintf,  dprintf,  sprintf,  snprintf,  vprintf, vfprintf, vdprintf,
       vsprintf, vsnprintf - formatted output conversion

SYNOPSIS
       #include <stdio.h>

       int printf(const char *restrict format, ...);
       int fprintf(FILE *restrict stream,
                   const char *restrict format, ...);
       int dprintf(int fd,
                   const char *restrict format, ...);
       int sprintf(char *restrict str,
                   const char *restrict format, ...);
       int snprintf(char *restrict str, size_t size,
                   const char *restrict format, ...);

       #include <stdarg.h>

       int vprintf(const char *restrict format, va_list ap);
       int vfprintf(FILE *restrict stream,
                   const char *restrict format, va_list ap);
       int vdprintf(int fd,
                   const char *restrict format, va_list ap);
       int vsprintf(char *restrict str,
                   const char *restrict format, va_list ap);
       int vsnprintf(char *restrict str, size_t size,
                   const char *restrict format, va_list ap);

А в glibc ещё есть asprintf и vasprintf. А ещё есть исторические *wprintf*. А, ещё в ncurses есть *printw, тоже дублированные. Функций было бы в два раза меньше, если бы аргументы передавались бы указателем на массив. Истинно говорю -- это путь к безумию.

Ответить | Правка | Наверх | Cообщить модератору

122. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Аноним (122), 14-Янв-22, 17:36 
> типа передать массив с аргументами

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

Ответить | Правка | Наверх | Cообщить модератору

155. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Ordu (ok), 14-Янв-22, 22:16 
> Передача на стеке экономичнее создания списка.

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

Ответить | Правка | Наверх | Cообщить модератору

162. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Аноним (122), 14-Янв-22, 22:40 
> Не список, а массив

Массив каких типов нужно создать, чтобы передать int32, int64, float и char[]? Это ж придётся где-то отдельно под каждый элемент выделить память, а потом создать массив из ссылок? Костыль.

Ответить | Правка | Наверх | Cообщить модератору

176. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 14-Янв-22, 23:22 
>> Не список, а массив
> Массив каких типов нужно создать, чтобы передать int32, int64, float и char[]?
> Это ж придётся где-то отдельно под каждый элемент выделить память, а
> потом создать массив из ссылок? Костыль.

А, ну да. Ты прав. Я когда тот пост писал, у меня к концу execl попутался в голове с printf'ом. В printf'е как массивом не удастся выкрутиться, потому что аргументы разнотипны, как ты и говоришь. То есть весь тот мой аргумент, скорее про execl.

Эллипсис как раз создаёт на стеке структуру, которая как бы массив, но с разнотипными элементами. И вот это как раз костыль. Если ты запиливаешь в язык такую возможность, то запили её как следует. Возьми и дай возможностей такую структуру создавать, дай методов для работы с ней, типа добавления элемента в конец или перечисления этих элементов. Так, чтобы результат можно было бы использовать везде, где это нужно, и так как это нужно: например создать такую структуру на куче, или внутри другой структуры. Но тут у Ритчи возникла сложность: у него на уме был ровно один use-case для эллипсиса -- printf. Но невозможно с одного use-case'а сделать грамотное обобщение и запилить вменяемый API под это. Поэтому он, будучи грамотным инженером, запилил костылик, который умеет ровно то, что нужно ему. При этом, способы работы с va_list вовсе не были стандартизованы хрен его знает сколько времени. Я не знаю, как там Ритчи с этим справлялся, не удивлюсь, если он научил компилятор складывать произвольное количество аргументов на стек, а извлекал их оттуда ассемблерными вставками.

Но есть же другой способ -- макроязык. Пускай программист пилит такие костыли, какие ему угодно. Зачем костыли совать в спецификацию языка? Костыли сложно сопровождать, но когда ты выкидываешь их в библиотеку, то когда они тебе начнут мешать, ты сможешь взять и выкинуть. А пользователи этих костылей, если им так надо, будут иметь выбор -- либо переписать свой код, либо подобрать выкинутые костыли, собрать их в отдельную библиотеку и продолжить ими пользоваться. И если мы гипотетически предположим выкидывание println! из rust'ового std, то это приведёт лишь к появлению на crates.io крейта println. Если мы попробуем выкинуть эллипсис из C, то поднимется такой вой, что... ненене, пускай этот костыль лучше будет вечным.

Ответить | Правка | Наверх | Cообщить модератору

307. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Совершенно другой аноним (?), 17-Янв-22, 09:31 
> Например когда и зачем? Ты можешь привести последнюю функцию такого рода, которую
> ты писал? Я по-моему ничего не писал с эллипсисом, кроме обёрток над printf.

ну, если Вы это не делали, не значит, что этого не делает никто. В моих трёх самописных библиотеках, которые активно используются в моих проектах вполне себе имеются функции с переменным числом параметров, которые не являются при этом чем-то, аналогичным printf(). Одна - это функция проверки пути в XML DOM, вторая - функция установки значения макроса в макробиблиотеке, третья - обобщённый поиск сведений по специфичной базе сведений.

> А ещё есть исторические *wprintf*.

не совсем, это *printf*() работающий с wchar_t.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

310. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 17-Янв-22, 10:11 
>> Например когда и зачем? Ты можешь привести последнюю функцию такого рода, которую
>> ты писал? Я по-моему ничего не писал с эллипсисом, кроме обёрток над printf.
> ну, если Вы это не делали, не значит, что этого не делает
> никто.

Да, я понимаю, поэтому и спрашиваю: "как ты используешь эллипсис".

> Одна - это функция проверки пути в XML DOM,

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

int check_path(size_t length, DOMElement path[]);

Или я не правильно понял, в чём собственно идея эллипсиса в такой функции? Если так, то в чём?

> вторая - функция установки значения макроса в макробиблиотеке,

Непонятно совершенно. Что значит "установка значения макроса"? Что такое "макробиблиотека"? Какое это отношение имеет к эллипсису?

> третья - обобщённый поиск сведений по специфичной базе сведений.

А тут при чём эллипсис?

Видишь в чём фишка: я уверен, что Ритчи совершил ошибку добавляя эллипсис в C. И я сильно сомневаюсь, что кто-то может придумать применения эллипсису, которые будут лучше, чем другие способы проектирования API. И более того, я уверен, что все кто думает иначе, просто не понимают как надо писать программы на C. Поэтому когда ты заявляешь "я использую эллипсис", я делаю вывод, что ты не умеешь писать на C. Именно поэтому мой вопрос не о том, как часто ты используешь эллипсис, а о том, как ты его используешь: в конце-концов я могу ошибаться в отношении эллипсиса, и мне было бы интересно пофиксить свою ошибку. Но для этого мне нужен вполне реальный конкретный пример, в котором эллипсис будет действительно лучше всех остальных способов. Если тебе интересно в этом поучаствовать, ты можешь сочинить пример, или позаимствовать из чужого кода -- я не против. Но это должен быть реальный пример. Лучше конечно несколько, чтобы можно было бы оценить частоту того, как часто такое может быть нужно.

Ответить | Правка | Наверх | Cообщить модератору

312. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Совершенно другой аноним (?), 17-Янв-22, 11:36 
>[оверквотинг удален]
>> Одна - это функция проверки пути в XML DOM,
> Это в смысле элементы пути передаются отдельными аргументами? Если так, то в
> чём была мотивация использовать эллипсис, если эллипсис ограничивает длину пути, который
> возможно передать: если в коде вызова такой функции три аргумента-элемента пути,
> значит она проверит путь длиной в три элемента. То есть длина
> проверяемого пути должна быть известна на этапе компиляции. Это ограничение никак
> не мешало? Его при этом легко снять, передавая массив элементов пути:
> int check_path(size_t length, DOMElement path[]);
> Или я не правильно понял, в чём собственно идея эллипсиса в такой
> функции? Если так, то в чём?

интерфейс:
int xml_check_path(struct xml_node* xr, struct xml_node** xn, unsigned int nt, ...);

вызов:
    if (xml_check_path(x.x_tree, &xr, 3, "root", "tpl", "config") != 3)

Да, ничто не мешало сделать:

int xml_check_path(struct xml_node* xr, struct xml_node** xn, unsigned int nt, char* attr[]);

и вызывать:
char* attrs[] = { "root", "tpl", "config" };
...

    if (xml_check_path(x.x_tree, &xr, sizeof(attrs) / sizeof(attrs[0]), attrs) != 3)

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

>> вторая - функция установки значения макроса в макробиблиотеке,
> Непонятно совершенно. Что значит "установка значения макроса"? Что такое "макробиблиотека"?
> Какое это отношение имеет к эллипсису?

Есть библиотека, реализующая собственный макроязык. В частности у неё есть API:

int macro_set(MACRO m, const char* macro, int lmacro, unsigned int flags, ...);

Макросы бывают разных типов (строковые, целочисленные, с плавающей запятой).

>> третья - обобщённый поиск сведений по специфичной базе сведений.
> А тут при чём эллипсис?

При том, что есть одна функция поиска по такой базе (это не СУБД, а просто набор сведений о блоках, каналах, датчиках с определённой иерархией):

int pod2_GetInfoBy(CONF2 h,
         struct pod_block* InfoConfigTypeBlockV,
         struct pod_channel* InfoConfigChannelV,
         struct pod_gauge*     InfoConfigGaugeV,
         unsigned int field, ... );

и куча удобных обёрток:

#define pod2_GetBlockInfoByTypeBlk2(h, tb, ib) \
        pod2_GetInfoBy2((h), (ib), NULL, NULL, 1, (tb))

#define pod2_GetBlockInfoByCodTypeBlk2(h, cb, ib) \
        pod2_GetInfoBy2((h), (ib), NULL, NULL, 2, (unsigned int)(cb))

#define pod2_GetBlockInfoByTypeBlkTypePSO2(h, tb, tp, ib) \
        pod2_GetInfoBy2((h), (ib), NULL, NULL, 5, (tp), (tb))

#define pod2_GetBlockInfoByCodTypeBlkTypePSO2(h, cb, tp, ib) \
        pod2_GetInfoBy2((h), (ib), NULL, NULL, 6, (tp), (unsigned int)(cb))

#define pod2_GetBlockInfoByTypePSO2(h, tp, ib) \
        pod2_GetInfoBy2((h), (ib), NULL, NULL, 4, (tp))

>[оверквотинг удален]
> использую эллипсис", я делаю вывод, что ты не умеешь писать на
> C. Именно поэтому мой вопрос не о том, как часто ты
> используешь эллипсис, а о том, как ты его используешь: в конце-концов
> я могу ошибаться в отношении эллипсиса, и мне было бы интересно
> пофиксить свою ошибку. Но для этого мне нужен вполне реальный конкретный
> пример, в котором эллипсис будет действительно лучше всех остальных способов. Если
> тебе интересно в этом поучаствовать, ты можешь сочинить пример, или позаимствовать
> из чужого кода -- я не против. Но это должен быть
> реальный пример. Лучше конечно несколько, чтобы можно было бы оценить частоту
> того, как часто такое может быть нужно.

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

Ответить | Правка | Наверх | Cообщить модератору

318. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 17-Янв-22, 14:47 
> Естественно, можно и без "...", так и без многих вещей можно жить
> и заменять их каким-либо другими, которые есть.

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

Тут, насколько я вижу, эллипсис создаёт ненужных ограничений, в том смысле что мы при вызове должны знать статически, что именно передаётся и в каком количестве, но это никак не помогает вызываемой функции знать статически чего и сколько ей передали, соответственно все надежды на какую-либо оптимизацию основанную на этом идут прахом. При этом, совершенно определённо, эллипсис отменяет проверку типов аргументов во всех случаях. С xml_check_path, например, ты хочешь, чтобы &rest аргументы были бы типа char*, но xml_check_path с радостью сожрёт всё что угодно. С последним примером, мне вообще непонятно, зачем всё это, если всё равно ты пишешь обёртки: сделай обёртки инлайн-функциями, которые соберут массив из аргументов и присунут его в pod2_GetInfoBy. И её тоже сделай inline-функцией, если это возможно, тогда компилятор и от массива избавится, если он тебя напрягает. Но заметь: все типы каждого аргумента будут чётко и строго проверяться.

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

#define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
xml_check_path(чёта-там, ATTRS("one", "two", "three"));

Опять же: типы всех аргументов будут проверяться статически, только что терминировано нулём, что дальше потребует именно последовательной работы с аргументами. Можно xml_check_path сделать макросом, и передавать массив с длиной его, но я не знаю хорошего способа посчитать количество элементов __VA_ARGS__, возможно придётся дважды из них делать массив -- один раз, чтобы передать указатель на него, второй раз чтобы посчитать его размер sizeof'ом. Да и в конце-концов, твой "наглядный код", всё равно явным образом указывает количество, так что, если писать:

xml_check_path(чёта-там, 3, ATTRS("one", "two", "three"));

то в сравнении с твоим это хуже только тем, что добавляется ATTRS.

Ответить | Правка | Наверх | Cообщить модератору

324. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Совершенно другой аноним (?), 17-Янв-22, 16:16 
> А наглядность кода -- там можно выкрутиться и без эллипсиса:
> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
> xml_check_path(чёта-там, ATTRS("one", "two", "three"));

да, одна проблема, что используется C89 в варианте от Microsoft, в котором нет __VA_ARGS__ и много чего ещё.

Ответить | Правка | Наверх | Cообщить модератору

345. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 18-Янв-22, 01:27 
>> А наглядность кода -- там можно выкрутиться и без эллипсиса:
>> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
>> xml_check_path(чёта-там, ATTRS("one", "two", "three"));
> да, одна проблема, что используется C89 в варианте от Microsoft, в котором
> нет __VA_ARGS__ и много чего ещё.

Ну и кто тут ССЗБ?

Ответить | Правка | Наверх | Cообщить модератору

352. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Совершенно другой аноним (?), 18-Янв-22, 11:58 
>>> А наглядность кода -- там можно выкрутиться и без эллипсиса:
>>> #define ATTRS(...) ((char*[]){__VA_ARGS__, NULL})
>>> xml_check_path(чёта-там, ATTRS("one", "two", "three"));
>> да, одна проблема, что используется C89 в варианте от Microsoft, в котором
>> нет __VA_ARGS__ и много чего ещё.
> Ну и кто тут ССЗБ?

К сожалению такая область деятельности, в которой приходится сопровождать аппаратное и программное обеспечение по 20+ лет.

Ответить | Правка | Наверх | Cообщить модератору

353. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Ordu (ok), 18-Янв-22, 12:24 
Это не меняет того, что эллипсис тебе нужен только потому, что ты пользуешься устаревшим компилятором, в котором эллипсис был запилен костылём, потому что разработчики языка не знали других путей.
Ответить | Правка | Наверх | Cообщить модератору

142. "Выпуск языка программирования Rust 1.58"  –2 +/–
Сообщение от Онаним (?), 14-Янв-22, 20:47 
"person = get_person()", но это не значит, что этот код реально потом останется после раскрытия макроса, потому что макрос может паттерн-матчингом сопоставлять

(!!!!!!!!!!!!!!!!!!!!!!)

Вот именно об этом уровне костылинга и речь.
Мало того синтаксис неочевидный сам по себе, так ещё и вот это.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

156. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Аноним (113), 14-Янв-22, 22:27 
Ты что, наркоман?
у тебя есть 3 варианта:
- просто {}
- {N}, где N - порядковый номер аргумента чтобы переиспользовать их в строке
- {string_id}, где string_id - named argument
Все просто и логично.

Раньше named argument можно было создавать только внутри print!
Сейчас добавили возможность использовать внешнюю переменную как named argument (https://github.com/rust-lang/rfcs/pull/2795)
В примере ! у "{person}!" это вообще часть строки, оно никаким боком не относится к макросу.

Читайте маны, если не понятно https://doc.rust-lang.org/rust-by-example/hello/print.html

Ответить | Правка | Наверх | Cообщить модератору

160. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 14-Янв-22, 22:39 
Ещё один не осиливший. Хотя нет, почти осилил.

"Раньше named argument можно было создавать только внутри print!"

Вот именно об этом и речь - какой уровень костылинга должен иметься, чтобы вот специально в print! засунуть такой синтаксис?

Ответить | Правка | Наверх | Cообщить модератору

163. "Выпуск языка программирования Rust 1.58"  –1 +/–
Сообщение от Онаним (?), 14-Янв-22, 22:41 
То, что поправили - понятно, видимо единицы адекватных среди пилителей этого добра имеются таки.
Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск языка программирования Rust 1.58"  +1 +/–
Сообщение от morphe (?), 15-Янв-22, 01:08 

До добавления этой штуки было только такое:

    format!("{}, {}, {}", "a", "b", "c")
    // Либо с явным указанием позиций аргументов
    format!("{1}, {2}, {3}", "a", "b", "c")

В случае если форматированная строка большая - то это было неудобно и запутанно, однако инфраструктура для макросов не позволяла реализовать полноценный захват из внешнего контекста (Не было нормальной гигиены для proc macro), поэтому передачу именованных аргументов сделали явной, и на месте:

    format!("{a}, {b}, {c}", a = "a", b = "b", c = "c")

Теперь же реализована возможность неявно захватывать внешние переменные

    let a = "a";
    format!("{a}");

Однако не всегда нам нужны такие переменные, если мы собираемся использовать лишь в макросе форматирования, поэтому во многих случаях остаётся полезен синтаксис со внутренней передачей именованных аргументов, нововведение помогает лишь в тех случаях, когда раньше приходилось писать a = a, b = b, c = c

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

222. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от Аноним (222), 15-Янв-22, 13:06 
>  format!("{1}, {2}, {3}", "a", "b", "c")

только, как я понимаю, индексация начинается с нуля

Ответить | Правка | Наверх | Cообщить модератору

250. "Выпуск языка программирования Rust 1.58"  +/–
Сообщение от morphe (?), 15-Янв-22, 19:14 
>>  format!("{1}, {2}, {3}", "a", "b", "c")
> только, как я понимаю, индексация начинается с нуля

Да, опечатался)

Ответить | Правка | Наверх | Cообщить модератору

158. "Выпуск языка программирования Rust 1.58"  +1 +/–
Сообщение от Ordu (ok), 14-Янв-22, 22:28 
> Вот именно об этом уровне костылинга и речь.

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

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

161. "Выпуск языка программирования Rust 1.58"  –2 +/–
Сообщение от Онаним (?), 14-Янв-22, 22:39 
Бггг, спасибо, ребята, я уж лучше на что-нибудь менее костыльное посмотрю.
Ответить | Правка | Наверх | Cообщить модератору

169. "Выпуск языка программирования Rust 1.58"  +1 +/–
Сообщение от Ordu (ok), 14-Янв-22, 22:57 
> Бггг, спасибо, ребята, я уж лучше на что-нибудь менее костыльное посмотрю.

Такое ощущение, что я тебя уговариваю посмотреть на rust. Ты сам зашёл в новость, и сам смотрел на него, более того ещё и вопросы начал задавать, чтобы посмотреть повнимательнее. А теперь ведёшь себя так, будто тебя кто-то уговаривал.

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск языка программирования Rust 1.58"  –3 +/–
Сообщение от Урри (ok), 14-Янв-22, 13:15 
Лавры log4j не дают покоя.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

98. "Выпуск языка программирования Rust 1.58"  +3 +/–
Сообщение от Аноним (-), 14-Янв-22, 14:38 
>> разворачивающиеся в компайлтайме макросы
> Лавры log4j не дают покоя.

Какой занятный ламеризм.


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру