Язык программирования компилятора в C++

@[progeR] · Регистрация: 20.08.2011

Студворк — интернет-сервис помощи студентам

Добрый день!
Разглядывая новые возможности С++11 (С++14) и читая статьи, посвященные шаблонам, мне пришла в голову мысль - по сути шаблоны - это такой эдакий язык программирования компилятора. Посему возникает вопрос: а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)? Спецификация структур/функций/классов - своего рода ветвление на этапе компиляции (if-else). Рекурсия - цикл foreach (или for). Тогда type_traits.h, например, можно будет забыть навсегда, т.к. он по своей сути является эдаким "мета-костылем". Назвать его костылем в прямом смысле слова нельзя, но те же conditional, enable_if и прочее это обход, замена static_if.
Как-то так...

Как считаете вы?

@HelicopterK52 · 29.08.2016, 16:37

Сообщение от [progeR]

Как считаете вы?

Так добавят же constexpr if. Ждите.

А делать то же самое, но красивее... хм, попробуйте.
Я не пробовал, так что не в курсе.

@_Ivana · 29.08.2016, 17:24

Сообщение от [progeR]

а почему просто не взять и не сделать нормальное

Сообщение от [progeR]

Как считаете вы?

Я считаю, что "нормальное" уже давно сделано в языках с более нормальным метапрограммированием. А В С++, говорят, еще много чего надо сделать нормально - но комитет не спешит.

@Catstail · 29.08.2016, 17:52

[progeR], поясните, что значит "язык программирования компилятора".

@Mr.X · 29.08.2016, 19:16

Сообщение от [progeR]

а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого

Да я вот тоже думаю, если бы С++ был объектно-ориентированным языком, он бы инкапсулировал свою сложнось внутри себя, а снаружи казался бы простым, но он таки вываливает ее всю на программиста!

Добавлено через 1 минуту

Сообщение от Catstail

[progeR], поясните, что значит "язык программирования компилятора".

Ну, имеется в виду программирование вычислений на стадии компиляции.

@Catstail · 29.08.2016, 19:54

Сообщение от Mr.X

имеется в виду программирование вычислений на стадии компиляции.

- а откуда известно, что шаблоны реализованы именно так?

@EVP · 29.08.2016, 20:09

Сообщение от [progeR]

мне пришла в голову мысль - по сути шаблоны - это такой эдакий язык программирования компилятора. Посему возникает вопрос: а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)?

Сообщение от [progeR]

Как считаете вы?

Исключительно на мой взгляд с горки

как вариант:

Шаблоны пошли по декларативному-функциональному стилю программирования,
а С++ без шаблонов - императивный язык.

Для метапрограммирования в императивном стиле надо вводить новую подсистему метапрограммировани и новый программируемый парсер,
которые могли бы работать с помощью квазицитирования выражений и нового императивного скопа метапрограммирования

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
meta
{
    std::wstring names[] = {
        L"Example",
        L"Test"
    };
    for(const auto& name : names)
        добавитьКласс(
            <[
                class $name {
                public:
                    int value;
                };
            ]>
        );
    выполняемОстальныеМетаФункции();
}

с возможностью программировать парсер для дальнейшей обработки (хотя бы как в Nemerle, но можно сделать лучше :-) ).
Без программируемого парсера будут проблемы с расширением языка.

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

Где-то читал, что Страуструп идеологически не хочет(не хотел) допускать императивный стиль в метапрограммировании на C++.
Отсюда такие выкрутасы с шаблонами.

@castaway · 29.08.2016, 21:39

Сообщение от [progeR]

а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)?

Как по-вашему должен работать static_for? "Развёрнутый" цикл?
static_if - что он должен делать? Условная компиляция не подходит?
static_vars - это что такое? Константы? Так они есть.
static_switch - реализовано в виде шаблонов.
Шаблоны дают больше. Зачем всё это? Чем по-вашему текущее состояние языка является ненормальным?
Приведите выдуманный пример с мифическим ключевым словом, который будет нормальным.

@GbaLog- · 29.08.2016, 21:57

Не по теме:

Сообщение от castaway

"Развёрнутый" цикл?

Тогда у индусов работу отнимет компилятор. :D

@hoggy · 29.08.2016, 23:15

Сообщение от [progeR]

а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)?

а вы попробуйте изобразить синтаксис, который сможет отвечать следующей задаче:

класс A параметризуется параметром Б, который в свою очередь обязан быть классом.
если в этом классе есть метод @name определенной сигнатуры,
тогда класс A должен быть относледован от класса Ц,
а иначе, он должен быть отнаследован от шаблона Д,
параметризованного параметром Б.

вообще, дизайн современных шаблонов - это цена за их мощность и гибкость.
попытка изобрести что-то сопоставимое по мощности и гибкости,
которое при этом гармонично впишется в центральную тему с++ - ООП,
приведет к тому, что у вас получится такой же ~~нечитабельный говнокод~~ замороченный синтаксис.

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

