c ++ 11 — Существуют ли какие-либо языковые препятствия C ++, которые мешают переходу на D-диапазоны?

Мои знания C ++ 11 гораздо более ограничены, чем хотелось бы, поэтому могут быть более новые функции, которые улучшают вещи, о которых я еще не знаю, но есть три области, о которых я могу думать в данный момент которые по крайней мере проблематичны: шаблонные ограничения, static ifи введите самоанализ.

В D функция, основанная на диапазоне, обычно имеет шаблонное ограничение, указывающее, какой тип диапазонов она принимает (например, прямой диапазон по сравнению с диапазоном произвольного доступа). Например, вот упрощенная подпись для std.algorithm.sort:

auto sort(alias less = "a < b", Range)(Range r)
if(isRandomAccessRange!Range &&
hasSlicing!Range &&
hasLength!Range)
{...}

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

Теперь, хотя это может показаться улучшением юзабилити по сравнению с простым сообщением об ошибке компиляции, когда sort не может скомпилироваться, потому что тип не имеет правильных операций, он на самом деле оказывает большое влияние на перегрузку функций, а также на самоанализ типа. Например, вот два из std.algorithm.findперегрузки:

R find(alias pred = "a == b", R, E)(R haystack, E needle)
if(isInputRange!R &&
is(typeof(binaryFun!pred(haystack.front, needle)) : bool))
{...}R1 find(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle)
if(isForwardRange!R1 && isForwardRange!R2 &&
is(typeof(binaryFun!pred(haystack.front, needle.front)) : bool) &&
!isRandomAccessRange!R1)
{...}

Первый принимает иглу, которая является только одним элементом, тогда как второй принимает иглу, которая находится в переднем диапазоне. Эти два типа могут иметь разные типы параметров, основанные исключительно на ограничениях шаблона, и могут иметь радикально различный код внутри. Без чего-то вроде шаблонных ограничений вы не можете иметь шаблонные функции, которые перегружены на атрибуты своих аргументов (в отличие от перегрузки на самих конкретных типах), что значительно усложняет (если не делает невозможным) различные реализации, основанные на жанр используемого диапазона (например, диапазон ввода или прямой диапазон) или другие атрибуты используемых типов. В этой области в C ++ была проделана определенная работа с концепциями и похожими идеями, но AFAIK, C ++ по-прежнему серьезно не хватает функций, необходимых для перегрузки шаблонов (будь то шаблонные функции или шаблонные типы), основанных скорее на атрибутах их типов аргументов. чем специализация на конкретных типах аргументов (как это происходит со специализацией шаблона).

Связанная особенность будет static if, Это так же, как ifза исключением того, что его состояние оценивается во время компиляции, и true или же false фактически определит, какая ветка компилируется, а не какая ветка запускается. Это позволяет вам ветвить код на основе условий, известных во время компиляции. например

static if(isDynamicArray!T)
{}
else
{}

или же

static if(isRandomAccessRange!Range)
{}
else static if(isBidirectionalRange!Range)
{}
else static if(isForwardRange!Range)
{}
else static if(isInputRange!Range)
{}
else
static assert(0, Range.stringof ~ " is not a valid range!");

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

R find(alias pred = "a == b", R, E)(R haystack, E needle)
{
static if(isInputRange!R &&
is(typeof(binaryFun!pred(haystack.front, needle)) : bool))
{...}
else static if(isForwardRange!R1 && isForwardRange!R2 &&
is(typeof(binaryFun!pred(haystack.front, needle.front)) : bool) &&
!isRandomAccessRange!R1)
{...}
}

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

Скорее, static if отлично подходит для таких вещей, как специализация только части реализации вашей функции или для того, чтобы тип диапазона мог должным образом наследовать атрибуты типа диапазона, который он переносит. Например, если вы позвоните std.algorithm.map в массиве целых чисел результирующий диапазон может иметь нарезку (потому что диапазон источника имеет), тогда как если вы вызвали map в диапазоне, в котором не было срезов (например, диапазоны, возвращаемые std.algorithm.filter не может иметь срезы), тогда результирующие диапазоны не будут иметь срезов. Чтобы сделать это, map использования static if скомпилировать в opSlice только когда диапазон источника поддерживает это. В настоящее время, map код, который делает это выглядит

