Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>привести указатель на float к указателю на unsigned int, чтоб извлечь внутреннее представление плавающего числа?
S>>С++ это и не позволяет.
ЕМ>Как, и с каких пор?
Со времен C++98. Здесь можете посмотреть раздел 3.10.15.
S>>>>Или вы про type punning через Си-шный union? ЕМ>>>Это уже частность.
S>>Эта частность под запретом.
ЕМ>Как, с каких пор?
ЕМНИП, всю жизнь.
За подробностями сюда: https://stackoverflow.com/a/11996970
S>>>>К возможностям языка это вообще не относится. ЕМ>>>Это относится к его применению.
S>>Мы говорим о языке.
ЕМ>А для чего создается язык — для составления на нем текстов программ с целью любования ими, или таки для практического применения?
За 30 лет практического применения C++ я написал туеву хучу кода, который работал на самых разных платформах и компиляторах. И тема ABI передо мной вообще никогда не вставала. В отличии от вопросов о соответствии стандарту и поведению одного и того же кода в разных условиях.
S>>https://en.wikipedia.org/wiki/General-purpose_macro_processor S>>
A general-purpose macro processor or general purpose preprocessor is a macro processor that is not tied to or integrated with a particular language or piece of software.
ЕМ>Приставка general-purpose Вас, стало быть, совершенно не смущает. Как и непоколебимая уверенность в том, что любой макро/препроцессор непременно обязан быть general-purpose, иначе основы мироздания рухнут.
Вы хотели определение -- вы его получили. Если это определение (соответствующие действительности для тех же C и C++) рвет вам шаблоны и рушит картину мира, то это ваши проблемы.
Причем, это не мое определение, я его не формулировал.
ЕМ>Ну и ради бога, бывает.
Дайте ссылку на какое-либо другое определение макро-процессора, тогда и посмотрим что бывает, а что есть только в вашей фантазии.
S>>Пойдите и сделайте.
ЕМ>Надо будет — пойду и сделаю.
Звиздеть не мешки ворочать.
ЕМ>Квалификации мне для этого хватает более чем
"Ну и вы, батенька, говорите, говорите" (с)
Re[9]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Именно — парни совершенно безосновательно, но крайне отчаянно, уперлись в идею о том, что компилятор C++ якобы по умолчанию обязан правильно обрабатывать любую программу, которая удовлетворяет синтаксису C, хотя в этом не было ни малейшей необходимости. Никаких аргументов за это, которые не выглядели бы наивно, я не встречал ни у Страуструпа, ни у его комментаторов.
И это рядом с другим: ЕМ>Чтоб реально убить C++, язык для начала должен быть полностью с ним совместим, как C++ сперва был полностью совместим с C, и сохранять эту совместимость какое-то время.
Вот некоторые парни реально заморочились на счёт того, чтобы быть совместимыми. И эта совместимость до сих пор неплохо даже работает, я в прошлом месяце взял программу на С, сменил в её файлах расширение на cpp, включил в свой проект и оно заработало. И дальше правил эти файлы так, как будто это С++ код. То есть это полезно спустя несколько десятилетий после создания языка, а тогда было полезным ещё больше.
Тот факт, что Страуструп так бережно и скурпулёзно поддерживал совместимость, это огромнейший именно что практичный плюс языка, вот не надо недооценивать.
Re[15]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, so5team, Вы писали:
BFE>>Вы за подобный подход? S>Как я понимаю -- нет. Он хочет полноценного метапрограммирования на этапе компиляции.
Хочет метапрограммирования, а пишет о макросах...
S>Как раз того, что сейчас завозят в C++26 в виде compile-time рефлексии.
Как я понимаю, это безумие уже не остановить.
Безумие состоит в том, что в комитете выбрали совершенно уродский синтаксис. А ещё они занимаются тем, что никому не нужно. Как вообще могла прийти в голову, что программисту может понадобится категория выражения? Такое только в профдеформированном мозге писателя компилятора могло произойти.
А синтаксис ? Вы видели это убожество? Нафига эти префиксы '^'. Что это за порнография?
using MyType = int.size < long.size ? long.type : int.type;
И тут всё просто и понятно: если после типа стоит точка, то далее идёт работа с метоинформацией об этом типе. Кратко. Чётко. По делу. А не вот это вот всё...
И если взять это за основу тогда: decltype(a + b).type — тип результата сложения.
Вот конвертация в строку перечисления предложенное комитетом:
template <typename E>
requires std::is_enum_v<E>
constexpr std::string enum_to_string(E value) {
template for (constexpr auto e : std::meta::members_of(^E)) {
if (value == [:e:]) {
return std::string(std::meta::name_of(e));
}
}
return"<unnamed>";
}
enum Color { red, green, blue };
static_assert(enum_to_string(Color::red) == "red");
static_assert(enum_to_string(Color(42)) == "<unnamed>");
Вот как оно должно быть:
template <typename E>
requires std::is_enum_v<E>
consteval const char* enum_to_string(E value)
{
for(constexpr auto e : E.members )
{
if ( value == e.value)
return e.name;
}
return"<unnamed>";
}
using namespace std::literals;
static_assert(enum_to_string(Color::red) == "red"sv);
static_assert(enum_to_string(Color(42)) == "<unnamed>"sv);
И каждый день — без права на ошибку...
Re[16]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, B0FEE664, Вы писали:
BFE>А синтаксис ? Вы видели это убожество? Нафига эти префиксы '^'. Что это за порнография?
Меня больше вымораживает оператор баян:
[: ||| :]
Когда изучаешь примеры с рефлексией, то эти самые операторные скобки хреново видны в коде.
Я пробовал в комментариях на Хабре донести до Полухина что синтаксис неоднозначный и что жалко, что решение по синтаксису, с которым затем придется жить миллионам программистов, принимается на заседаниях комитета, где собирается полторы-две сотни, а собственно рефлексией занимается пара-тройка десятков. Но понимания не встретил.
Но со стороны комитета тоже вполне понятная позиция: процесс подачи предложений и их обсуждения открытый, кому очень нужно, тот пусть участвует. А таким как я, кто недоволен итоговым результатом, нужно просто быть поактивнее.
BFE>Вот безумие комитета:
К любому синтаксису можно привыкнуть.
Мне вот, к примеру, синтаксис С++ных шаблонов не особо нравился. А теперь нахожусь при мнении, что он очень удачный.
Главная проблема, на самом деле, не в том как это будет выглядеть и как много хейтеров и ниасиляторов будут испражняться ослоумием в Интернетах. А в том, когда это будет доступно для массового применения. Если затянется как с поддержкой С++ных модулей, то печально.
Re[10]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, so5team, Вы писали:
ЕМ>>>>привести указатель на float к указателю на unsigned int, чтоб извлечь внутреннее представление плавающего числа? S>>>С++ это и не позволяет. ЕМ>>Как, и с каких пор? S>Со времен C++98. Здесь можете посмотреть раздел 3.10.15.
Во-первых, там речь об lvalue, а для того, о чем писал я, достаточно rvalue.
Во-вторых, не вижу там характерных слов, вроде "impossible", "unsupported", "not implemented" и подобных. Возможно, недостаточно знаю английский.
В-третьих, до низкого уровня, слава богу, [пока] не добралась модная традиция "стерильного программирования", требующая, чтобы исходники какого-нибудь начального загрузчика гарантированно собирались у любого дятла, сумевшего их раздобыть вместе с компилятором соответствующего стандарта языка. Там это совершенно не нужно, и вряд когда-нибудь станет.
S>>>Эта частность под запретом. ЕМ>>Как, с каких пор? S>ЕМНИП, всю жизнь. S>За подробностями сюда: https://stackoverflow.com/a/11996970
Опять же не вижу в стандартах и документации характерных слов, вроде "prohibuted", "not allowed" , "disabled", "illegal" и т.п.
S>За 30 лет практического применения C++ я написал туеву хучу кода, который работал на самых разных платформах и компиляторах. И тема ABI передо мной вообще никогда не вставала. В отличии от вопросов о соответствии стандарту и поведению одного и того же кода в разных условиях.
Это потому, что Вы работаете на высоких уровнях — там и я стараюсь поддерживать ту "стерильность", хотя и не на столь фанатичном уровне, что нынче в моде. Это из серии "сделайте устройство, которым сможет пользоваться даже дурак...".
S>Вы хотели определение -- вы его получили.
Во-первых, я хотел определения макропроцессора вообще, а получил определение такового общего назначения. Это как в соседней теме о ножах, только наоборот: я несколько раз подчеркивал, что речь идет о совершенно банальных ножах "для всего", а мне в ответ упорно суют примеры узкоспециализированных, целевых изделий.
Во-вторых, не ожидал от Вас апелляции к Википедии в роли источника единых, всеобщих определений, выходящих за пределы строгих наук.
S>Если это определение (соответствующие действительности для тех же C и C++) рвет вам шаблоны и рушит картину мира
Не, препроцессоры C/C++ у меня вызывают лишь чувства брезгливости и стыда за разработчиков языков. Если убожество препроцессора C еще можно понять (малые машины, ограниченные ресурсы, непонятные перспективы языка и т.п.), то его точное копирование в C++ уже за пределами моего понимания. Что ж, они хотели избежать ада макросов — получилп ад шаблонов, и до сих пор делают вид, будто это случилось внезапно.
А такое случается со всей без исключения искусственно ограниченной функциональностью. Я вот сам на командном языке винды порой пишу такое, что самому рыдать хочется, но перенести сразу все рабочее хотя бы на PowerShell (который тоже ужасен) никак руки не дойдут.
S>Дайте ссылку на какое-либо другое определение макро-процессора
Ну вот Вам от Алисы, по запросу "определение встроенного макропроцессора":
Встроенный макропроцессор — это программа, которая встроена в другую программу (например, компилятор, ассемблер) и выполняет систематическую замену текста на основе макросов. Макрос — это средство замены строки на другую, полученную из исходной по заранее заданным правилам.
Re[16]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, B0FEE664, Вы писали:
BFE>Хочет метапрограммирования, а пишет о макросах...
И с каких пор макросы перестали быть средством метапрограммирования? Или нам следует сосредоточиться на сугубо философской стороне?
BFE>Как я понимаю, это безумие уже не остановить.
Да, я тоже сомневаюсь, что разум возобладает.
BFE>в комитете выбрали совершенно уродский синтаксис.
А куда им деваться, ежли они стремятся любой ценой сохранить выбранную парадигму? То ли еще будет...
Re[17]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, so5team, Вы писали:
S>К любому синтаксису можно привыкнуть. S>Мне вот, к примеру, синтаксис С++ных шаблонов не особо нравился. А теперь нахожусь при мнении, что он очень удачный.
Дык, это ж всегда и везде так делается. Любая ужасная идея становится "вполне приемлемой" на фоне еще более ужасных.
S>когда это будет доступно для массового применения.
С таким подходом это будет становиться все менее доступным для масс, и в итоге выродится во что-то вроде тайного ордена, требующего испытаний, посвящения и воспитания достойной смены.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Во-вторых, не вижу там характерных слов, вроде "impossible", "unsupported", "not implemented" и подобных. Возможно, недостаточно знаю английский.
Может недостаточное знание английского так же сказывается, но больший вклад нежелание принимать реальность как она есть. Когда 30 лет не высовываешь нос за пределы уютного мирка VC++, то сложно поверить в то, что читать содержимое float-а через указатель на int запрещено.
S>>Вы хотели определение -- вы его получили.
ЕМ>Во-первых, я хотел определения макропроцессора вообще, а получил определение такового общего назначения.
Сложно объяснить как "вообще" противопоставляется "общему назначению" кроме как скудоумием.
ЕМ>Ну вот Вам от Алисы, по запросу "определение встроенного макропроцессора":
ЕМ>
ЕМ>Встроенный макропроцессор — это программа, которая встроена в другую программу (например, компилятор, ассемблер) и выполняет систематическую замену текста на основе макросов. Макрос — это средство замены строки на другую, полученную из исходной по заранее заданным правилам.
Сравните с определением из Wikipedia, ссылку я вам давал:
A macro processor is a program that copies a stream of text from one place to another, making a systematic set of replacements as it does so. Macro processors are often embedded in other programs, such as assemblers and compilers.
Не вижу противоречий.
Ключевой момент в том, что макросы работают с текстом и не заботятся о семантике, которая с текстом связана. Именно поэтому в первой части определения из Wikipedia сказано вот это:
a macro processor that is not tied to or integrated with a particular language
т.е. макропроцессор делает свою работу безотносительно того, что делает язык программирования.
Когда же мы работаем с фрагментом кода с анализом его семантики, т.е. когда на вход идут не фрагменты текста, а код как данные над которыми можно делать какие-то преобразования, то это уже не макро-программирование, а мета-программирование.
Здравствуйте, so5team, Вы писали:
S>Когда 30 лет не высовываешь нос за пределы уютного мирка VC++
Да я, как бы, иногда высовываю в разные линуксы и на МК. Нечасто, но бывает.
S>сложно поверить в то, что читать содержимое float-а через указатель на int запрещено.
Повторю: я не вижу в стандарте запрета. VC++ и gcc такие операции компилируют. Подозреваю, что Вы неправильно называете явление.
S>Сложно объяснить как "вообще" противопоставляется "общему назначению" кроме как скудоумием.
Ну давайте я попробую. Здесь нет противопоставления, но есть подчинение. Когда речь идет о неком устройстве "общего назначения", подразумевается, что целевое назначение этого устройства не определено, и оно или специально разработано, или просто оказалось пригодным, для выполнения максимально широкого круга задач. А когда говорят об "устройстве вообще", то подразумевается любая сущность, к которой применимо понятие "устройство".
То есть, "процессор общего назначения" является "процессором вообще", но обратное неверно. Так понятно?
Да, это в той литературе, которую мне доводилось читать, и в той среде, к адекватности которой у меня нет претензий. Возможно, у Вас они другие.
S>Не вижу противоречий.
Противоречие создаете Вы, когда привычно толкуете "...copies a stream of text from one place to another...". Вам почему-то кажется, что любой макропроцессор непременно должен быть препроцессором, и непременно обрабатывать весь текстовый поток в одно лицо, допуская до него другие средства (в нашем случае — компилятор) лишь после полного завершения работы.
S>Ключевой момент в том, что макросы работают с текстом и не заботятся о семантике, которая с текстом связана.
Если "работают" заменить на "обычно работают" или "могут работать", то не возражаю. Впрочем, даже если и оставить "работают", то ничто не мешает макропроцессору, встроенному в компилятор, иметь функции вроде "обработай эту строку, как фрагмент исходного текста", "попробуй интерпретировать эту строку, как выражение/тип" и т.п.
S>Именно поэтому в первой части определения из Wikipedia сказано вот это: S>
a macro processor that is not tied to or integrated with a particular language
Это сказано только для "general-purpose macro processor or general purpose preprocessor".
S>т.е. макропроцессор делает свою работу безотносительно того, что делает язык программирования.
Мне казалось, что должно быть даже интуитивно понятно, что смысл этого выражения в том, что макропроцессор общего назначения не предназначен для использования с конкретным языком, и не обязан быть встроен в компилятор конкретного языка. Но Вы упорно навязываете собственную интерпретацию — "макропроцессор не может работать параллельно с компилятором и обмениваться с ним информацией, иначе это не макропроцессор вовсе".
S>Когда же мы работаем с фрагментом кода с анализом его семантики, т.е. когда на вход идут не фрагменты текста, а код как данные над которыми можно делать какие-то преобразования, то это уже не макро-программирование, а мета-программирование.
И здесь тоже нет противоречия, а есть подчинение: макропрограммирование является частным случаем метапрограммирования.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>сложно поверить в то, что читать содержимое float-а через указатель на int запрещено.
ЕМ>Повторю: я не вижу в стандарте запрета. VC++ и gcc такие операции компилируют.
Да, уж, дураков учить -- только портить, а вы, Евгений, нужны RSDN-у в своей незамутненности.
Для таких как вы, которые думают, что если компилятор компилирует, то это разрешено, потом приходится целые книги
писать. Жаль только, что долбоящеры, кичащиеся своими воспоминаниями о PL/1, не способны учиться новому и таких полезных книг не читают.
S>>Когда же мы работаем с фрагментом кода с анализом его семантики, т.е. когда на вход идут не фрагменты текста, а код как данные над которыми можно делать какие-то преобразования, то это уже не макро-программирование, а мета-программирование.
ЕМ>И здесь тоже нет противоречия, а есть подчинение: макропрограммирование является частным случаем метапрограммирования.
Для метапрограммирования нужно, чтобы код (уже разобранный и обработанный с учетом семантики языка) поступал на вход в качестве параметра. В случае с макросами это в принципе не так, поскольку макросы работают либо на уровне сырого текста (как препроцессор Си), либо, в более продвинутых случаях, на уровне AST не подвергшегося еще семантическому анализу (например, процедурные макросы Rust-а, которые получают и возвращают TokenStream-ы).
Здравствуйте, so5team, Вы писали:
S>макросы работают либо на уровне сырого текста (как препроцессор Си), либо, в более продвинутых случаях, на уровне AST не подвергшегося еще семантическому анализу
Это не макросы (как сущность/технология) так работают — так работают их отдельные реализации. Никакие объективные законы не мешают делать реализации, в которых они работают иначе.
Ваши любимые шаблоны тоже обладают рядом свойств макросов, и ни Вы, ни кто другой, не сумеете однозначно доказать, что шаблон не является макросом (не конкретно в терминах C++, а по своей сути). Просто потому, что не существует единого, всеобщего определения, обязательного для всех, и жесткого разделения на "макросредства" и "метасредства". Это всего лишь более-менее устоявшиеся разделение и терминология, позволяющие говорить, что вот это — "скорее макрос", а это — "скорее метасредство".
Наша дискуссия показывает, что Вы в состоянии воспринимать исключительно то, что уже где-то определено, реализовано, обкатано, стало более-менее известным/популярным. Идеи, которые не ложатся в одну из готовых и обкатанных парадигм, Вы отвергаете из принципа. Что ж Вы удивляетесь тому, что Страуструп с коллегами столь же однозначно отвергли макросы лишь потому, что "они работают так, а не иначе"? Мыслей о том, что макросы можно реализовать иначе, я ни разу не встречал ни в работах Страуструпа, ни в любой другой литературе по C++. Везде и была, и остается строгая дихотомия: либо предварительная стадия, обработка на уровне лексем и чисто текстовые подстановки, либо стадия компиляции и какие-то принципиально особые конструкции и способы их обработки.
Не следует думать, что все выдающиеся люди, достигшие впечатляющих результатов, всегда "равномерно и однородно" образованы, сообразительны, лишены предрассудков и т.п. Наоборот, гениальность и плодовитость, как известно, часто сопровождается разного рода психическими отклонениями, а то и нарушениями.
Re[6]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
N>До недавнего времени развитием стандарта Питона занимался почти единолично один добрый диктатор. И он ушёл со своего поста, когда принял на себя волну критики после непопулярного решения. Через время оказалось, что решение было верным. И это произошло в очень-очень-очень доброжелательном комьюнити. Роль личности не надо ни недооценивать, ни переоценивать. Когда на языке написаны тонны коммерческого кода, то развивать язык без оглядки на пользователей и обратную совместимость просто невозможно.
Что за история и о каком решении речь?
Кодом людям нужно помогать!
Re[2]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
x>>... x>>Смотрел несколько дней назад, уже всего точно не помню, но вот некоторые моменты: x>>Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей. x>>...
SaZ>Свежий пример из моей практики, про инкапсуляцию. На текущем проекте мы разрабатываем stateless ui фреймворк
Пардон, а это предметная область (domain)? Вроде UI — это к портам/адаптерам.
В видео критикуется мантра что предметная область обязана быть выражена как compile-time иерархия классов, где всё "состояние" должно инкапсулироваться, а публичным должно быть только "поведение".
К тому, что у PgSQLDBConnection : IDBConnection сокет подключения инкапсулирован — вопросов нет. Это не предметная область.
S>Для метапрограммирования нужно, чтобы код (уже разобранный и обработанный с учетом семантики языка) поступал на вход в качестве параметра. В случае с макросами это в принципе не так, поскольку макросы работают либо на уровне сырого текста (как препроцессор Си), либо, в более продвинутых случаях, на уровне AST не подвергшегося еще семантическому анализу (например, процедурные макросы Rust-а, которые получают и возвращают TokenStream-ы).
Макросы раста работают не с синтаксическим материалом, а лексическим. То есть ещё до построения AST.
Но это не единственный способ жить с макросами. К примеру, макросы лиспа получают не токены входного стрима, а вполне себе уже разобранное AST. То, что в нём не произведён семантический анализ, скорее связано с отсутствием такового в лиспе совсем, чем с какими-то фундаментальными ограничениями макросов.
Генераторы кода в C#, хоть и не являются макросами, но работают как раз с уже разобранным и типизированным AST (например, могут тащить из него информацию о методах класса, не задуряясь ручным разбором потока лексем в поисках отличий вложенных классов и конструкторов от методов экземпляра).
Макросы в D работают напрямую с метаданными. B дарте — тоже.
Вообще, ваш оппонент пытается изобрести Немерле
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
σ>Пардон, а это предметная область (domain)? Вроде UI — это к портам/адаптерам. σ>В видео критикуется мантра что предметная область обязана быть выражена как compile-time иерархия классов, где всё "состояние" должно инкапсулироваться, а публичным должно быть только "поведение".
Видео не смотрел, и честно говоря не тянет. Но вопрос возник.
σ>К тому, что у PgSQLDBConnection : IDBConnection сокет подключения инкапсулирован — вопросов нет. Это не предметная область.
А что это тогда? Как по мне — сокет подключения это предметная область PgSQLDBConnection.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
σ>>В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям).
D>А это что?
D>
class B : private A {
// ...
};
Приватное наследование
Re[15]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это ж гораздо заметнее, чем пресловутая разница в анализе итерационных и рекурсивных алгоритмов, где последние всегда и бесспорно признаются более сложными для среднего человека. А мало-мальски сложные шаблонные конструкции почти все основаны если не на рекурсии, то на поочередном сопоставлении, которое по смыслу достаточно близко к ней.
Хм, странно, мне всегда проще было сделать что-то рекурсивно, чем итерационно.
ЕМ>Поэтому у большинства программистов использование шаблонов за пределами "минимально обобщенного" программирования сводится к тупому переписыванию (вплоть до копипасты) фрагментов из справочников, руководств и примеров, с подстановкой туда своих имен. Когда компилятор выдает пресловутую "простыню", большинство опять же мало что в ней понимает, и либо одним из методом тыка подбирает параметры шаблона, либо применяет известные методы устранения наиболее типичных ошибок. Насколько, по-Вашему, это соответствует нормальному, надежному процессу программирования?
Ты про каких-то неосиляторов
ЕМ>Я обычно так и делаю, когда есть возможность. Если б у меня был свой компилятор C++, я б там давно сделал большинство вещей, которые облегчают работу, повышают надежность программы и т.п., не создавая значимых затрат.
А что тебе сешает сделать свой компилятор своего "C++"? Если выкинуть шаблоны, то останется "C с классами", взять в качестве бэка ту же чистую сишечку, и такой коспилятор пишется за месяц, ну, окей, за три. А дальше сиди и наворачивай, как тебе нравится
ЕМ>>>Например, в ассемблере System/360.
S>>покажете пример как получить в качестве параметра класс
ЕМ>Как Вы представляете себе пример на макроязыке ассемблера System/360, получающий в качестве параметра класс? Для этого пришлось бы городить специальный псевдоязык. А в этом я не вижу ни малейшей надобности, ибо сама идея, на мой взгляд, предельно примитивна, и напрашивается интуитивно. Если для Вас это не так, то мы смотрим на устройство ЯП и процесс их компиляции под несовместимыми углами, и примеры здесь не помогут.
Примеры помогут, по-моему, мало кто понимает, как твои макросы должны работать
