[C++] Проверить существование типа (3 стр)

gammaker, ты всё правильно пишешь. Но можно не так поверхностно изгаляться, а с пристрастием. Можно определить оператор преобразования в угол  struct my_coord {float x; float y; float z}; Как это преобразование будет сделано - не важно. Например как я написал выше. Компилятор увидит его и будет возможность вызывать

my_coord pos_1;
float result=cos(pos_1);

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

>И что это за обычные контейнеры такие, которые даже обычнее, чем vector?
:) видимо мы сходим сума разными способами.

Ghost2
Затем, чтобы реализовать концепты, которых в C++ пока не завезли. Это как интерфейсы, только не на виртуальных функциях в рантайме, а во время компиляции на шаблонах со всеми соответствующими возможностями оптимизации. Если я то же самое сделаю на виртуальных функциях, у меня производительность просядет раз в 10 наверное из-за того, что компилятор не сможет заинлайнить + куча индирекций, которые приведут к проблемам с кешем.

KKH
> Можно определить оператор преобразования в угол  struct my_coord {float x;
> float y; float z};
Обычно у людей есть здравый смысл и они такого не делают. А если это ещё и в команде делать, то такому человеку быстро по рукам надают или уволят даже.

gammaker

> сделаю на виртуальных функциях
> производительность просядет раз в 10 наверное
Если у тебя узкие места кода завязаны на изменяемое в рантайме поведение, то это глобальная проблема орхетектуры, а не виртуальных функций. И шаблонами ты тут только убьёшь возможность все это поддерживать и, не дай Бог, наращивать. Потом, даю 146%, что тупая компиляция модулей из одной единицы трансляции даст больше, чем весь этот концепт-программизм.

gammaker
> Если я то же самое сделаю на виртуальных функциях, у меня производительность
> просядет раз в 10 наверное из-за того, что компилятор не сможет заинлайнить +
> куча индирекций, которые приведут к проблемам с кешем.
кул-стори

gammaker

> куча индирекций, которые приведут к проблемам с кешем.
Ой, ну не надо говорить про кеш и индирекции без профайлера подмышкой. Кеш это не про концепты и трёхэтажные шаблоны, а про локальность данных в памяти.

Ghost2
> Если у тебя узкие места кода завязаны на изменяемое в рантайме поведение, то
> это глобальная проблема орхетектуры, а не виртуальных функций.
Кто сказал, что в рантайме? У меня в компайлтайме всё известно, поэтому я и использую шаблоны. У меня вполне может быть десяток вложенных функций, которые ничего не делают сами по себе или почти ничего не делают. Но поведение этих функций на каждом из шагов определяется типом, который в них передали. Этого можно было сделать двумя способами - с помощью интерфейсов с виртуальными функциями или шаблонов с концептами. Так как всё известно в компайлтайме и надо, чтобы всё инлайнилось, я делаю на шаблонах.
Если тип реализует некоторый интерфейс, значит у него есть все методы, определяемые этим интерфейсом. Концепты - это и есть аналог интерфейса, но только для шаблонов - статического полиморфизма. Вот их мне и приходится эти концепты реализовывать самому, так как в стандарт их ещё не завезли.

Ghost2
> Кеш это не про концепты и трёхэтажные шаблоны, а про локальность данных в
> памяти.
И локальность кода тоже. Шаблоны позволят компилятору заинлайнить 10-этажный вызов маленьких функций в один кусок кода, а если делать на виртуальных функциях, то их так и останется 10 штук, да ещё и косвенными переходами. А если поместить всё это в цикл, то разница будет очень ощутима. А у меня как раз подразумевается, что всё это в 99% будет в циклах, а то и в двойных. И такие циклы будут не в одном тормозном месте, а повсеместно по всей программе.
А затевается всё это ради повышения продуктивности разработчика. Вместо того, чтобы мыслить циклами, ветвлениями и другими простейшими понятиями, можно будет создавать любые алгоритмы из маленьких универсальных кусочков, легко комбинирующихся друг с другом. А уже компилятор все эти кусочки должен будет заинлайнить в один большой цикл, который иначе пришлось бы писать самому.

gammaker

> Кто сказал, что в рантайме?
Ты сам сказал, что если делать без шаблонов, то придется использовать виртуальные функции.
Какой там полиморфизм - статический или динамический, с точки зрения архитектуры, совершенно до лампочки.

> Шаблоны позволят компилятору заинлайнить 10-этажный вызов маленьких функций
Кто же делает в здравом уме 10-ти этажный стек вызовов в критических для производительности местах?