static if (hasSlicing!R)
{
static if (is(typeof(_input[ulong.max .. ulong.max])))
private alias opSlice_t = ulong;
else
private alias opSlice_t = uint;

static if (hasLength!R)
{
auto opSlice(opSlice_t low, opSlice_t high)
{
return typeof(this)(_input[low .. high]);
}
}
else static if (is(typeof(_input[opSlice_t.max .. $])))
{
struct DollarToken{}
enum opDollar = DollarToken.init;
auto opSlice(opSlice_t low, DollarToken)
{
return typeof(this)(_input[low .. $]);
}

auto opSlice(opSlice_t low, opSlice_t high)
{
return this[low .. $].take(high - low);
}
}
}

Это код в определении типа mapтип возвращаемого значения и то, компилируется ли этот код или нет, полностью зависит от результатов static ifs, ни одна из которых не может быть заменена специализациями шаблонов на основе определенных типов без необходимости написания нового специализированного шаблона для map для каждого нового типа, который вы используете с ним (что явно не подходит). Чтобы компилировать код, основанный на атрибутах типов, а не на конкретных типах, вам действительно нужно что-то вроде static if (который C ++ в настоящее время не имеет).

Третий важный элемент, который отсутствует в C ++ (и который я более или менее затрагивал) — это интроспекция типов. Тот факт, что вы можете сделать что-то вроде is(typeof(binaryFun!pred(haystack.front, needle)) : bool) или же isForwardRange!Range это важно. Без возможности проверить, имеет ли конкретный тип определенный набор атрибутов или что конкретный фрагмент кода компилируется, вы даже не можете написать условия, какие ограничения шаблона и static if использовать. Например, std.range.isInputRange выглядит примерно так

template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r = void;       // can define a range object
if (r.empty) {}   // can test for empty
r.popFront();     // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}

Он проверяет, что определенный фрагмент кода компилируется для данного типа. Если это так, то этот тип можно использовать в качестве входного диапазона. Если это не так, то не может. AFAIK, невозможно сделать что-либо даже смутно, как это в C ++. Но чтобы разумно реализовать диапазоны, вам действительно нужно уметь isInputRange или проверить, компилируется ли определенный тип с sort — is(typeof(sort(myRange))), Без этого вы не можете специализировать реализации, основанные на том, какие типы операций поддерживает определенный диапазон, вы не можете должным образом пересылать атрибуты диапазона при его переносе (а функции диапазона постоянно переносят свои аргументы в новые диапазоны), и Вы даже не можете должным образом защитить свою функцию от компиляции с типами, которые не будут работать с ней. И, конечно же, результаты static if и ограничения шаблона также влияют на самоанализ типа (поскольку они влияют на то, что будет и не будет компилироваться), поэтому эти три функции очень взаимосвязаны.

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

Другие функции, такие как миксины и унифицированный синтаксис вызова функций, также могут помочь, но они далеко не так фундаментальны. Миксины могут помочь в первую очередь в уменьшении дублирования кода, а UFCS помогает в первую очередь в том, чтобы сделать так, чтобы универсальный код мог просто вызывать все функции, как если бы они были функциями-членами, чтобы, если случается, что тип определяет конкретную функцию (например, find) тогда это будет использоваться вместо более общей, свободной версии функции (и код все еще работает, если такая функция-член не объявлена, потому что тогда используется свободная функция). UFCS не является принципиально необходимым, и вы могли бы пойти в противоположном направлении и отдать предпочтение бесплатным функциям для всего (как C ++ 11 сделал с begin а также end), хотя для того, чтобы сделать это хорошо, требуется, чтобы свободные функции могли проверять существование функции-члена, а затем вызывать функцию-член внутри, а не использовать свои собственные реализации. Итак, снова вам нужно самоанализ типа вместе с static if и / или шаблонные ограничения.

Как бы я ни любил диапазоны, на данный момент я почти отказался от попыток что-либо с ними сделать в C ++, потому что функций, которые делают их разумными, просто нет. Но если другие люди могут понять, как это сделать, тем больше у них власти. Независимо от диапазонов, я бы хотел увидеть такие функции усиления C ++, как ограничения шаблона, static ifи введите интроспекцию, потому что без них метапрограммирование путь менее приятный, в том смысле, что, хотя я делаю это все время в D, я почти никогда не делаю это в C ++.