Rust 1.6

Ну если всё, что меньше прямого манипулирования RDBMS, — это не декларативное программирование, то много людей с тобою не согласятся.

Да причём тут RDBMS? :-) Суть в том, что ты не можешь написать цепепе-код, который будет выполняться при инстанцировании шаблонов :-) Всё, что ты можешь, это писать километровые typename, typedef, is_somewhat<T>, decltype(T1 * T2) и т.п. :-) Ты не можешь банально заставить работать cin >> x; :-)

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

Да это не декларативное программирование :-) Это примитивная директива вывести тип по неким аргументам :-)

Суть в том, что ты не можешь написать цепепе-код, который будет выполняться при инстанцировании шаблонов

А ты про constexpr-функции слышал? Я же говорю о современном С++, а не древнем. Но даже в древнем возможность выполнять рекурсивные вычисления была. Хоть и выглядело это очень коряво.

Да это не декларативное программирование :-)

Ну это уж как угодно. Главное — то, что метапрограммы выполнят значительную работу по подбору и согласованию типов компонентов. Что в противном случае нужно было бы делать ручками. Чем сложнее структура, тем больше будет такой работы.

//Психиатр

А ты про constexpr-функции слышал? Я же говорю о современном С++, а не древнем.

Слышал, слышал :-) Но, почему-то, у меня g++ -std=c++14 ... терпит фейл при компиляции вот этого банального кода:

#include <iostream>

constexpr void get_text(std::string& x)
{
  std::cin >> x;
}

int main(int argc, char *argv[])
{
  std::string x;
  get_text(x);
  std::cout << x << std::endl;
  return 0;
}

Подсказываю. Тебе нужно иначе «вводить данные» в компилятор. Сформируй массив констант и списки типов в исходнике. Если тебе нужно обрабатывать строки, представь их тоже списками char (есть и другие способы). А дальше всё в функциональном стиле...

Можно возразить, что компилятор загнется даже на самой простой задаче комбинаторной оптимизации, ввденной таким образом. Это верно, современные компиляторы сами по себе не ориентированы на то, что метапрограммы будут играть в шахматы. Но мы-то не лыком шиты, так? Мы можем изменить clang так, чтобы он оаспознавал наши структуры данных и компилировал метапрограммы в bit code оптимальным образом. После чего исполнял. И сразу всё станет на много радостнее. И, заметь, никакого дополнительного языка не вводится. Разве что ввод-вывод неудобный.

^//Психиатр

Подсказываю. Тебе нужно иначе «вводить данные» в компилятор. Сформируй массив констант и списки типов в исходнике. Если тебе нужно обрабатывать строки, представь их тоже списками char (есть и другие способы). А дальше всё в функциональном стиле...

Подсказываю :-) Мне надо банально выполнить цепепе-код во время компиляции - в данном случае - принять данные со стандартного ввода :-) Я код представил - std::cin >> x; :-) Если тебе нечего делать, представь и ты код с «массивами констант, списком типов, списком char (или другими способами), а дальше - в функциональном стиле» для банального считывания данных в компайл-тайме:-)

Но мы-то не лыком шиты, так? Мы можем изменить clang так, чтобы он оаспознавал наши структуры данных и компилировал метапрограммы в bit code оптимальным образом. После чего исполнял. И сразу всё станет на много радостнее

Ну давай, продемонстрируй, коли тебе делать нечего :-) Удачи тебе :-)

для банального считывания данных в компайл-тайме:-)

Ты, наверное, меня опять не понял. Для компилятора необходимо представлять все входные данные в виде структур, с которыми он работает. Это называется кодирование данных. Вот так, например, Boost Hana кодирует строки для метапрограмм. Как видишь, в записи

constexpr auto str = "Hello world!"_s;

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

Ну давай, продемонстрируй, коли тебе делать нечего :-) Удачи тебе :-)

Ой, ну напугал программиста программированием. Мне сейчас это без надобности, компилятор С++ и так переваривает все мои метапрограммы без проблем. Я тебе на словах продемонстрировал, как можно увеличить его возможности. Если такой вопрос встанет, будет найден и нанят человек под эту задачу. Или не под эту, так как задача, в общем-то, миддловская.

Просто не надо относиться к компилятору, как к священной корове. Он не такой уж и сложный внутри.

компилятор не имеет возможности обратиться к СУБД чтобы выяснить детали о том, как именно создать твой CoolSpatialIndex оптимально :-)

Требовать наличия подключения к СУБД для компиляции программы - это такая блестящая идея.

Ну это анонимуса понесло, да. Я хотел показать, что сложность метапрограммирования на С++ ограничена лишь возможностью компилятора по выполнению метапрограмм. Которые нетрудно будет радикально расширить.

//Психиатр

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