> И локальность кода тоже.
Увеличить локальность кода путем намеренного раздувания его шаблонами статического полиморфизма и инлайном? Самому то не смешно?
Потом, средняя программа проводит 90% своего времени в 10% кода. Теперь возьми свой бинарник, который, как знает весь форум, меньше дебажного хеллоуворлда, подели его размер на 10 и сравни с размером кеша у современных процессоров.

> А если поместить всё это в цикл, то разница будет очень ощутима.
Разница будет ощутима при первом запуске цикла. Почитай наконец как работает кеш.

> можно будет создавать любые алгоритмы из маленьких универсальных кусочков
Можно в двух словах описать какой-нибудь из этих алгоритмов?

Ghost2
> Кто же делает в здравом уме 10-ти этажный стек вызовов в критических для
> производительности местах?
Компилятор всё заинлайнит и будет 0-этажный относительно вызывающего кода. И будет так же быстро работать, потому что лишний код и лишние проверки компилятор выкинет.

Ghost2
> Увеличить локальность кода путем намеренного раздувания его шаблонами
> статического полиморфизма и инлайном?
Не будет там никакого раздувания. Будет как раз наоборот выбрасывание всего ненужного. Большинство из этих 10 этажей занимают по пол-строчки кода. Это либо всего лишь вызов следующей функции цепочки, либо иногда ещё добавляется какая-нибудь проверка условия, приращение указателя или что-то типа того. В итоге вся цепочка свернётся к нескольким строкам кода, которые пользователь библиотеки мог бы написать вручную, оперируя более низкоуровневыми понятиями.
А вот если делать виртуальными функциями, то здесь ничего не заинлайнится и всё это дерево функций, да ещё и виртуальных, будет вызываться в рантайме. Пусть даже насчёт кеша я ошибаюсь, но вызов полупустых функций стоит дорого и оверхед будет в разы.

Ghost2
> Теперь возьми свой бинарник, который, как знает весь форум, меньше дебажного
> хеллоуворлда, подели его размер на 10 и сравни с размером кеша у современных
> процессоров.
L1 не такой уж и большой. Бинарник наверное не поместится. А кроме кода ведь ещё и данные какие-то есть.

Ghost2
> Можно в двух словах описать какой-нибудь из этих алгоритмов?
Ну вот например, придумал от балды:

Array<int> fibArr;
Recurrence(Algo::Op::Add<int>, 1, 1)
    .Take(19).Cycle().Drop(5).Take(80).Stride(3)
    .Filter([](int x){return x%8!=0;})
    .CopyTo(fibArr.Insert($));

Генерируем бесконечную последовательность Фибоначчи. Берём из неё первые 19 элементов. Зацикливаем их, опять получая бесконечную последовательность. Удаляем из неё первые 5 элементов. Потом берём 80 первых элементов. Потом берём из этой последовательности каждый третий элемент, начиная с нулевого (0-й, 3-й, ..., 78-й), отбрасываем числа, которые делятся на 8 и записываем то, что осталось, в массив fibArr.
Никаких промежуточных массивов не выделяется. Действия аккумулируются в возвращаемых объектах. Это получился такой паттерн декоратор на шаблонах. В конце метод CopyTo проходится по всем элементам результирующей последовательности и кладёт каждый из них в динамический массив.
Я пока ещё не проверял сгенерированный код и на производительность не тестировал, но теоретически компилятор должен был всё заинлайнить и выдать просто цикл. По крайней мере, создатели языка D, у которого всё это есть в стандартной библиотеке и реализовано на шаблонах, говорят, что у них всё инлайнится и даёт такой же быстрый код, как и нативный.
А с виртуальными функциями такое заинлайнить просто нереально. Может только Java с её виртуальной машиной может такое сделать, потому что там есть подобные штуки, а шаблонов нет.

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

gammaker

> Бинарник наверное не поместится.
Ты так рассуждаешь, будто работаешь на голом железе. В L1 и без твоих бинарников тесно, так что можешь даже не рассчитывать туда персистентно попасть.

> Ну вот например, придумал от балды:
От балды не надо. Мне бы из продакшена. А то, что можно позолотить и отделать бриллиантами засохшую какашку, я и сам догадываюсь.

Ghost2
> Ты так рассуждаешь, будто работаешь на голом железе. В L1 и без твоих
> бинарников тесно, так что можешь даже не рассчитывать туда персистентно
> попасть.
Ну так тем более. К чему тогда был этот твой аргумент?

