Чому C ++ не має рефлексії?

Це дещо химерне питання. Мої завдання - зрозуміти мовне рішення дизайну та визначити можливості відображення в C ++.

1. Чому мовний комітет C ++ не пішов на реалізацію роздумів про мову? Чи занадто складно відображення мовою, яка не працює на віртуальній машині (наприклад, Java)?

2. Якби реалізувати роздуми для C ++, які будуть проблеми?

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

У C ++ є кілька проблем з відображенням.

• Додайте ще багато роботи, і комітет C ++ досить консервативний, і не витрачайте час на радикальні нові функції, якщо вони впевнені, що це окупиться. (Була зроблена пропозиція щодо додавання модульної системи, подібної до збірок .NET, і, хоча я думаю, що існує загальна думка, що це було б добре, це не є їх головним пріоритетом на даний момент, і воно було відсунуто до того часу, як добре після C ++ 0x. Мотивація цієї функції полягає в тому, щоб позбутися #includeсистеми, але це також дозволить принаймні деякі метадані).

• Ви не платите за те, що не використовуєте. Це одна з основних основних філософій дизайну, що лежить в основі C ++. Чому мій код повинен містити метадані, якщо він мені ніколи не потрібен? Крім того, додавання метаданих може перешкоджати оптимізації компілятора. Чому я повинен платити цю вартість у своєму коді, якщо мені ніколи не потрібні ці метадані?

• Це призводить нас до ще одного важливого моменту: C ++ дає дуже мало гарантій щодо складеного коду. Компілятору дозволено робити майже все, що йому подобається, доки отримана функціональність - це те, що очікується. Наприклад, ваші заняття фактично не потрібні там . Компілятор може оптимізувати їх подалі, вбудовувати все, що вони роблять, і це часто робить саме це, оскільки навіть простий код шаблону, як правило, створює досить багато екземплярів шаблону. Стандартна бібліотека C ++ покладається на цю агресивну оптимізацію. Функціонери виконуються лише в тому випадку, якщо витрати на інстанціювання та руйнування об'єкта можуть бути оптимізовані. operator[]у векторі можна порівняти лише з індексацією необробленого масиву в продуктивності, оскільки весь оператор може бути вбудований і, таким чином, повністю видалений зі складеного коду. C # і Java дають багато гарантій щодо виходу компілятора. Якщо я визначу клас у C #, то цей клас буде існувати в отриманій збірці. Навіть якщо я його ніколи не використовую. Навіть якби всі дзвінки до його учасницьких функцій могли бути окреслені. Клас повинен бути там, щоб відображення знайшло його. Частина цього полегшується компіляцією C # у байт-код, а це означає, що компілятор JIT можевидаліть визначення класу та вбудовані функції, якщо це подобається, навіть якщо початковий компілятор C # не може. У C ++ у вас є лише один компілятор, і він повинен вивести ефективний код. Якщо вам дозволили перевірити метадані виконуваного файлу C ++, ви очікуєте побачити кожен визначений ним клас, а це означає, що компілятору доведеться зберігати всі визначені класи, навіть якщо вони не потрібні.

• А далі є шаблони. Шаблони на C ++ - це не що інше, як дженерики іншими мовами. Кожна інстанція шаблону створює новий тип. std::vector<int>це абсолютно окремий клас від std::vector<float>. Це додає до багатьох різних типів у всій програмі. Що має бачити наше відображення? Шаблон std::vector ? Але як це зробити, оскільки це конструкція вихідного коду, яка не має значення під час виконання? Потрібно було б побачити окремі класи std::vector<int>та std::vector<float>. А std::vector<int>::iteratorта std::vector<float>::iterator, то ж саме дляconst_iteratorі так далі. І як тільки ви перейдете до метапрограмування шаблонів, ви швидко закінчите екземпляри сотень шаблонів, які всі вбудовуються та видаляються компілятором. Вони не мають жодного значення, крім як метапрограми часу компіляції. Чи повинні всі ці сотні класів бути видимими для роздумів? Вони повинні були б, бо в іншому випадку наше відображення було б марним, якщо це навіть не гарантує, що класи, які я визначив, насправді будуть там . І бічною проблемою є те, що клас шаблонів не існує, поки він не буде ініційований. Уявіть програму, яка використовує std::vector<int>. Чи повинна наша система відображення бачити std::vector<int>::iterator? З одного боку, ви, звичайно, так очікували. Це важливий клас, і він визначається з точки зору того std::vector<int>, що робитьіснують у метаданих. З іншого боку, якщо програма ніколи насправді не використовує цей шаблон класу ітераторів, його тип ніколи не буде ініційований, і тому компілятор не створив би клас в першу чергу. І створити його під час виконання ще пізно, оскільки він вимагає доступу до вихідного коду.

• І нарешті, рефлексія не настільки важлива для C ++, як це є у C #. Причина знову - метапрограмування шаблонів. Він не може вирішити все, але для багатьох випадків, коли ви в іншому випадку вдаєтеся до рефлексії, можна написати метапрограму, яка робить те ж саме під час компіляції. boost::type_traits- простий приклад. Ви хочете дізнатися про тип T? Перевірте її type_traits. У C # вам доведеться рибалити навколо його типу, використовуючи відображення. Рефлексія все ще буде корисною для деяких речей (основне використання, яке я бачу, метапрограмування не може легко замінити, - це автогенерований код серіалізації), але це несе значні витрати на C ++, і це просто не потрібно так часто, як це є іншими мовами.

Редагувати: У відповідь на коментарі:

cdleary: Так, символи налагодження роблять щось подібне, оскільки вони зберігають метадані про типи, що використовуються у виконуваному файлі. Але вони також страждають від проблем, які я описав. Якщо ви коли-небудь намагалися налагодити збірку версій, ви будете знати, що я маю на увазі. Існують великі логічні прогалини, коли ви створили клас у вихідному коді, який увійшов у підсумковий код. Якби ви використовували роздуми для чогось корисного, вам знадобиться, щоб воно було більш надійним і послідовним. Як це є, типи зникають і зникають майже кожного разу, коли ви збираєтесь. Ви змінюєте крихітну деталь, і компілятор вирішує змінити, які типи будуть вбудовані, а які - як відповідь. Як витягти з цього щось корисне, Ви навіть не гарантували, що найбільш релевантні типи будуть представлені у ваших метаданих? Тип, який ви шукали, можливо, був там в останній збірці, але тепер його вже немає. А вже завтра хтось перевірить у невеликій невинній зміні невелику невинну функцію, яка робить тип просто великим, що він не стане повністю вписаним, тому він знову повернеться. Це все ще корисно для налагоджувальних символів, але не набагато більше того. Ненавиджу намагатися створити код серіалізації для класу під цими умовами. але не набагато більше того. Ненавиджу намагатися створити код серіалізації для класу під цими умовами. але не набагато більше того. Ненавиджу намагатися створити код серіалізації для класу під цими умовами.

Еван Теран: Звичайно, ці питання можна було б вирішити. Але це повертається до моєї точки №1. Це займе багато роботи, а комітет C ++ має багато речей, які вони вважають важливішими. Чи користь від обмеженого відображення (і це було б обмежено) в C ++ дійсно достатньо велика, щоб виправдати фокусування на цьому за рахунок інших можливостей? Чи є справді величезна користь у додаванні функцій до основної мови, що вже можна (в основному) зробити через бібліотеки та препроцесори, такі як QT? Можливо, але потреба набагато менш нагальна, ніж якби таких бібліотек не існувало. Що стосується ваших конкретних пропозицій, я вважаю, що заборона його на шаблонах зробить це абсолютно марним. Наприклад, ви не зможете використовувати відображення у стандартній бібліотеці. Яке б відображенняstd::vector? Шаблони - це величезна частина С ++. Функція, яка не працює на шаблонах, в основному марна.

Але ти маєш рацію, якась форма роздумів може бути реалізована. Але це було б значною зміною мови. Як і зараз, типи - це виключно конструкція часу компіляції. Вони існують на користь компілятора, і більше нічого. Після того , як код був скомпільований, там немає ніяких класів. Якщо ви розтягнете себе, ви можете стверджувати, що функції все ще існують, але насправді все, що існує, є купа інструкцій асемблера стрибків і багато штовхань / поп-стеків. Не можна багато чого продовжувати, додаючи такі метадані.

Але, як я вже говорив, є пропозиція щодо зміни моделі компіляції, додавання автономних модулів, зберігання метаданих для вибраних типів, що дозволяє іншим модулям посилатися на них без необхідності возитися з #includes. Це вдалий початок, і якщо чесно, я здивований, що стандартний комітет не просто викинув пропозицію за занадто великі зміни. Так, можливо, через 5-10 років? :)

Рефлексія вимагає, щоб десь зберігалися метадані про типи, які можна запитати. Оскільки C ++ компілюється у власний машинний код та зазнає значних змін через оптимізацію, подання на високому рівні програми в значній мірі втрачається в процесі компіляції, отже, запити їх під час виконання неможливо. Java та .NET використовують дуже високий рівень представлення у двійковому коді для віртуальних машин, що робить такий рівень відображення можливим. Однак у деяких C ++ реалізаціях є щось, що називається Інформація про тип часу запуску (RTTI), що можна вважати позбавленою версією відображення.

Усі мови не повинні намагатися включати всі особливості будь-якої іншої мови.

C ++ - це, по суті, дуже і дуже складний макроскладач. Це НЕ (у традиційному розумінні) мова високого рівня, наприклад C #, Java, Objective-C, Smalltalk тощо.

Добре мати різні інструменти для різних робіт. Якщо у нас є лише молотки, всі речі виглядатимуть як цвяхи тощо. Наявність мов скриптів корисно для деяких завдань, а відбиваючі мови OO (Java, Obj-C, C #) корисні для іншого класу завдань, і супер -ефективні мови, близькі до машини, голі кістки корисні для ще одного класу завдань (C ++, C, Assembler).

C ++ виконує дивовижну роботу з розширення технології Assembler до неймовірних рівнів управління складністю та абстракцій, щоб зробити програмування більшими, складнішими завданнями набагато більш можливими для людини. Але це не обов'язково мова, яка найкраще підходить для тих, хто підходить до своєї проблеми зі строго високого рівня (Lisp, Smalltalk, Java, C #). Якщо вам потрібна мова з цими функціями, щоб найкраще реалізувати рішення ваших проблем, то подякуйте тим, хто створив такі мови для всіх нас!

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

Для C #, Java, Objective-C потрібна значно більша, багатша система виконання для підтримки їх виконання. Цей час виконання повинен бути доставлений до відповідної системи - попередньо встановлений для підтримки роботи вашого програмного забезпечення. І цей шар повинен підтримуватися для різних цільових систем, налаштованих ДУМОЮ ІНШОЮ МОВОЮ, щоб він працював на цій платформі. І той середній шар - той адаптивний шар між хост-операційною системою та вашим кодом - під час виконання, майже завжди написаний такою мовою, як C або C ++, де ефективність №1, де передбачуване розуміння точної взаємодії програмного забезпечення та обладнання може бути добре зрозуміли і маніпулювали до максимальної вигоди.

Я люблю Smalltalk, Objective-C і маю багату систему виконання з відображенням, метаданими, збиранням сміття тощо. Дивовижний код можна написати, щоб скористатися цими можливостями! Але це просто більш високий шар на стеку, шар, який повинен опиратися на нижчі шари, який сам повинен врешті-решт сидіти на ОС та апаратному забезпеченні. І нам завжди буде потрібна мова, яка найкраще підходить для створення цього шару: C ++ / C / Assembler.

Додаток: C ++ 11/14 продовжує розширювати можливості C ++ для підтримки абстракцій та систем вищого рівня. Нитки, синхронізація, точні моделі пам’яті, більш точні визначення абстрактних машин дозволяють розробникам C ++ досягти багатьох абстракцій високого рівня, якими деякі з цих мов лише високого рівня використовували ексклюзивний домен, продовжуючи надавати тісний продуктивність металу та відмінна передбачуваність (тобто мінімальні підсистеми виконання). Можливо, засоби відображення будуть вибірково включені в майбутньому перегляді C ++, для тих, хто цього хоче, або, можливо, бібліотека надаватиме такі послуги часу (можливо, це є зараз, або початок роботи в цій програмі?).

Якщо ви дійсно хочете зрозуміти дизайнерські рішення, що стосуються C ++, знайдіть копію Посібника з анотацією C ++ від Ellis та Stroustrup. Він НЕ в курсі останніх стандартів, але він проходить через оригінальний стандарт і пояснює, як все працює і часто, як вони вийшли таким чином.

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

Компілятор C ++ нічого не тримає (ну ігноруючи RTTI), тому ви не знайдете відображення в мові. (Компілятори Java та C # зберігають лише імена класів, методів та типи повернення, тому ви отримуєте трохи даних про відображення, але ви не можете перевіряти вирази чи структуру програми, а це означає навіть у тих мовах, які підтримують відображення, інформація, яку ви можете отримати, є досить рідкою, і, отже, ви не можете зробити багато аналізу).

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

Рефлексія може бути і була реалізована в c ++ раніше.

Це не рідна функція c ++, оскільки вона має велику вартість (пам'ять та швидкість), яку не слід встановлювати мовою за замовчуванням - мова орієнтована на "максимальну продуктивність за замовчуванням".

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

Причина C ++ не має відображення в тому, що це вимагатиме від компіляторів додати інформацію символів до файлів об'єктів, наприклад, про те, які члени мають клас класу, інформацію про членів, про функції та все. Це, по суті, робить файли марними, оскільки інформація, що надсилається деклараціями, буде зчитуватися з цих об'єктних файлів (модулів тоді). У C ++ визначення типу може виникати кілька разів у програмі, включаючи відповідні заголовки (за умови, що всі ці визначення однакові), тож доведеться вирішити, куди слід розміщувати інформацію про цей тип, так само як назвати його ускладнення тут. Агресивна оптимізація, виконана компілятором C ++, який може оптимізувати десятки екземплярів шаблонів класу, є ще одним важливим моментом. Це можливо, але оскільки C ++ сумісний із C,

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

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

За словами Алістера Кокберна, субтипізація не може бути гарантована у рефлексивному середовищі .

Відображення більше стосується систем прихованого набору тексту. У C ++ ви знаєте, який тип маєте, і ви знаєте, що з цим можна зробити.

Відображення може бути необов’язковим, як директива про препроцесор. Щось на зразок

#pragma enable reflection

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

Якщо C ++ міг би мати:

• дані члена класу для імен змінних, типів змінних та constмодифікатора
• ітератор аргументів функції (лише позиція замість імені)
• дані члена класу для імен функцій, типу повернення та constмодифікатора
• список батьківських класів (у тому ж порядку, що визначено)
• дані для членів шаблону та батьківських класів; розширений шаблон (тобто фактичний тип буде доступний для відображення API, а не "інформація про шаблон того, як дістатися")

Цього було б достатньо, щоб створити дуже прості у використанні бібліотеки в основі нетипової обробки даних, яка настільки поширена в сьогоднішніх веб-додатках та базах даних (усі орми, механізми обміну повідомленнями, аналізатори xml / json, серіалізація даних тощо).

Наприклад, основна інформація, що підтримується Q_PROPERTYмакросом (частина Qt Framework) http://qt.nokia.com/doc/4.5/properties.html, розширена, щоб охопити методи класу та e) - була б надзвичайно корисною для C ++ та для програмне співтовариство загалом.

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

кілька хороших посилань на роздуми в C ++, щойно я знайшов:

Робочий документ стандарту C ++: аспекти відображення в C ++

Простий приклад рефлексії за допомогою шаблонів

Відображення на C ++, я вважаю, що надзвичайно важливо, якщо C ++ використовуватиметься як мова для доступу до бази даних, обробки веб-сесій / http та розробки графічного інтерфейсу. Відсутність відображення заважає ORM (наприклад, Hibernate або LINQ), XML і JSON парсерам, які створюють класи, серіалізація даних та багато інших типів (де спочатку безцінні дані повинні використовуватися для створення примірника класу).

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

Мені провайдеру прошивки не потрібні роздуми, щоб прочитати дані з послідовного порту - тоді добре не використовувати комутатор. Але як розробник баз даних, який хоче продовжувати використовувати C ++, я постійно переживаю жахливий, важкий для підтримки код, який відображає дані між членами даних та структурами бази даних.

Ні серіалізація Boost, ні інший механізм насправді не вирішують відображення - це повинен зробити компілятор - і після того, як це буде зроблено, C ++ буде знову запускатися в школах і використовуватись у програмному забезпеченні, яке займається обробкою даних.

Для мене це питання №1 (а примітивні натівні примітиви - це питання №2).

Це в основному тому, що це "додаткова додаткова". Багато людей вибирають C ++ на таких мовах, як Java та C #, щоб мати більше контролю над результатами компілятора, наприклад, меншою та / або швидшою програмою.

Якщо ви хочете додати роздуми, доступні різні рішення .