«Радикально» - это как, вызовом внешних программ или процедур? Вряд ли компиляторостроители настолько упоролись. А вычисление constexpr на основании данных, имеющихся в тексте программы, недостаточно радикально для улыбчивых дурачков.

В контексте противопоставления Rust-а C++у (ну или наоборот), может быть занимательно: Rust vs. C++: Fine-grained Performance

Ну это анонимуса понесло, да.

Так это же широко известный в узких кругах LOR-овских C++ников и Rust-оманов улыбчивый дурачок смайлик. Конструктивностью и адекватностью суждений до сих пор не отличался.

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

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

А уж такие чокнутые примеры, как подключение к СУБД во время компиляции, вытаскивание из СУБД схемы данных и генерации по этой схеме классов для ORM — этого вообще на практике не требуется по целому ряду причин. Начиная от маразматической идеи давать доступ к СУБД со всех машин, на которых возможен запуск компиляции, заканчивая необходимостью работать с разными диалектами SQL в СУБД от разных производителей (включая и возможность работать с разными версиями одной и той же схемы в одной и той же СУБД).

Так что как идиотский аргумент в форумных разборках — да, «C++ сосет, потому что не может в строку в компайл-тайм». На практике это никому не нужно.

«Радикально» - это как, вызовом внешних программ или процедур?

Нее. Всё проще. JIT-компиляция для метапрограмм стредствами LLVM (и аналогов). Сейчас метапрограммы выполняются в режиме интерпретации и очень неэкономны в плане представления некоторых типов данных (строки — списки типов, и т.п.). В результате сложную комбинаторную оптимизацию на них не запустишь. Смысла нет. А с JIT - будет. Вплоть до задействования GPU для этих целей.

Где это может пригодиться? Ну, например, если мы делаем новый язык поверх С++, с развитым метапрограммированием уровня системы типов.

Забыл подписаться. ^//Психиатр

JIT-компиляция для метапрограмм стредствами LLVM (и аналогов)

CTFE? Почему-то мне кажется, что если кому-то нужны метапрограммы такой сложности, он что-то делает не так.

В результате сложную комбинаторную оптимизацию на них не запустишь. Смысла нет. А с JIT - будет. Вплоть до задействования GPU для этих целей.

Подключение к СУБД для компиляции, вид сбоку.

CTFE? Почему-то мне кажется, что если кому-то нужны метапрограммы такой сложности, он что-то делает не так.

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

Но посмотри на это с другой стороны. Предположим, у нас уже накопилось много таких внешних решателей, а объем задач для них всё еще возрастает. Желание унифицировать механизм — вполне логично. И почему бы тогда не рассматривать C++ AST как IL?

В конце-концов, метапрограммы в Scala JIT-компилируемы. Чем С++ должен быть хуже?

Всё это может казаться безумием, но это всего лишь эффект новизны. Просто раньше так в С++ никто не делал, а если и делал, то помалкивал. Но мы ведь в будущее смотрим, так? Стандарты новые принимаем, где С++ заявляется как лучший язык для разработки библиотек. А в будущем эффективные средства метапрограммирования — один из основных факторов повышения продуктивности программиста. Программы должны писать себя сами.

//Психиатр

Предположим, у нас уже накопилось много таких внешних решателей, а объем задач для них всё еще возрастает. Желание унифицировать механизм — вполне логично.

Формулировки уже стали слишком абстрактными, но я еще отвечу: тот же Boost.Hana уже выглядит отвратительно, и делать унифицированное средство на его основе или на основе чего-то подобного - глупо. Другое дело - добавить в Си++ полноценный CTFE, но см ниже.

Но мы ведь в будущее смотрим, так? Стандарты новые принимаем, где С++ заявляется как лучший язык для разработки библиотек.

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

А в будущем эффективные средства метапрограммирования — один из основных факторов повышения продуктивности программиста. Программы должны писать себя сами.

Этому тезису столько же лет, сколько и Lisp-у. Странно, что в него еще верят.

«C++ сосет, потому что не может в строку в компайл-тайм». На практике это никому не нужно.

Не можем — значит не нужно. И так во всем, лол.

«C++ сосет, потому что не может в строку в компайл-тайм». На практике это никому не нужно.

Не можем — значит не нужно

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

Этому тезису столько же лет, сколько и Lisp-у. Странно, что в него еще верят.

А некоторые даже этим пользуются, лол.

А некоторые даже этим пользуются, лол.

Некоторые даже зарабатывают разработкой на COBOL и MUMPS. И?

например парсинг описания протокола и его последующая компиляция не отходя от кассы в один шаг.

Не можем — значит не нужно.

Как правило, когда бывает нужно, люди могут. Некоторые вот Boost.Spirit придумали, хотя, казалось бы, столько готовых генераторов лексеров и парсеров...