Добавлено через 7 минут

Сообщение от castaway

static_if - что он должен делать?

ветвление на стадии компиляции, очевидно жеж.

есть такая байка, я не знаю, правда ли это:
его долгое время лобировали в комитете.
и больше всех сопротивлялся Страуструп.

но вроде бы он сдал позиции,
и статик_иф таки встал на очередь вступления
в будущие версии стандарта.

Сообщение от castaway

Зачем всё это?

упрощение синтаксиса.
борьба с синтаксической сложностью.

@castaway · 29.08.2016, 23:21

Сообщение от hoggy

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

+

Сообщение от [progeR]

мне пришла в голову мысль

Ваша мысль поверхностная. Вам стоит "мыслить глубже".

Добавлено через 4 минуты

Сообщение от hoggy

ветвление на стадии компиляции, очевидно жеж.

Есть условная компиляция, но я просто хотел услышать мнение ТС.

Сообщение от hoggy

упрощение синтаксиса.
борьба с синтаксической сложностью.

То же самое. Интересовало мнение из уст ТС.

@HelicopterK52 · 29.08.2016, 23:32

Сообщение от castaway

Есть условная компиляция

Имеете ввиду препроцессор?
Так он бесполезен для ветвлениях на типах и constexpr выражениях,
т.к. ничего ни о том, ни о другом не знает.

@[progeR] · 30.08.2016, 10:54 **[ТС]**

Так вот EVP в принципе неплохой пример привел.
А что касается static_if - это уже сказали правильно - ветвление на этапе компиляции. Тогда, например, для вычисления compile-time факториала не будет требоваться хвостовая функция (это просто пример, а жизненных примеров, где этот самый static if/constexpr if можно применить, я думаю, каждый найдет)).
static_for - статический цикл - цикл на этапе компиляции. Замена рекурсии, например (или наоборот - ее дополнение).
static_vars - compile-time переменные, которые в саму программу не попадут. Например использовать как вспомогательные переменные для вычислений каких-нибудь constexpr выражений. Ну, у кого опыта побольше - тот наверняка сталкивался с местами в коде, где такая возможность пригодилось бы.

И, я считаю, синтаксис может упростится. А возможно и само написание кода.

Или вот, например, есть constexpr функции. Но ведь не каждую функцию можно объявить constexpr. Должны быть выполнены определенные условия, например, если не ошибаюсь, такая функция должна иметь только один return. А так, пожалуйста, используя это гипотетическое подмножество, функция будет из коробки compile-time с несколькими return, if-else...

Ведь все от желания зависит - захотят, будет нечто подобное. И проблемы, которые возникнут при этом, тоже будут решены, и синтаксис будет придуман и прочее.

Вон, язык D, не оттого что ветер в голове гуляет, стали придумывать.

@HelicopterK52 · 30.08.2016, 11:03

Сообщение от [progeR]

Тогда, например, для вычисления compile-time факториала не будет требоваться хвостовая функция

Она и сейчас не требуется:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <iostream>
#include <cstdint>
 
 
constexpr uint32_t fact(uint32_t arg)
{
    if(arg == 0)
        return 1;
    uint32_t value = arg;
    for(--arg;arg>1;--arg)
        value *= arg;
    return value;
}
 
 
enum
{
    fact0 = fact(0),
    fact1 = fact(1),
    fact2 = fact(2),
    fact5 = fact(5),
};
 
int main()
{
    std::cout << fact0 << " " << fact1 << " " << fact2 << " " << fact5 << std::endl;
}

http://rextester.com/FOWC70327

Сообщение от [progeR]

static_for - статический цикл - цикл на этапе компиляции. Замена рекурсии, например (или наоборот - ее дополнение).

В constexpr функции, как видим, оно и так на этапе компиляции.

Сообщение от [progeR]

static_vars - compile-time переменные, которые в саму программу не попадут.

Так constexpr же есть. Просто его можно использовать не только в compile-time.

@castaway · 30.08.2016, 23:22

Сообщение от HelicopterK52

Имеете ввиду препроцессор?
Так он бесполезен для ветвлениях на типах и constexpr выражениях,
т.к. ничего ни о том, ни о другом не знает.

Да.
Я понимаю. А чем может быть полезна условна компиляция, основанная на constexpr и т.д. и т.п.?

@tapochka · 30.08.2016, 23:26

Сообщение от castaway

А чем может быть полезна условна компиляция, основанная на constexpr и т.д. и т.п.?

вместо enable_if например

@hoggy · 30.08.2016, 23:29

Сообщение от castaway

А чем может быть полезна условна компиляция, основанная на constexpr и т.д. и т.п.?

constexpr - это смелая попытка предоставить программисту возможность писать привычный ему код,
в привычном простом синтексисе, но так, что он будет исполняться времени компиляции.

