Покрывают ли макросы Rust возможности #define?

Ну вот, нельзя:

В Расте, макросы должны расширяться в полные выражения, предписания, элементы, типы или шаблоны… в них не может быть несбалансированных скобок и т.п. BEGIN_MESSAGE_MAP() невозможно реализовать в Расте, т.к. в ней несбалансированные фигурные скобки

https://itnext.io/other-reasons-why-rust-is-my-favorite-programming-language-ba6805a6a458

Можно попробовать на proc-macro что-то подобное сделать. Но ценность троллейбуса из буханки черного (или белого) хлеба намного выше.

Если есть какте-то интересные примеры действительно востребованных define-ов - приносите, можно будет посмотреть как их в виде макросов можно переписать (и нужно ли).

я не знаю, что есть BEGIN_MESSAGE_MAP, но раз она существует, то она, видимо, нужна. Догадываюсь, что на Расте оно должно быть оформлено по-другому, так, что в макрос входит вся конструкция:

BEGIN_MESSAGE_MAP
тело
END_MESSAGE_MAP

Ну хорошо. Тут человек просил #ifdef - ему тоже отказали. Он хотел такое:

pub fn funct(&self
#ifdef _YES_
, t: Type0
#endif
) {
#ifdef _YES_
let abc = some_func(SomeType::new());
#else
let abc = some_other_func(SomeOtherType::new());
#endif
}

https://users.rust-lang.org/t/ifdef-like-feature/1753

Можно попробовать использовать cpp для раста перед rustc. макросы же отдельная программа обрабатывает, а не компилятор языка.

Меня в данном случае интересуют решения дизайнеров раста. Я почитал что-то и понял, что там всё изрядно сложно сделано. Понятно, зачем нужна гигиена и т.п. Но если, допустим, у кого-то есть программа на Си и нужно её переводить на Раст, то для каждого макроса нужна методичка. Вот я сейчас и пытаюсь приблизиться к пониманию того, можно ли перевести более-менее линейно по трудозатратам.

Дизайнеры раста делали язык так что-бы он тебе по яйцам давал ещё до компиляции за любой косяк с твоей стороны. Хз как это воспринимать, как защиту от дурака, как дисциплины дрессировку.

есть программа на Си и нужно её переводить на Раст

Зачем? Идешь на поводу моды переписывания всего и вся на Раст?

можно ли перевести более-менее линейно по трудозатратам

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

программа на Си и нужно её переводить на Раст

оберни весь код сишный в unsafe и всунь в раст ))))))))))))))

Ну вообще-то нет, я же написал «допустим». Я хочу перевести программу с Си на Оберон, и больше всего этому мешают макросы. Соответственно, нужно разработать такие макросы для Оберона, чтобы было удобно переводить. Какие-то я уже разработал, а #ifdef там и так уже присутствует. Но всё равно пока непонятно, что делать, т.к. другой порядок слов. Я надеялся, что в расте решали задачу о переписывании, но похоже, что нет. Иначе была бы готовая методичка, как мигрировать с Си на Раст, и такие случаи были бы в ней разобраны. Но может быть, она и есть, просто пока что мне не попалась. Кстати, порядок слов в определении переменной в Расте тоже правильный - как в Обероне, а не неправильный - как в Си.

Я, честно сказать, думаю, что нужно расклассифицировать все макросы: один макрос - это просто константа, другой - выражение, третий - открывающая фигурная и за ней предписание (statement). И для каждого вида сишного макроса сделать соответствующий вид обероновского макроса. Я думал, что в Расте пошли именно этим путём, но нет.

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

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

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

Я думал, что в Расте пошли именно этим путём, но нет.

Нет, потому что в расте очевидно не ставили целью сделать портирование программ на С лёгким. Причины, в общем-то тоже, понятны: если ты предоставишь такие же инструменты как в С, то и писать будут (в том числе) так же как на С. А это помимо преимуществ несёт и недостатки. В контексте языка, который ценен своими ограничениями, в этом мало смысла.

Тут человек просил #ifdef - ему тоже отказали.

Справедливости ради, альтернативные варианты там привели.

Там какая-то наркомания, а не альтернативы.

That will only work if the functions/types exist in all configurations.

Что делать с многомегабайтной россыпью дебаг информации (именования объектов, сохранение костеков на некоторых операциях, россыпь валидаций), которая нужна в дебаге, но не нужна в релизе?

Зачем? Все макросы, которые мне пока что были нужны, сводятся к трем типам:

-- return or continue;
-- переменное число аргументов. Variadic templates во-первых нечитаемая срань, во-вторых серьезно ограничены в способностях, в том числе по причине следующего пункта;
-- сгенерить структуры данных|декларации типов на основе других. При том, что в C++ шаблоны принципиально плохо дружат с методами-полями классов и замыканиями, то есть, с любыми составными сущностями, и тот факт, что есть функторы, что можно создать нужную декларацию класса рекурсивным наследованием в шаблоне, эту проблему никак не отменяют, а лишь являются поводом не пытаться ее решать.

Но для этого не нужны макросы. Предлагаю продолжать список.

Есть отдельная проблема передачи куска кода аргументом, но она более-менее решается замыканиями, хотя это спорно. Ублюдочные итераторы C++, смоделированные по подобию циклов Си, возникли именно потому, что в C++ не было возможности сделать проход по нетривиальному контейнеру функциями этого контейнера — вместо этого проход делался вовне через вызовы примитивов, что дает весьма проблематичные затруднения для любого контейнера, отличного от «непрерывный массив значений», поскольку не всегда можно заставить внешний код правильно обращаться с твоими структурами.

В контексте языка, который ценен своими ограничениями, в этом мало смысла.

Да неважно, почему. Просто там так решили, это их дело. Может, надо тогда написать вместо конверетера с Си конвертер с раста… Т.к. уровень хаоса в коде изначально ниже. Впрочем, это может оказаться за пределами моих возможностей.

Но для этого не нужны макросы.

Ну ты же вроде знаешь Си и Си++ - в дикой природе макросов полно.

Справедливости ради, альтернативные варианты там привели.

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

Ну ты же вроде знаешь Си и Си++ - в дикой природе макросов полно

В C++ макросов очень мало, по большей части это лишь инклуды и условная компиляция — и то условная компиляция часто может быть выполнена без макросов.

Больше интересует Си.

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

НДА. Так-то конечно связный список естественным образом порождает гонки. Надо заводить новую тему.

по большей части это лишь инклуды и условная компиляция

я, кстати, неправильно назвал тему, имелось в виду «возможности препроцессора». инклюды и условная компиляция туда тоже относятся.

Больше интересует Си

Си — безнадежно устаревшее еще в 1973 году говно, тут нечего обсуждать. Я пишу на Си только потому, что мой паскаль никому не нужен, какой-нибудь эйфиль и прочие сдохли, а Rust идет по пути усложнения работы программиста.

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

То, что на Си как два пальца об асфальт, как связный список, на Расте как каменный цветок родить. Вот и думай.

НДА. Так-то конечно связный список естественным образом порождает гонки. Надо заводить новую тему

Меня больше поражает, что стандартная либа в Rust застряла где-то на уровне 80-х годов, то есть, однопоточные контейнеры под блокировками, для которых даже связанный список уже «гонки, низзя». Даже сейчас, когда я пишу на крестах за денюжку, меня вообще не тянет штудировать STL, потому что STL — по большей части засохшее говнище из каменного века, а хэш-таблица пишется за день. При этом за два дня хэш-таблицу можно сделать многопоточно, а контейнеры STL расширить невозможно. Хотя бы привязать группу контейнеров к экземпляру аллокатора ты не можешь, только весь тип можно привязать. Ту же ошибку успешно повторяет Rust. Это только одна из ошибок, бездумно скопированных разрабами Rust из C++.

Приходи в новую тему, Rust и двусвязный список

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

Так я как раз и хочу забрать код из Си в Паскаль (в Оберон), но этому мешает препроцессор. Причём мешает не твой список, а реальное разнообразие макросов из дикой природы

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

Ну я думаю, что правильным будет определить классы макросов по возможностям, и для каждого класса придумать свой отдельный костыль. А оставшиеся 3% отрефакторить до перевода. Другое дело, что пока я не решился по-настоящему этим заниматься. Компьютеры - зло, об этом я всегда помню. Языки программирования такие уродливые по той причине, что Бог не попускает компьютерам истребить людей слишком быстро, а даёт людям шанс спастись. Поэтому я приветствую Раст, как новую уловку, которая мешает программировать эффективно. А лисп закопал, почти не вспоминаю про него.

Можно процедурным макросом. Но лучше не надо.

Ну я думаю, что правильным будет определить классы макросов по возможностям, и для каждого класса придумать свой отдельный костыль. А оставшиеся 3% отрефакторить до перевода

В Си макросы — это инклуды, константы, инлайн функции. До C99 там не было инлайн функций, так что повально юзали макросы — в GCC даже есть расширения для возврата значения из макроса. У нас вон в хттп-акселераторе макросы вместо инлайна применяли просто потому, что Си умеет конкатенировать только константы, а константу аргументом передать нельзя, потому строка-аргумент макроса пробрасывалась через цепочку макросов, чтобы в конце сделать compile-time конкатенирование.