например парсинг описания протокола и его последующая компиляция не отходя от кассы в один шаг.

Это проблема только для тех, кто в IDE не может custom build step настроить. Остальные делают отдельный парсер и генератор, подключают их запуск в проектные файлы (хоть в make, хоть в cmake, хоть в scons) и имеют этот самый «парсинг описания протокола и его последующая компиляция не отходя от кассы в один шаг»

Причем безболезненно делается это еще со времен первых версий yacc-а и lex-а, если не раньше.

например парсинг описания протокола и его последующая компиляция не отходя от кассы в один шаг.

И преимущество парсинга в компайл-тайме перед парсингом в стиле yacc заключается... в чем именно?

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

А уж такие чокнутые примеры, как подключение к СУБД во время компиляции, вытаскивание из СУБД схемы данных и генерации по этой схеме классов для ORM — этого вообще на практике не требуется по целому ряду причин

Давай отвлечемся немного от контекста СУБД. Я здесь развивал идею, что С++ (и его аналоги по системе типов Rust и D) — это лучшие языки для разработки эффективных структур данных и обобщенного программирования над ними. Это очень надо в Big Data, здесь и сейчас. Big Data бежит из Java heap в offheap. А тут у С++/Rust/D пока нет равных (оставим пока в стороне проблемы роста Rust типа отсутствия HKT и специализации).

Специфика Big Data такова, что структур данных нужно очень много (есть математическое обоснование этого фактора). Отчасти мы это видим по PostgreSQL, который предлагает очень много всего на выбор. Но, поверь мне на слово, PG — это лишь песчинка на пляже по сравнению с тем, что уже наработано и пылится в архивах научных журналов. Из того, что не на слуху, но активно используется — это сжатые суффиксные деревья и массивы для биоинформатики и сжатые веб-графы.

Кстати, «веб-граф» — это статистика, отражающая особые свойства графов, кодирующих связи между ресурсами в WWW. «Социальный граф» — это другая статистика. И под эти статистики разрабатываются конкретные сжатые структуры данных (термины гуглятся). Такие статистики можно получать на основе сырых данных и затем скармливать метапрограммам, чтобы они вывели специализированные структуры данных для заданного случая из набора имеющихся шаблонов. Звучит как фантстика? С++ это вполне по силам. Короче, пример с подключением компилятора к СУБД для получения метаданных не такой уж высосанный из пальца, на самом деле.

Возвращаясь к PG, для примера, я думаю, что его базовые структуры данных (куча, таблицы, GiST, GIN) можно генерализовать средствами обобщенного программирования на С++, расширив фреймворк на поддержку других практичных но пока еще экзотических структур типа упомянутых мною выше. Можно его в итоге совсем «обобщить», приблизив к математическому идеалу. Вопрос трудоемкости пока оставим за скобками. Важно то, что практическая необходимость для этого есть — Big Data.

//Психиатр

преимущество парсинга в компайл-тайме

это был лишь простой пример.

Я здесь развивал идею, что С++ (и его аналоги по системе типов Rust и D) — это лучшие языки для разработки эффективных структур данных и обобщенного программирования над ними. Это очень надо в Big Data, здесь и сейчас.

А в BigData что, хранятся прямо бинарные данные? Или они извлекаются из SQL СУБД, преобразуются в бинарные, и обрабатываются уже в таком виде?

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

Непонятно только, почему это должны быть метапрограммы на CTFE-C++, а не обычные кодогенераторы на чем угодно.

Этот простой пример не показывает никаких преимуществ. Примеры посложнее есть?

Этому тезису столько же лет, сколько и Lisp-у. Странно, что в него еще верят.

Ну извини, в Java на метапрограммировании времени выполнения держатся весь ORM и DI, и еще очень много всего по мелочи. Всё вместе это именно то, что делает платформу эффективной. Весь код, который программы могут написать сами, пишется программами.

Про вытаскивание схемы из БД уже упоминали, но сказали что «НИНУЖНО».

Этот простой пример не показывает никаких преимуществ.

еще как показывает.

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

Три момента:

1. Когда я беру готовый генератор парсеров, то я переиспользую чужую экспертизу в реализации подобных инструментов. Ибо авторы Coco/R или ANTLR наверняка разобрались в теме лучше чем я.

2. Внешние инструменты, как правило, предлагают какие-то готовые средства для отладки и/или трассировки происходящего во время парсинга. Что значительно облегчает создание собственного парсера. Кроме того, разрабатывая внешний инструмент намного проще заниматься его отладкой и покрытием его тестами.

3. Зачастую для работы с описаниями уже есть сторонние инструменты, которые генерируют нужный мне итоговый код на C или C++. Взять, например, ASN.1-компиляторы или генераторы кода по описаниям Protobuf-а или Thrief-а. Их достаточно просто включить в свой билд-процесс, и не нужно самому заниматься парсингом и генерацией.

