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

Zefick
> А ты с чем-то уже сравнивал, когда говорил, что код на шаблонах в десять раз
> быстрее? Кажется я что-то пропустил.
Это слишком затратно делать две реализации, особенно заранее зная, какая из них проиграет. У меня нет столько времени. Достаточно будет сравнить с циклом, написанным руками, чем я займусь наверное где-то в ближайшие пару дней.

Zefick
> Я просто предположил, что мой вариант самый тормозной из всех, что только может
> быть и если даже он такой быстрый без всяких шаблонов, то целесообразность в
> дальнейших оптимизациях находится под большим сомнением.
Clojure же вроде на JVM работает? А ты вроде говорил, что у неё там супер возможности оптимизации, которые C++ даже и не снились?

Zefick
> А что он быстрый я думаю это очевидно, миллион это тебе не хрен собачий
И всё равно чисто психологически будет желание избегать использования этих range в пользу вручную написанных циклов, потому что использование неоптимизированных алгоритмов - это намеренное написание более медленного кода. И ладно если разница в 10-20% или даже 50%. И совсем другое дело, когда разница в разы, а то и в 10 раз.

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

Zefick
> либо ты восемьдесят раз считаешь числа фибоначчи
Не угадал, 85 раз.

Zefick
> Чем первый вариант хуже сохранения 19 чисел в массив я думаю объяснять не надо
Если нужен массив, надо перед .Cycle() дописать ещё .ToArray(). Но пихать массив в Cycle() не нужно, потому что тогда это получится сложный алгоритм, сочетающий в себе две разные вещи вместо одной.

Zefick
> и что будет в случае, если исходный поток вообще не поддерживает повторного
> вычисления - тоже.
Будет ошибка компиляции. FiniteForwardRange и выше поддерживают Cycle, а FiniteInputRange - нет. Но ToArray как раз из FiniteInputRange сделает FiniteRandomAccessRange, с которым можно делать всё что угодно.
И именно для различий между этими Input\Forward\Bidirectional\RandomAccess range я и ковыряюсь с шаблонами и создаю эти темы. Но большинство проблем уже решено. Осталось самое главное - максимальное наследование свойств диапазонами друг от друга.

gammaker
> Достаточно будет сравнить с циклом, написанным руками, чем я займусь наверное
> где-то в ближайшие пару дней.
  Это пишется за пару часов максимум если знаешь язык и то если только ты совсем слоупок.

> А ты вроде говорил, что у неё там супер возможности оптимизации, которые C++ даже и не снились?
  Ну если так, то тогда это ещё один повод задать вопрос на хрена использовать С++.

> И ладно если разница в 10-20% или даже 50%. И совсем другое дело, когда разница в разы, а то и в 10 раз.
  Да хоть в сто, если это 1% от всей работы, то ты сэкономишь доли кадра на оптимизациях и это только при условии, что FPS привязан к вычислениям (чего в нормальных движках уже давно не делают), иначе выигрыша не будет вообще никакого. А обычно подобная херомантия занимает даже меньше. Зато потом весело читать каскадные сообщения об ошибках на десять страниц (у нас ведь 10 вложенных шаблонов, каждый внесёт свой вклад в конечный выхлоп) и гадать где же что пошло не так.

Zefick
> Зато потом весело читать каскадные сообщения об ошибках на десять страниц (у
> нас ведь 10 вложенных шаблонов, каждый внесёт свой вклад в конечный выхлоп) и
> гадать где же что пошло не так.
Вот для этого и нужно сделать все эти проверки существования методов, чтобы поймать ошибку на раннем этапе. Тогда компилятор просто скажет, что нет подходящей функции, а внутрь не полезет.

Zefick
> Да хоть в сто, если это 1% от всей работы, то ты сэкономишь доли кадра на
> оптимизациях и это только при условии, что FPS привязан к вычислениям (чего в
> нормальных движках уже давно не делают), иначе выигрыша не будет вообще никакого.
А кто сказал, что это должно быть 1% работы и вообще чтобы это было в движке? Может я хочу свой синтезатор на это дело перевести? Для синтезатора это будет очень ощутимо.

Zefick
> Это пишется за пару часов максимум если знаешь язык и то если только ты совсем слоупок.
Да я и не сомневаюсь, что я это быстро напишу. Но я хотел бы всё оформить в виде теста производительности по всем моим правилам и наработкам, чтобы было красиво. Чтобы потом не стыдно было релизнуть эти тесты вместе с моей либой. Ну 2 часа наверное и уйдёт где-то. Но до этого надо другие дела сделать, которые у меня идут по плану.

