История изменений
Исправление
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;
}
Исправление
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;
}
Исходная версия
MOPKOBKA,
:
Наверное не имеет смысла опираться на показанное в Haskell, слишком далекая от того что я хочу обсудить концепция.
Но толку с этого? Какой смысл сводить всё к одному и тому же?
Идея того что есть тип struct int_t {}; а сверху компилятор к типу привяжет некое значение, которым будет оперировать только в CT, кажется интуитивно хорошей.
Тем что компилятор не будет генерировать по сути ненужные копии методов add, mul, и сами эти функции могут быть например возвращенны как просто:
auto f()
{
return int_t_mul;
}