Boost.Preprocessor для себя откройте:) Я открыл (немножко)… оказалось что на макросах можно делать ТАКИЕ вещи… фактически можно вводить новые языковые возможности. Я даже не понимаю как оно работает… а оно работает. Причем это даже не С++, в чистом Си такое тоже будет работать. Говорят еще в libCello тоже на макросах сделали фактически новый язык, хотя формально это всего лишь библиотека на Си.
Что они все так осторожничают… «алгоритмов «некоторых аспектов» управления автомобилем»… Пора уже включаться в гонку разработки полностью самодостаточных автомобильных автопилотов, а не «некоторых систем»…
А что не так с заголовком? Я еще несколько дней назад прочитал об этом то-ли на реддите то-ли на hackernews. Заготовок там в точности такой же только на английском.
А можно для каждого числа сохранять количество делителей, отличающихся от единицы и самого числа. Простые числа — это частный случай с таким количеством делителей равным нулю.
Вообще интересно построить какие-нибудь графики по этим данным… например чтобы увидеть, как количество простых чисел уменьшается с увеличением x…
y=количество_простых_чисел_до(x)
по идее должно быть что-то типа sqrt(x)
ну и дальше поиграть с масштабами, чтобы понять что за кривая.
ИМХО можно было включить обработку унарных плюса и минуса в парсер напрямую. Еще кроме унарных плюса и минуса есть еще унарная битовая инверсия, унарная логическая инверсия… символы которых вполне могут использоваться и как бинарные опрерации.
Унарные и бинарные операции имеют разное число аргументов, поэтому должны нормально различаться парсером без всяких дополнительных действий (по крайней мере для рекурсивного спуска так, думаю что все эти алгоритмы примерно работают схожим образом)
Да ладно. Есть как минимум две платные книги по D и одна бесплатная.
Платные:
Andrei Alexandrescu — The D Programming Language (в том числе перевод на русский)
Adam D. Ruppe — D Cookbook
Бесплатная: Ali Çehreli — Programming in D
Я кстати имел в виду кстати не лямбды, а именно блоки кода, включаемые на этапе компиляции. Отличие в том, что лямбды вызываются (то есть генерируется код вызова функции), а при прямой подстановке никаких вызовов не происходит. Я занимался embedded программированием, там в условиях очень ограниченных ресурсов приходилось писать такие вещи с помощью обычных макросов.
Например, в шаблоны С++ можно передавать целые числа; они передаются не через стек в рантайме, а напрямую встраиваются в код во время компиляции. Я считаю, что совершенно аналогично можно сделать передачу произвольных сущностей времени компиляции, в частности блоков кода
template<block B>
void foo()
{
// do something
B; // это не вызов, а именно подстановка кода напрямую
// do something
}
// ...
foo<{ bar1(); }>();
Да, там будут проблемы с «гигиеничностью» (смешиванием имен из блока B и имен из самой функции foo), но все вполне решаемо.
Идея миксинов очень правильная, но реализация (строки в кавычках) мне концептуально не нравится — так как теряется возможность подсветки синтаксиса в IDE (нет возможности отличить обычную строку от фрагмента кода). Лучше как в Nemerle — в специальных скобках для квазицитирования.
Хотя в данном случае и квазицитирования не надо, достаточно разрешить передачу в шаблоны блоков кода в фигурных скобках. Такое кстати можно и в С++ ввести с минимальными изменениями в синтаксисе.
(ответ olegmax )
Все что называется «language feature emulation», многое из «metaprogramming» и «generic programming».
Из вашего списка пожалуй type traits, может быть polymorphic wrappers for function objects.
Tuples однозначно, их нужно на уровне синтаксиса слить со списками инициализации. Тогда можно писать выражения вида {i, j, k}=10; или {i, j, k} = {10,20,30}, множественные возвраты из функий — и все красивым и естественным путем.
Еще:
Any, Optional, Variant — должна быть прямая языковая поддержка; для опционального типа взять "?" из C#.
Все что касается эмуляции концептов.
Вообще шаблоны нужно расширить так, чтобы они плавно переходили в синтаксические макросы, я пожалуй в новогодние каникулы статейку напишу по этому поводу.
Полноценные функциональные типы должны быть встроены в язык и иметь синтаксис вида (char,float)=>int
Сигналы и слоты скорее всего должны быть встроены в язык на уровне синтаксиса с реализацией по умолчанию, но с возможностью переопределять реализацию
Сопрограммы безусловно на уровне синтаксиса в язык
Ну и т.д, я всего буста не знаю к сожалению, но там несомненно найдется еще много кандидатов.
Разумеется, в виде библиотек должны остаться такие вещи как математика, файловая система, регулярные выражения, случайные числа… То есть общая идея — в язык вносится все то, для чего нужна работа с AST, типизатором, кодогенератором. Все, что не касается языка как такового — остается в виде библиотек.
Сколько всего понапридумывали люди, нет чтобы просто добавить именованные параметры в язык и не мучаться! Я в каком-то давнем обсуждении даже синтаксис предлагал — unary dot notation.
void foo(int x=1, int y=2, int z=3) {}
foo(.y=100, .z=200, .x = 300);
foo(.z=500);
Вообще это печальная сторона С++. С одной стороны, программисты реально хотят появления новых языковых возможностей — отсюда появляются и активно используются библиотеки типа Boost. С другой стороны, новые возможности в сам язык вводить не спешат… костыли из Буста становятся все более распространенными, а затем их начинают затаскивать в стандарт, они попадают в стандарт, и получается, что вроде как и возможность реализована — но каким-то немыслимо кривым и вывернутым способом. Вместо добавления небольшого количества простого и понятного кода в компилятор добавляют огромное количество непонятного кода на шаблонах в библиотеку.
Так часовые пояса хранятся же где-то? Или в реестре или в какой-то DLL. Что мешало просто заменить старую информацию на новую? А системное время все равно останется неизменным — все эти часовые пояса, локальное время и переход на летнее время должны использоваться по идее только для отображения.
Простите, а мы разве переходили на летнее/зимнее время в 2014 году? ИМХО мы просто часовые пояса сменили. И именно такой патч логично было выпустить Майкрософту.
(ЗЫ вещи чинить люблю, в этом есть некая творческая составляющая)
Вообще интересно построить какие-нибудь графики по этим данным… например чтобы увидеть, как количество простых чисел уменьшается с увеличением x…
y=количество_простых_чисел_до(x)
по идее должно быть что-то типа sqrt(x)
ну и дальше поиграть с масштабами, чтобы понять что за кривая.
Унарные и бинарные операции имеют разное число аргументов, поэтому должны нормально различаться парсером без всяких дополнительных действий (по крайней мере для рекурсивного спуска так, думаю что все эти алгоритмы примерно работают схожим образом)
Платные:
Andrei Alexandrescu — The D Programming Language (в том числе перевод на русский)
Adam D. Ruppe — D Cookbook
Бесплатная:
Ali Çehreli — Programming in D
Например, в шаблоны С++ можно передавать целые числа; они передаются не через стек в рантайме, а напрямую встраиваются в код во время компиляции. Я считаю, что совершенно аналогично можно сделать передачу произвольных сущностей времени компиляции, в частности блоков кода
Да, там будут проблемы с «гигиеничностью» (смешиванием имен из блока B и имен из самой функции foo), но все вполне решаемо.
Хотя в данном случае и квазицитирования не надо, достаточно разрешить передачу в шаблоны блоков кода в фигурных скобках. Такое кстати можно и в С++ ввести с минимальными изменениями в синтаксисе.
Все что называется «language feature emulation», многое из «metaprogramming» и «generic programming».
Из вашего списка пожалуй type traits, может быть polymorphic wrappers for function objects.
Tuples однозначно, их нужно на уровне синтаксиса слить со списками инициализации. Тогда можно писать выражения вида {i, j, k}=10; или {i, j, k} = {10,20,30}, множественные возвраты из функий — и все красивым и естественным путем.
Еще:
Any, Optional, Variant — должна быть прямая языковая поддержка; для опционального типа взять "?" из C#.
Все что касается эмуляции концептов.
Вообще шаблоны нужно расширить так, чтобы они плавно переходили в синтаксические макросы, я пожалуй в новогодние каникулы статейку напишу по этому поводу.
Полноценные функциональные типы должны быть встроены в язык и иметь синтаксис вида (char,float)=>int
Сигналы и слоты скорее всего должны быть встроены в язык на уровне синтаксиса с реализацией по умолчанию, но с возможностью переопределять реализацию
Сопрограммы безусловно на уровне синтаксиса в язык
Ну и т.д, я всего буста не знаю к сожалению, но там несомненно найдется еще много кандидатов.
Разумеется, в виде библиотек должны остаться такие вещи как математика, файловая система, регулярные выражения, случайные числа… То есть общая идея — в язык вносится все то, для чего нужна работа с AST, типизатором, кодогенератором. Все, что не касается языка как такового — остается в виде библиотек.
Вообще это печальная сторона С++. С одной стороны, программисты реально хотят появления новых языковых возможностей — отсюда появляются и активно используются библиотеки типа Boost. С другой стороны, новые возможности в сам язык вводить не спешат… костыли из Буста становятся все более распространенными, а затем их начинают затаскивать в стандарт, они попадают в стандарт, и получается, что вроде как и возможность реализована — но каким-то немыслимо кривым и вывернутым способом. Вместо добавления небольшого количества простого и понятного кода в компилятор добавляют огромное количество непонятного кода на шаблонах в библиотеку.