gammaker
> Может я хочу свой синтезатор на это дело перевести? Для синтезатора это будет очень ощутимо.
  Тогда уж сразу и синтезируй во время компиляции, чё уж. Зачем зазря процессор и кэш напрягать выполнением своей проги? Тем более что там и так всё будет оптимизировано в ноль, так что только код заполнения файла константной информацией останестя :)

> Но я хотел бы всё оформить в виде теста производительности по всем моим
> правилам и наработкам, чтобы было красиво.
  Про юникод в консоли только незабудь, а то некрасиво будет :)

> Чтобы потом не стыдно было релизнуть эти тесты вместе с моей либой.
  Стыдно или не стыдно в твоём случае зависит совсем не от грамотности написанного, а от самоуверенности написавшего.

Zefick
> Тогда уж сразу и синтезируй во время компиляции, чё уж. Зачем зазря процессор и
> кэш напрягать выполнением своей проги?
Не понял, к чему этот комментарий. Надо чтобы юзер мог без всяких компиляторов exe'шнику подсунуть любой midi-файл и услышать его.

Zefick
> Про юникод в консоли только незабудь, а то некрасиво будет :)
Так он и так есть, я же на своих наработках всё делаю.

У меня ещё в HTML файл будут записываться результаты теста, где синеньким будет подсвечена более быстрая функция\класс, а красненьким - более медленная. Ещё будет написано, кто во сколько раз быстрее, ну и конечно время в миллисекундах.
Все тесты будут распределены по группам в спойлерах.

gammaker
> Нужна операция проверки существования типа, обратная enable if. То есть такое:
>
> exists<std::enable_if_t<false>>::value //== false
> exists<std::enable_if_t<true>>::value //== true
>
> На месте std::enable_if_t может быть любой аналогичный тип, который в
> зависимости от аргумента шаблона существует или нет, и с ним тоже должно
> работать.
> Возможно ли сделать это в C++?

Возможно. В чем проблема-то? Александреску стоит почитать

В самом простом варианте три строчки кода

gammaker
> Надо чтобы юзер мог без всяких компиляторов exe'шнику подсунуть любой midi-файл и услышать его.
  Эпичнее этого может быть только текстовый редактор, который показывает текст, который ты в него вставляешь.
  Насколько я помню в винде чтобы проиграть миди надо вызвать одну функцию, передав туда даже не содержимое файла, а только его название и никакого генератора самому писать ну нежно. В линуксе как обычно придётся скачать какой-нибудь пакет, где будут все нужные сэмплы и API для использования. Но правда линукс не нужен, а уж под макось ты точно делать ничего не будешь, не смотря на то, что она в сто раз более привлекательна.

> У меня ещё в HTML файл будут
  А не медленно ли? Я слышал, что HTML тормозит и требует наличия браузера для просмотра. Наверное стоит рассмотреть возможность оформлять результаты в виде PDF или картинки.

ZeroCool++
> Возможно. В чем проблема-то? Александреску стоит почитать
Просмотрел содержание, не нашёл. Ты ведь имел в виду "Современное проектирование на C++"? Это вроде уже древняя книга, без C++11 многие вещи реализовать нельзя.

ZeroCool++
> В самом простом варианте три строчки кода
Это строчки, которые можно переиспользовать снова и снова или для каждой проверки надо писать по 3 строчки? Если первое, то давай сюда, а если второе, то у меня уже есть такое. В принципе устраивает и уже даже работает, но если бы любую проверку можно было свести к одной строчке кода, было бы лучше.

Zefick
> Насколько я помню в винде чтобы проиграть миди надо вызвать одну функцию,
> передав туда даже не содержимое файла, а только его название и никакого
> генератора самому писать ну нежно.
Так смысл в том, что каждый синтезатор звучит по-своему. Мой же ещё и не привязан к платформе (как виндовый синтезатор к винде) и занимает всего 56 килобайт - меньше некоторых midi. Никаких семплов не требует, потому что всё генерируется кодом. Для этого приходится считать сотни миллионов синусов в секунду, накладывать всякие эффекты и ещё некоторую часть составляют пилообразные волны. Есть даже версия, работающая в браузере, только в 5 раз медленнее и в 10 раз больше весит. Правда я ещё не разобрался, как дать пользователю возможность скормить моей программе в браузере midi файл, потому что в веб-программировании не разбираюсь.