Оставшиеся 3% макросов типа «кодогенерация» и «шаблоны» — это боль и страдание, даже для опытного сишника вроде меня. Самое плохое в сишных макросах то, что их «класс» нельзя определить. Да, есть макросы с аргументами и без, но по факту это ничего не говорит про функцию этих макросов. Так что сорян — только руками. Результат работы препроцессора — Тьюринг-полный, а свойства Тьюринг-полной программы невозможно програмно определить в общем случае.

Языки программирования такие уродливые по той причине, что Бог не попускает компьютерам истребить людей слишком быстро, а даёт людям шанс спастись

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

Поэтому я приветствую Раст, как новую уловку, которая мешает программировать эффективно. А лисп закопал, почти не вспоминаю про него

Ну раст тут не одинок. Однако, мне, как художнику, нет-нет, да и хочется пописать на чем-то чистом и незапятнанном долларом. Но за это не заплатят.

Я уже почти зарыдал. дай пять.

Ну раст тут не одинок

Они все такие. Вот как у евреев рисуют человека с изъянами, чтобы обойти запрет на изображение человека. Так же и все ЯП - там обязательно есть очевидный изъян, как будто нарочно вставленный. Причём старые повторно используют, а новые искусно придумывают. Очень тяжело преодолеть искушение сделать язык без вставленных изъянов.

Очень тяжело преодолеть искушение сделать язык без вставленных изъянов

Кому тяжело? Мне легко — другое дело, что господь мне претит. С подачи власть имущих общество стало устроено так, что ты сдохнешь с голоду, если будешь думать о чем-то, кроме денег — но именно по этой причине стандарт ЯП будут писать те, кто больше всего думает о деньгах и меньше всего думает про ЯП. Да, Керниган, Ритчи, Гвидо, и прочие не думали ни о чем, когда писали свои ЯП — «думали» потом манагеры, принимавшие эти ЯП без архитектуры в качестве индустриального стандарта. А как ты думаешь, какие конструктивные предложения в устройство космической ракеты может предложить пастух? Какое решение о в принципе способен вообще сделать? «Поставьте больше двигателей карощ, клянусь своими баранами»? Вот так и получается: принимает то, где больше рюшечек, то есть фич, то есть двигателей. При том, что для ЯП, как и для ракеты, основное требование — это быть как можно легче и проще.

Да ладно, ты программист, находишься в топ 10% людей в данной российской стране (если ты тут, конечно). Да и в любой другой, если ты, конечно, не подписал кабального контракта, чтобы попасть в рай. Притом, в отличие от какого-нибудь чиновника или депутата ты не повязан никакой уголовщиной и можешь спокойно спать по ночам. Я работаю на полставки и ты можешь. У тебя будет куча свободного времени, делай что хочешь. Я вообще-то написал порядка 80 страниц спецификации на «Яр» и мне никто за это не платил. Но я подумал и быстренько убрал их из сети.

Да, Керниган, Ритчи, Гвидо, и прочие не думали ни о чем

Гвидо сделал не так уж плохо для любителя, Керниган и Ритчи были давно, но в целом всё под контролем спецслужб. Языки, кроме того, что мешают эффективно разрабатывать, ещё и помогают вставлять закладки, и это хорошо, т.к. тоже отодвигает победу компьютера над человеком.

Керниган и Ритчи были давно, но в целом всё под контролем спецслужб. Языки, кроме того, что мешают эффективно разрабатывать, ещё и помогают вставлять закладки, и это хорошо, т.к. тоже отодвигает победу компьютера над человеком

Если там и были спецслужбы, то это случилось уже сильно «потом». А «сначала» на этот вопрос даже не обращали внимание, потому что сетей как таковых толком не было. Только с достаточно массовым распространением сетей стало ясно, что любой софт на Си дырявый как друшлаг, что можно делать затыкать дырочки. делать их меньше и еще меньше, но все равно какое-то количество остается.

Гвидо сделал не так уж плохо для любителя

Кокого любителя? Я могу оправдать PHP, этот ЯП действительно завоевал нишу — нишу «выполни мой сайт на 2 МБ оперативы и 10 МБ дискового пространства», по сравнению с которой современный облачный хостер и прочие амазоны выглядят венцом грабительских цен при смехотворном выхлопе. Но питон ничего не завоевывал. Как и руби, это был noname язык, который однажды был подхвачен корпорацией (гуглом и эплом соответственно). Мне иногда кажется, что если завтра в амазоне решат, что сотрудникам положено носить говно на голове — всё IT спустя пару лет будет ходить с говном на голове.

