Чому макроси не включені в більшість сучасних мов програмування?

Я знаю, що вони реалізуються надзвичайно небезпечно в C / C ++. Хіба вони не можуть бути реалізовані більш безпечно? Чи недоліки макросів справді досить погані, щоб переважати масивну потужність, яку вони надають?

Я думаю, що головна причина - макроси лексичні . Це має кілька наслідків:

• У компілятора немає можливості перевірити, чи є макрос семантично закритим, тобто що він являє собою "одиницю значення", як це робить функція. (Поміркуйте #define TWO 1+1- що TWO*TWOдорівнює? 3.)

• Макроси не набираються, як і функції. Компілятор не може перевірити, чи мають параметри та тип повернення сенс. Він може перевірити лише розширений вираз, який використовує макрос.

• Якщо код не компілюється, компілятор не може знати, чи є помилка в самому макросі або в тому місці, де використовується макрос. Компілятор або повідомить про неправильне місце половину часу, або повинен повідомити про обидва, навіть якщо один з них, ймовірно, добре. (Поміркуйте #define min(x,y) (((x)<(y))?(x):(y)): що повинен робити компілятор, якщо типи xта yне відповідають або не реалізуються operator<?)

• Автоматизовані інструменти не можуть працювати з ними семантично корисними способами. Зокрема, ви не можете мати такі речі, як IntelliSense для макросів, які працюють як функції, але розширюються на вираз. (Знову minприклад.)

• Побічні ефекти макроса не настільки явні, як з функціями, що викликає потенційну плутанину у програміста. (Розглянемо ще раз minприклад: у виклику функції ви знаєте, що вираз для xоцінюється лише один раз, але тут ви не можете знати, не дивлячись на макрос.)

Як я вже говорив, все це наслідки того, що макроси є лексичними. Коли ви намагаєтесь перетворити їх на щось більш правильне, ви закінчите функціями та константами.

Але так, макроси можна розробити та реалізувати краще, ніж у C / C ++.

Проблема макросів полягає в тому, що вони є ефективно механізмом розширення синтаксису мови, який переписує ваш код у щось інше.

• У випадку C / C ++ немає принципової перевірки рівня безпеки. Якщо ви обережні, все в порядку. Якщо ви зробили помилку, або якщо ви зловживаєте макросами, ви можете потрапити у великі проблеми.

  Додайте до цього, що багато простих речей, які ви можете зробити з макросами (стиль C / C ++), можна зробити іншими способами іншими мовами.

• В інших мовах, таких як різноманітні діалекти Lisp, макроси краще інтегруватися з синтаксисом основної мови, але ви все ще можете отримати проблеми з деклараціями в макросі "протікання". З цим вирішуються гігієнічні макроси .

Короткий історичний контекст

Макроси (скорочення макроінструкцій) вперше з'явилися в контексті мови складання. Згідно з Вікіпедією , макроси були доступні в деяких складальниках IBM в 1950-х роках.

Оригінальний LISP не макросів, але вони були вперше введені в MacLisp в середині 1960-х: https://stackoverflow.com/questions/3065606/when-did-the-idea-of-macros-user-defined-code -трансформація-з’являються . http://www.csee.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf . До цього "fexprs" забезпечували макроподібну функціональність.

Найдавніші версії C не мали макросів ( http://cm.bell-labs.com/cm/cs/who/dmr/chist.html ). Вони були додані приблизно в 1972-73 рр. За допомогою препроцесора. До цього C підтримував лише #includeта #define.

Макропропроцесор M4 зародився приблизно в 1977 році.

Більш новітні мови, мабуть, реалізують макроси, де модель роботи є синтаксичною, а не текстовою.

Тож коли хтось говорить про першість певного визначення терміна «макро», важливо зазначити, що значення розвивалося з часом.

Як зазначає Скотт , макроси можуть приховувати логіку. Звичайно, це роблять функції, класи, бібліотеки та багато інших поширених пристроїв.

Але потужна макросистема може піти далі, що дозволяє розробити та використовувати синтаксис та структури, які зазвичай не знаходяться в мові. Це справді може бути чудовим інструментом: мови, що стосуються домену, генератори коду та багато іншого, все це за умови єдиного мовного середовища ...

Однак цим можна зловживати. Це може ускладнити читання, розуміння та налагодження коду, збільшити час, необхідний для ознайомлення нових програмістів із кодовою базою даних, та призведе до дорогих помилок та затримок.

Отже, для мов, призначених для спрощення програмування (наприклад, Java або Python), така система є анафемою.

Макроси можуть бути реалізовані дуже безпечно за деяких обставин - наприклад, у Ліспі макроси - це лише функції, які повертають перетворений код у вигляді структури даних (s-вираз). Звичайно, Лісп значно виграє від того, що він гомонічний і того, що "код - це дані".

Прикладом того, наскільки легкими можуть бути макроси, є цей приклад Clojure, який визначає значення за замовчуванням, яке слід використовувати у випадку винятку:

(defmacro on-error [default-value code]
  `(try ~code (catch Exception ~'e ~default-value)))

(on-error 0 (+ nil nil))               ;; would normally throw NullPointerException
=> 0                                   ;l; but we get the default value

Навіть у Lisps, однак, загальна порада "не використовуйте макроси, якщо не потрібно".

Якщо ви не використовуєте гомонічну мову, макроси стають набагато складнішими, а всі інші параметри мають деякі підводні камені:

• Текстові макроси - наприклад, препроцесор C - простий у здійсненні, але дуже складний у використанні, оскільки потрібно створити правильний синтаксис у текстовій формі, включаючи будь-які синтаксичні химерності
• DSLS на основі макросу - наприклад, система шаблонів C ++. Складний, що сам по собі може спричинити складний синтаксис, може бути надзвичайно складним для правильного поводження з компіляторами та інструментами, оскільки він вносить значну нову складність у синтаксис та семантику мови.
• API для маніпулювання AST / байт-кодом - наприклад, відображення / генерація байт-коду - теоретично дуже гнучка, але може отримати дуже багатослівний: для виконання досить простих речей може знадобитися багато коду. Якщо для генерування еквівалента функції трьох рядків потрібно десять рядків коду, то ви не зробили багато своїх мета метапрограмування ...

Крім того, все, що може зробити макрос, в кінцевому підсумку може бути досягнуто якось іншим способом затяжною цілковитою мовою (навіть якщо це означає написання великої кількості табличок). В результаті всієї цієї хитрості не дивно, що багато мов вирішують, що макроси насправді не варті всіх зусиль для впровадження.

Щоб відповісти на ваші запитання, подумайте, для яких макросів переважно використовуються (Увага: код, складений мозком).

• Макроси, що використовуються для визначення символічних констант #define X 100

Це легко замінити на: const int X = 100;

• Макроси, що використовуються для визначення (по суті) вбудованих типово-агностичних функцій #define max(X,Y) (X>Y?X:Y)

У будь-якій мові, яка підтримує перевантаження функцій, це може бути емульовано набагато більш безпечним для типу способом, перевантаживши функції правильного типу або, мовою, яка підтримує дженерики, загальною функцією. Макрос із задоволенням намагатиметься порівняти будь-що, включаючи вказівники чи рядки, які можуть скластись, але майже точно не те, що ви хотіли. З іншого боку, якщо ви зробили безпечні для макросу типи, вони не надають жодних переваг та зручності над перевантаженими функціями.

• Макроси, що використовуються для вказівки ярликів до часто використовуваних елементів. #define p printf

Це легко замінюється функцією, p()яка робить те саме. Це досить задіяно в C (вимагає використання va_arg()сімейства функцій), але в багатьох інших мовах, які підтримують змінну кількість аргументів функції, це набагато простіше.

Підтримка цих функцій в рамках мови , а не в спеціальному макромові простіше, менш схильна до помилок і набагато менш заплутане інше читанні коди. Насправді я не можу придумати єдиного випадку використання для макросів, які не можна легко дублювати іншим способом. Тільки місце , де макроси дійсно корисні, коли вони прив'язані до умовної компіляції конструкцій , таких як #if( і т.д.).

З цього питання я не буду сперечатися з вами, оскільки вважаю, що непроцесорні рішення умовної компіляції в популярних мовах надзвичайно громіздкі (як введення байт-коду в Java). Але такі мови, як D, придумали рішення, які не потребують препроцесора і не є більш громіздкими, ніж використання умовних умов препроцесора, при цьому набагато менш схильні до помилок.

Найбільшою проблемою, з якою я бачив макроси, є те, що при значному використанні вони можуть зробити код дуже важким для читання та обслуговування, оскільки вони дозволяють приховати логіку в макросі, яку можна знайти, а може і нелегко знайти (а може і не може бути тривіальною ).

Для початку слід зазначити, що MACRO в C / C ++ дуже обмежені, схильні до помилок і не дуже корисні.

MACRO, реалізовані в скажімо LISP, або мові асемблера z / OS, можуть бути надійними та неймовірно корисними.

Але через зловживання обмеженою функціональністю у C вони зібралися поганою репутацією. Тож ніхто більше не реалізовує макроси, натомість ви отримуєте такі речі, як Шаблони, які роблять деякі найпростіші макроси, які використовувались, і такі речі, як анотації Java, які роблять деякі більш складні речі, які макрос використовував.