Zefick
> А не медленно ли? Я слышал, что HTML тормозит и требует наличия браузера для просмотра.
Браузер как раз есть по умолчанию у всех. У меня всё летает. Тормозить HTML не будет, так как это не язык программирования, а язык описания страниц. А то, что браузер жрёт много ресурсов - это не мои проблемы, так как его писал не я. А вот сам я стремлюсь писать код, который не тормозит.
И кстати, HTML файл мало места занимает, в отличие от PDF и картинки. А PDF просмотрщики ещё и тормозят порой сильнее браузеров.

gammaker
> Мой же ещё и не привязан к платформе (как виндовый синтезатор к винде) и
> занимает всего 56 килобайт
  Кто будет считать эти килобайты, когда всё нужное уже есть в ОС и не занимает места в бинарнике вообще? :)

> Так смысл в том, что каждый синтезатор звучит по-своему.
  И ты решил создать ещё один, который звучит по своему. Как знакомо.

> Есть даже версия, работающая в браузере, только в 5 раз медленнее и в 10 раз больше весит.
  Потому что написана на чудо-технологии emscripten, которую иначе как очковтирательством для дурачков не назовёшь.

Zefick
> Кто будет считать эти килобайты, когда всё нужное уже есть в ОС и не занимает
> места в бинарнике вообще? :)
В разных ОС они разные. В винде хорошо звучит, но его оттуда не вытащишь. В линухе вообще нет, а если ставить пакетом, то этот пакет будет весить в сотни раз больше. В Андроиде звучит плохо, половины инструментов нет, мой даже получше звучит. И мой одинаково звучит во всех ОС. Можно на основе него делать музыку в игре, которая одинаково звучит на всех платформах.

Zefick
> И ты решил создать ещё один, который звучит по своему. Как знакомо.
Картинка не в тему вообще. Я не задавался целью сделать единый стандарт. Мне просто было интересно разобраться с синтезом звука, потом я увлёкся и сделал синтезатор. К тому же мой синтезатор уникален своим маленьким размером и тем, что не использует семплы. Так что можно сказать, у него есть своя ниша.

Zefick
> Потому что написана на чудо-технологии emscripten, которую иначе как
> очковтирательством для дурачков не назовёшь.
Ну не написана, а скомпилирована в emscripten. Так-то 99% кода остались теми же.

gammaker
> На месте std::enable_if_t может быть любой аналогичный тип, который в
> зависимости от аргумента шаблона существует или нет, и с ним тоже должно
> работать.
> Возможно ли сделать это в C++?

проблема здесь в том,
что проверить факт существования типа - не достаточно для практического использования.
нужна ещё возможность проверить времени компиляции является ли тип полным.

но на языке с++ это не представляется возможным.

если тип - шаблонный, тогда нет универсального и достоверного способа выяснить,
является ли он полным.

SFINAE - костыль, который используется в потрохах детекторов не умеет "глубоко копать".
и если исследуемый тип - шаблонный,
тогда оно не спасет от ошибок компиляции связанных с попыткой инстанцировать шаблон,
который зависит от определений возможных T.

хотите знать больше?

KKH
> спустя 8 лет, сам сижу ищу "операцию проверки существования типа" 😂. Адаптирую свои 20 летние библиотеки на gcc ubuntu. Почитал, понастальгировал.
Иногда тоже гуглю какой-то вопрос, попадаю на Stack Overflow. Читаю вопрос, думаю, как хорошо описали мою ситуацию, я бы точно так же спросил. Потом смотрю ник, а это и есть мой вопрос, заданный несколько лет назад)

Судя по тому, что я через месяц после создания этой темы, выложил Intra на GitHub, у меня тогда получилось имитировать концепты. Но сейчас их имитировать не нужно, они уже есть, и вовсю используются в dev-next ветке, которую всё не хватает времени довести до рабочего состояния.
Я через несколько лет после этой темы задавался вопросом, как проверить, есть ли идентификатор в глобальной области видимости. Но там запрос был другой - совместимость кода с разными заголовочными файлами. Я так понимаю, у тебя эта проблема сейчас. А вот это уже сделать не получилось, по крайней мере, чтобы работало с GCC/Clang. Вроде только с функциями что-то нашаманить получалось, возможно, вместе с ADL.

gammaker
>Но там запрос был другой - совместимость кода с разными заголовочными файлами. Я так понимаю, у тебя эта проблема сейчас.
Ты очень проницателен. В точку. Хорошо, что C++17 везде работает. Сняло часть проблем.