Ghost2
> От балды не надо. Мне бы из продакшена.
Чего сразу продакшен? Ещё до продакшена дело не дошло. Надо до конца сначала это реализовать, а потом думать, какие циклы, которые мне долго и упорно приходилось писать раньше, например для моего движка, можно на это заменить.
А за продакшеном иди в Facebook. Там серверный софт пишут на D, наверняка там это используется. Потому что то, что я показал выше - одна из фич стандартной библиотеки, которой гордятся создатели языка и приводят во многих демонстрационных кусках кода.

gammaker

> К чему тогда был этот твой аргумент?
К тому, что жить частично в L2 это тоже очень неплохо. Но, как я уже говорил, шаблоны этому никак не способствуют.
Если конечно ты не фанат секса с числами Фибоначчи.

> Надо до конца сначала это реализовать, а потом думать, какие циклы
Сначала реализовать, потом думать. Да это просто девиз юного говнокодера.

gammaker
> Я пока ещё не проверял сгенерированный код и на производительность не тестировал
  Как же ты мог совершить такую оплошность. А я вот не поленился и проверил. Специально написал на Clojure, к которой в плане оптимизации уж точно не привязаться, где всё на списках и рекурсии без оптимизации виртуальных вызовов, а про кэш-френдли код там вообще не слышали (да и геморно пока на яве писать функциональный код, половины операций в стандартной библиотеке нет, а хочется написать без использования сторонних либ).

Результат просто поражает своими тормозами - эта фигня (кстати, на выходе всего 6 чисел) посчиталась миллион раз за 150 милисекунд. Да, очень требовательная к ресурсам операция, ничего не скажешь :)
  И это пример, где бойлерплейт-инструкции занимают почти всё время работы алгоритма. Если бы промежуточные операции были хоть немного осмысленные, то они занимали бы уже столько времени, что потери на обвязку затерялись бы в общем хронометраже и их оптимизации совсем потеряли бы смысл.

> Никаких промежуточных массивов не выделяется.
  Я почему-то сразу увидел, что как минимум зацикливание потребует промежуточный массив, а ты нет, хотя сам это написал.

Zefick
> Как же ты мог совершить такую оплошность.
Это не оплошность, всему своё время, сначала надо кое-что ещё доделать.

Zefick
> А я вот не поленился и проверил.
Во-первых ты взял другой язык, где всё это есть, а во-вторых я имел в виду именно сравнение производительности с вручную написанным циклом. А здесь не с чем сравнивать.

Zefick
> Результат просто поражает своими тормозами - эта фигня (кстати, на выходе всего
> 6 чисел) посчиталась миллион раз за 150 милисекунд. Да, очень требовательная к
> ресурсам операция, ничего не скажешь :)
Что-то у меня сарказмодетектор барахлит. Это был сарказм или нет? Вывод о тормознутости на основе чего сделан? Ведь тормознутость - понятие относительное, надо с чем-то сравнивать.

Zefick
> Я почему-то сразу увидел, что как минимум зацикливание потребует промежуточный
> массив, а ты нет, хотя сам это написал.
Потому что я не вижу массивов там, где их нет. А у меня в реализации зацикливания их нет. Массив только в одном месте - куда выводится результат.

gammaker
> Во-первых ты взял другой язык, где всё это есть
  И поэтому он так быстро работает? Тогда может ну его на фиг этот С++, раз он не только ничего не умеет, так ещё и тормозит?

> Ведь тормознутость - понятие относительное, надо с чем-то сравнивать.
  А ты с чем-то уже сравнивал, когда говорил, что код на шаблонах в десять раз быстрее? Кажется я что-то пропустил. Хотя нет, написано же "Я пока ещё не проверял сгенерированный код и на производительность не тестировал", тогда всё нормально :)
  Я просто предположил, что мой вариант самый тормозной из всех, что только может быть и если даже он такой быстрый без всяких шаблонов, то целесообразность в дальнейших оптимизациях находится под большим сомнением. А что он быстрый я думаю это очевидно, миллион это тебе не хрен собачий, ты в своём движке наверное вообще ни разу такого количества никаких однотипных операций не делал, тем более за такое время.

> А у меня в реализации зацикливания их нет.
  Ну тут одно из двух, либо ты восемьдесят раз считаешь числа фибоначчи, либо тебе надо дать премию Тьюринга. Чем первый вариант хуже сохранения 19 чисел в массив я думаю объяснять не надо и что будет в случае, если исходный поток вообще не поддерживает повторного вычисления - тоже.