Чому C ++ не може прийняти підхід D для його реалізації?

Як багато хто з вас, хлопці, знають, що поняття , підхід C ++ щодо обмеження можливих типів аргументу шаблону не вдалося включити до C ++ 11.

Я дізнався, що мова програмування D 2.0 має схожу особливість для загального програмування. Її рішення мені здається досить елегантним та простим.

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

• Мета C ++ може бути більшою, ніж реалізація D?
• Або спадщина C ++ заважає їй застосовувати такий підхід?
• Або будь-який інший?

Дякую за відповіді

ps Щоб побачити кілька прикладів загальної потужності програмування D, зверніться до цього: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

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

Доповнення до стандартної бібліотеки були дещо легкими. Кілька бібліотек були в Бусті давно: було доведено, що вони працюють.

Однак доповнення до основних понять у мові набагато складніше експериментувати, оскільки спочатку потрібна модифікація компілятора. Функція C ++ 03 (експорт шаблонів) була визначена без підтримки компілятора ... результат був жахливим. Реалізатори інтерфейсу компілятора EDG повідомили про це як про величезне завдання (кілька чоловічих років) за дуже невеликий прибуток. Жоден інший компілятор ніколи не намагався його реалізувати. Це не комфортна ситуація.

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

З іншого боку, Концепції були оцінені занадто новими та неперевіреними . Їх ледве не було визначено в часі, доказів концепції не було ... і, отже, їх відкидали, а не чекали на них (або робили помилку).

Чому б не слідкувати за D? Немає приказок, що цього не буде. Комітет закликав людей переосмислити з нуля, не вимагаючи терміну, та спробувати їх включити до компілятора, щоб побачити, як вони взаємодіють з іншими особливостями мови. Зокрема, виникає питання про розмежування понять та концептуальних карт: вони повинні бути поєднані як одна чи ні?

FYI: В даний час існує філія Кланг, присвячена цьому експериментуванню, яку очолює Лариса Вуфо з університету Індіани.

Щодо стандарту 2011 року, над чим працювали концепції C ++, і в кінцевому підсумку вони були відкинуті від цього стандарту, оскільки вони не були «запечені достатньо». Робота продовжується над концепціями C ++, що може призвести до перетворення їх на наступний стандарт. Однак, можливо, деякі люди працюватимуть над пропозицією щодо наступного стандарту, що є подібним до обмежень шаблону D. Буде це чи ні, залишається побачити. Наскільки я знаю, такої пропозиції для стандарту 2011 року не було, тому не було шансів перетворити її на цей стандарт незалежно від його достоїнств, але що буде чи не перетворить його на наступний стандарт, абсолютно невідомо в цей момент.

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

Насправді, я думаю, що коротка відповідь полягає в тому, що немає жодної технічної причини, чому щось подібне до обмежень шаблону D не могло бути в C ++.

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

Ви маєте на увазі обмеження шаблону D?

Наскільки я знаю, від імені boost :: concept були запропоновані концепції C ++. Проблема тут полягає в тому, що boost - це бібліотека, написана для C ++ 03. C ++ 11 має інші можливості синтаксису, які дозволяють реалізувати певні речі по-іншому, як це дозволяє C ++ 03 (отже, сам поштовх може бути переписаний з використанням переваг нового синтаксису).

Стандартний комітет відмовився від понять, тому що для їх конкретизації знадобилося занадто багато часу (тим самим знову затягуючи затвердження c ++ 11). Вони, ймовірно, перейдуть у наступному випуску C ++.

Тим часом, синтаксис D відрізняється, тоді C ++ і D сам зберігають деякі можливості оцінки виразів під час компіляції, які C ++ не завжди може мати, не порушуючи застарілого коду (чогось у D не було, маючи коротшу історію). Сам C ++ зараз має static_assertі costexpr, що дозволяє вдосконалити можливості оцінювання часу компіляції. Можливо, в майбутньому вийде на аналогічний рівень.

Ось QA з Herb Sutter, він розмовляє про концепції на 15-хвилинній позначці.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

Якщо вам це подобається, ось ще один: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Тепер щодо вашого питання. Чому б не версія D? Ну навіщо це використовувати? C ++ - дуже складна і стабільна мова. Кожну особливість потрібно вибирати надзвичайно ретельно, оскільки її зазвичай потрібно підтримувати десятиліттями. Якщо ви подивитесь на перший стандарт C ++ і дотримуєтесь оновлень, є деякі застарілі функції, але навіть ті, які все одно повинні підтримуватися. Тож є сенс розробити концепції на 100% відповідність C ++.

Щодо того, чому він не був включений у C ++ 0x. Ну тому, що це було величезно. Ця пропозиція була завдовжки 100 сторінок і дуже важко реалізується. Було вирішено, що для відтворення цієї функції потрібно більше часу, поки вона не буде включена в стандарт.

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