Так что все эти плюсы перевешивают озвученные вами минусы. Которые, повторюсь, имеют значение разве что для нубов, не умеющих работать без IDE.

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

Рад за CL. Только если вас CL настолько устраивает, что же заставляет вас приходить в тему про Rust и высмеивать возможности C++?

Про вытаскивание схемы из БД уже упоминали, но сказали что «НИНУЖНО».

Причем ненужно в квадрате - во-первых, компиляция требует подключения к СУБД, во-вторых, дублирование работы транслятора SQL. И да, тот же самый yacc-стиль позволяет сделать эту фигню, если уж очень хочется.

Ну извини, в Java на метапрограммировании времени выполнения держатся весь ORM и DI, и еще очень много всего по мелочи.

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

компиляция требует подключения к СУБД

выдуманная проблема

компиляция требует подключения к СУБД

выдуманная проблема

«Выдуманная» - в смысле «не требует» или в смысле «подключение - не проблема»?

что же заставляет вас приходить в тему про Rust и высмеивать

Ок.

возможности C++

А вас?

второе конечно

okay.jpg

А в BigData что, хранятся прямо бинарные данные? Или они извлекаются из SQL СУБД, преобразуются в бинарные, и обрабатываются уже в таком виде?

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

Непонятно только, почему это должны быть метапрограммы на CTFE-C++, а не обычные кодогенераторы на чем угодно.

Согласен, вопрос спорный. Я обычно руководствуюсь принципом бритвы Оккама. C++ AST вполне себе IL, пусть и для чисто-функционального языка (трудности с вводом-выводом). Может просто добавить к нему JIT? Благо, что примеров много.

А разве компиляция не требует запущенного компьютера?

Важно то, что практическая необходимость для этого есть — Big Data.

Я смотрю на вещи, связанные с метапрограммированием, немного более приземленно.

Бывают относительно простые вещи. Например, нужен мне вектор фиксированного размера на стеке для хранения промежуточных результатов каких-то расчетов. И размер этого вектора зависит от параметров расчета. Было бы здорово уметь вычислять константу времени компиляции на основании типов этих параметров. Грубо говоря:

template< typename Data, typename Method, typename Range >
auto calculate(const Data & d, const Method & m, Range r )
{
  typename Method::temp_value_type tmp_value[calc_tmp_value_size<Data, Method, Range>()];
  ...
  return ...;
}

Бывают более сложные вещи. Например, есть класс для тестирования чего-нибудь:

class MyUnitTest : public super_unit_test_framework::unit_test
{
public :
  void test_simple() { ... }
  void test_complex() { ... }
  void test_yet_more_complex() { ... }
  ...
};

MyUnitTest t;

t.set_up(); t.test_simple(); t.tear_down();
t.set_up(); t.test_complex(); t.tear_down();
...

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

Ну и за неимением таких продвинутых инструментов уже научились эти задачи решать несколько иначе.

Ты, наверное, меня опять не понял. Для компилятора необходимо представлять все входные данные в виде структур, с которыми он работает. Это называется кодирование данных.

Ты начал с декларативного программирования, теперь ты в уши льёшь про «кодирование данных» :-) Где в декларативном выражении: «SELECT * FROM table» ты видишь входные данные в виде структур? :-)

constexpr auto str = «Hello world!»_s;
нет ничего суперсложного. На уровне компилятора она раскроется в список констант. Так можно представлять любые примитивные структуры данных.

Зачем мне эти примитивные примеры как в книжках про цепепе различных облысевших теоретиков? :-)

Ой, ну напугал программиста программированием.

Конечно, напугал :-) Как часто цепепешники пилят clang, чтобы он что-то делал с их кодом, что не укладывается в 1300 страничный стандарт? :-) Или ты психиатр-клоун? :-)

Требовать наличия подключения к СУБД для компиляции программы - это такая блестящая идея.

Для специально-одарённых, спич о том, что в любимом тобой ущербном цепепе в компайл-тайме сделать нельзя ничего вообще, кроме как онанировать на аргументы шаблонов, которые могут быть шаблонами с аргументами :-)

А вас?

Я уже говорил: мне непонятно, почему так многим не понятно, почему C++ именно такой.

Так это же широко известный в узких кругах LOR-овских C++ников и Rust-оманов улыбчивый дурачок смайлик. Конструктивностью и адекватностью суждений до сих пор не отличался.

Жень, ты усвоил хоть, что «string»[1] = 0 делать нельзя в цепепе, или нет? :-)

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

Это актуально лишь для таких недоразумений, как цепепе :-) Там нет метапрограммирования, там жалкое-жалкое подобие оного :-)

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

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