Я не знал про эту историю успеха Питона. Думал, что он из толщи народа сам пророс.

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

Так и делал эн лет, потом решил, что пора бы заработать. Тоже понравилось. Можно чередовать.

Если там и были спецслужбы, то это случилось уже сильно «потом».

Угу, Крипто АГ на тот момент уже пару десятилетий успешно доставляля разведданные, а сама по себе Bell Labs изначально занималась связью. Конечно, понимание, что компьютеры будут использоваться в сетях, случилось «потом» и никто заранее ничего не задумывал.

или вот, нагуглил за 3 минуты такую цитатку:

История технологии голосовой связи начинается в 1876 году с изобретения Телефон Александра Грэхема Белла. В 1890-х годах «правоохранительные органы начинают прослушивать провода первых телефонных сетей». Удаленная голосовая связь «осуществлялась почти исключительно с помощью систем с коммутацией каналов», когда телефонные коммутаторы соединяли провода, образуя непрерывную цепь, и отключали провода по окончании разговора). Все другие телефонные услуги, такие как переадресация вызовов и прием сообщений, выполнялись операторами-людьми. Однако первый компьютеризированный телефонный коммутатор был разработан Bell Labs в 1965 году. Это позволило избавиться от стандартных методов прослушивания телефонных разговоров.

Притом, если ты почитаешь историю про Крипто АГ, то там очень узкий круг лиц среди сотрудников был в теме. В т.ч. они там недосмотрели за кадрами и наняли какую-то чрезмерно умную девушку, которая нашла и самовольно поправила «баги» в машинках. Её вроде не убили, но с той работы убрали. Т.е. даже задача прятать закладки от собственных сотрудников на тот момент должна была быть вполне очевидной, исходя из политики минимального разглашения сведений о закладках.

Я не знал про эту историю успеха Питона. Думал, что он из толщи народа сам пророс

Ну ты сам подумай, для чего нужен питон «толще народа»? Вебсайты хостить? Для питона хостинга сравнимого нет до сих пор. Научные вычисления? Может быть, но оно еле ползает, хуже только APL — а тогда вообще как черепаха было. Машинное обучение? Та же проблема в квадрате, ведь там уже реально нужна производительность, a+b считать сто раз в секунду недостаточно.

Крипто АГ на тот момент уже пару десятилетий успешно доставляля разведданные, а сама по себе Bell Labs изначально занималась связью

Crypto AG было намного раньше сишки и компов вообще, и сишкой не занималось.

Однако первый компьютеризированный телефонный коммутатор был разработан Bell Labs в 1965 году. Это позволило избавиться от стандартных методов прослушивания телефонных разговоров

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

Сrypto AG было намного раньше сишки и компов вообще, и сишкой не занималось.

Да, но аналитики на государственном уровне прекрасно понимали тенденции развития техники и связи. Мало того, одно из первых промышленных применений лампового компьютера было именно в области криптографии (дико засекреченный компьютер «Колосс»). Поэтому государство должно было понять, куда дует ветер, оценить направления развития техники и предусмотреть для себя плацдарм в этой области. Я не верю, что в США такие тупые спецслужбы, что этого не сделали, если даже какой-то там посудомойщик Оруэлл до этого додумался. А широким массам может быть внедрение компьютеров и построение сетей - да, изначально не было очевидно.

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

Ого, там даже фамилия Хаббард всплывает. Ну всё норм - у Гейтса дедушка был одним из учредителей ФРС, а потом его внук, стеснительный очкарик, стал акулой мирового бизнеса. Вот что генетика животворящая делает! Стальной характер и предпринимательская жилка передаются по наследству. Но про Хаббарда не будем копать.

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

https://ru.wikibrief.org/wiki/Bell_System

Crypto AG было намного раньше сишки и компов вообще, и сишкой не занималось.

цитирую Хабр:

Через два года, в 1967, Crypto выпустила новую, полностью электронную модель, H-460, чьё устройство было полностью разработано в АНБ.

А Си начали разрабатывать ещё через два года. Здесь не могу не вспомнить, что модуль LSM тоже разработан в АНБ. А хвалёная безопасность Астра Линукса во многом на нём основана. Поправьте меня пожалуйста, где я не прав.

А, нет, разработан не АНБ, а лишь при участии АНБ.

Ну ты сам подумай, для чего нужен питон «толще народа»?

Вместо BASIC. А в UNIX’ах вместо PERL.