в некотором смысле, движки в эту сторону именно то, что хочет ТС.

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

@Fulcrum_013 · 30.08.2016, 23:50

Сообщение от [progeR]

очему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)?

Это уже было. В PL/1. Но по каким то причинам от этого отказались даже при том что именно на PL/1 написан бортовой софт шаттлов. Наверное по причине того что такие штуки резко снижают воспринимаемость и читабельность алгоритма (ну хотя конечно не настолько насколько SFINAE),при этом отладка превращается в тихий ужас. А там где они действительно нужны не столько уж и много обычно кода чтобы нельзя было его продублировать, а после появления ООП не продублировать а написать один абстрактный базовый класс и несколько специализаций абстракции.

Добавлено через 9 минут
При этом не так уж и сложно сделать генератор программного кода на самом C++ для некоторых случаев где бывает необходимо куча подобного кода в котором точность подставляемых данных важнее интеллектуальности. С необходимостью создания таких генераторов сталкивался 2 раза - таблицы для подгрузки функций OpenGL и набор операторов для операций над 2D и 3D векторами и матрицами во всех вариантах урезания (т.е. матрица поворота, расширенная матрица, униформ матрица во всех сочитаниях).

Добавлено через 10 минут
А вот к примеру введение в стандарт свойств и полной RTTI (т.е. фактически доступ к словарю компиляции в рантайме) была бы на порядок удобнее и позволяла бы решать просто огромное количество сложных (в плане создания таблиц адресов геттеров и сеттеров и т.п. вручную) для сегодняшнего С++ задач (к примеру полиморфной сериализации/десериализации данных). Так же как и введение нативных делегатов многие бы задачи упростило бы и сделало бы инициализацию делегатов гораздо более читабельной и писАбельной чем пользуемые для этих средств костыли, при этом нативные делегаты работают всегда быстрее чем шаблонные или иные костыли на эту тему.

@DarkVortex · 31.08.2016, 00:10

Сообщение от [progeR]

он по своей сути является эдаким "мета-костылем"

Ну да, а мы сделаем еще один "мега-костыль"...

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@[progeR] 30 / 8 / 2 Регистрация: 20.08.2011 Сообщений: 615

	Язык программирования компилятора в C++ 29.08.2016, 16:35. Показов 1565. Ответов 18 Метки нет (Все метки) Добрый день! Разглядывая новые возможности С++11 (С++14) и читая статьи, посвященные шаблонам, мне пришла в голову мысль - по сути шаблоны - это такой эдакий язык программирования компилятора. Посему возникает вопрос: а почему просто не взять и не сделать нормальное подмножество языка С++ с нормальным синтаксисом и языковыми конструкциями для этого (static_for, static_if, static_vars, static_switch...)? Спецификация структур/функций/классов - своего рода ветвление на этапе компиляции (if-else). Рекурсия - цикл foreach (или for). Тогда type_traits.h, например, можно будет забыть навсегда, т.к. он по своей сути является эдаким "мета-костылем". Назвать его костылем в прямом смысле слова нельзя, но те же conditional, enable_if и прочее это обход, замена static_if. Как-то так... Как считаете вы? 0

@Catstail Супер-модератор 38160 / 21095 / 4306 Регистрация: 12.02.2012 Сообщений: 34,679 Записей в блоге: 14
	29.08.2016, 17:52
	[progeR], поясните, что значит "язык программирования компилятора". 0

@[progeR] 30 / 8 / 2 Регистрация: 20.08.2011 Сообщений: 615
	30.08.2016, 10:54 [ТС]
	Так вот EVP в принципе неплохой пример привел. А что касается static_if - это уже сказали правильно - ветвление на этапе компиляции. Тогда, например, для вычисления compile-time факториала не будет требоваться хвостовая функция (это просто пример, а жизненных примеров, где этот самый static if/constexpr if можно применить, я думаю, каждый найдет)). static_for - статический цикл - цикл на этапе компиляции. Замена рекурсии, например (или наоборот - ее дополнение). static_vars - compile-time переменные, которые в саму программу не попадут. Например использовать как вспомогательные переменные для вычислений каких-нибудь constexpr выражений. Ну, у кого опыта побольше - тот наверняка сталкивался с местами в коде, где такая возможность пригодилось бы. И, я считаю, синтаксис может упростится. А возможно и само написание кода. Или вот, например, есть constexpr функции. Но ведь не каждую функцию можно объявить constexpr. Должны быть выполнены определенные условия, например, если не ошибаюсь, такая функция должна иметь только один return. А так, пожалуйста, используя это гипотетическое подмножество, функция будет из коробки compile-time с несколькими return, if-else... Ведь все от желания зависит - захотят, будет нечто подобное. И проблемы, которые возникнут при этом, тоже будут решены, и синтаксис будет придуман и прочее. Вон, язык D, не оттого что ветер в голове гуляет, стали придумывать. 0