LINUX.ORG.RU

История изменений

Исправление MOPKOBKA, (текущая версия) :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT (и потом вставлять в asm результаты), кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}
Получается отложенная материализация шаблона.

А прямое встраивание в тип значения, как раз мешает этому, если рассматривать template <int n> int_t {};

Главное не терять это значение привязанное. Не знаю как лучше назвать такую пару тип+значения, пусть будет тип+.

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT (и потом вставлять в asm результаты), кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}
Получается отложенная материализация шаблона.

А прямое встраивание в тип значения, как раз мешает этому, если рассматривать template <int n> int_t {};

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT (и потом вставлять в asm результаты), кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}
А прямое встраивание в тип значения, как раз мешает этому, если рассматривать template <int n> int_t {};

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}
А прямое встраивание в тип значения, как раз мешает этому, если рассматривать template <int n> int_t {};

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}
А прямое встраивание в тип значения, как раз мешает этому.

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}

Исправление MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}

Исходная версия MOPKOBKA, :

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

Но толку с этого? Какой смысл сводить всё к одному и тому же?

Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.

Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:

auto f()
{
  return int_t_mul;
}