Потому что мы нигде std::enable_if_t<false> инстанциировать (или как это по русски) не пытаемся.

Каким образом тогда AnotherTest<Test2> выдает No, если он не получает false из is_detected, после чего проваливает enable_if_t и void_t?

Вообще, цитата с cppreference An alias template is a template which, when specialized, is equivalent to the result of substituting the template arguments of the alias template for the template parameters in the type-id

Каким образом тогда AnotherTest<Test2> выдает No, если он не получает false из is_detected, после чего проваливает enable_if_t и void_t?

Ну правильно, проваливает же. Или я может вопрос не понимаю...

Ну вы утверждаете, что using-декларация для enable_if_t не эквивалентна прямой подстановке enable_if_t

Хотя в правилах SFINAE и нет явной оговорки о том, что произойдет при провале using-декларации, но An alias template is a template which, when specialized, is equivalent to the result of substituting the template arguments of the alias template for the template parameters in the type-id

Кажется, из этого прямо следует, что нет разницы, написано _t в using или вне его

Ну правильно, проваливает же. Или я может вопрос не понимаю...

Собственно, проваливает и игнорирует специализацию по SFINAE

Кажется, из этого прямо следует, что нет разницы, написано _t в using или вне его

Да, мне мое утверждение тоже больше не нравится. Но тогда неясно, почему пример тот не работает.

Да, мне мое утверждение тоже больше не нравится. Но тогда неясно, почему пример тот не работает.

Мне кажется, что это либо (а) бага вижака коих дофига в таких примерах (б) проблема из-за неиспользуемых шаблонных параметров

Если писать через is_detected, то такие проблемы возникают категорически редко

Мне кажется, что это либо (а) бага вижака коих дофига в таких примерах (б) проблема из-за неиспользуемых шаблонных параметров

Чем больше я об этом думаю, тем сильнее склоняюсь к (а)...

У кого-нить есть права bug зарепортить?

У кого-нить есть права bug зарепортить?

@antoshkka

У кого-нить есть права bug зарепортить?

У меня, но я хочу чтобы они не это фиксили, а написали [a, b] = быстрее

их человеческие ресурсы вряд ли бесконечные

у меня все работает в проекте, разве что Intellisense фейлит примеров пять

я лучше зарепорчу в комитет, что надо в overloaded function address operator resolution добавить ADL

вот как жить без этого?

https://godbolt.org/g/mPdTvW

тебе изи, а у меня 100 строк копипасты из-за трейтов на каждый неймспейс

https://godbolt.org/g/mPdTvW

@antoshkka

вот это вообще нормально, да? template <typename T> constexpr std::enable_if_t< !sfinae::has_nonmember_equal_to_1_<T>::value && !sfinae::has_nonmember_equal_to_1_std<T>::value && !sfinae::has_nonmember_equal_to_1_utils<T>::value && !sfinae::has_nonmember_equal_to_1_atl<T>::value && sfinae::has_member_equal_to<T>::value, typename traits::member_equal_to<T>::result_type > invoke_equal_to(T const& x, T const& y) { static_assert(!traits::has_possible_bad_member_equal_to<T>(), "Please make an implicit declarion of the member == operator"); return x.operator == (y); }

ну то есть у тебя ни один стандартный метод не вызывает ==

или никто никогда не забывал перекрывать == в потомке?

ну тогда либо ты пишешь на чистом С, либо у вас запрещено наследование или операторы конвенцией 😆

А почему тогда ты уверен, что никто не забыл? :)

Тут же очень легко - например, человек (а) наследует класс Y : Х у которого X::operator == ради type alias, человек (б) потом дописывает классу Y поле, до свидания

человек напишет правильный тест на ==, если знает, что он нужен; при code review аналогично - нужно читать описание предка уже имеющегося класса; в статический анализ я слабо верю, хотя это весьма идейная проверка (проверить все операторы)

вообще operator ==, имхо, одно из самых проблемных мест в С++, поскольку завязано на некоторую логическую концепцию типа неполиморфной ссылки, которая в языке отсутствует

вообще operator ==, имхо, одно из самых проблемных мест в С++, поскольку завязано на некоторую логическую концепцию типа неполиморфной ссылки, которая в языке отсутствует

Да, с оперпатором == чот ниоч, да

https://godbolt.org/g/mPdTvW

А что-нить такое не поможет? https://godbolt.org/g/tvHY9t

А что-нить такое не поможет? https://godbolt.org/g/tvHY9t

Мне нужно проверить, что не происходит конструкция вида struct A { bool operator == (A const& other) const { return true; }}; struct B : A { int x; }; bool f() { B b1 = {1}, b2 = {2}; return b1 == b2; }

Мне нужно проверить, что не происходит конструкция вида struct A { bool operator == (A const& other) const { return true; }}; struct B : A { int x; }; bool f() { B b1 = {1}, b2 = {2}; return b1 == b2; }

А как ADL поможет?

А как ADL поможет?

https://godbolt.org/g/mPdTvW

https://godbolt.org/g/mPdTvW

А как это проблему с A и B решает? чего-то мне неочевидно

А как это проблему с A и B решает? чего-то мне неочевидно

Взятие адреса функции это ТОЧНОЕ соответствие сигнатуры

Взятие адреса функции это ТОЧНОЕ соответствие сигнатуры

Аа... хитро! Понял, спасибо

@antoshkka

Это нормально :)

Это нормально :)

Ну то есть вам не кажется, что нужно все-таки делать ADL в такой конструкции? И не видели ли вы предложения по функциональности типа decltype, позволяющей получать адрес последней вычисляемой функции выражения?

Ну то есть вам не кажется, что нужно все-таки делать ADL в такой конструкции? И не видели ли вы предложения по функциональности типа decltype, позволяющей получать адрес последней вычисляемой функции выражения?

На первое я пару месяцев назад отвечал в этом чате, что оно не так просто как кажется: если делать ADL то это сломает текущий пользовательский код, где нужен operator== именно из текущего scope. Так что сделать тут ничего уже нельзя.

Ну то есть вам не кажется, что нужно все-таки делать ADL в такой конструкции? И не видели ли вы предложения по функциональности типа decltype, позволяющей получать адрес последней вычисляемой функции выражения?

По поводу второго - а можно пример использования?

По поводу второго - а можно пример использования?

Проверка вызываемой функции на этапе компиляции. Я могу проверить, может ли быть вызван operator ==, но совершенно никак не могу выяснить, что же за функция будет вызвана, в частности, будет ли при вызове выполнен какой-либо implicit cast

По поводу второго - а можно пример использования?

Моя задача диагностировать следующую ошибку (аналогичная при внешнем операторе) при вызове == в обобщенном коде struct A { bool operator == (A const& other) const { return true; }}; struct B : A { int x; }; bool f() { B b1 = {1}, b2 = {2}; return b1 == b2; }

По поводу второго - а можно пример использования?

При этом, overloaded function address resolution позволяет мне вызвать только как надо, но не выполняет ADL, мне приходится писать полностью отдельный trait для каждого namespace, в котором может быть operator ==

Может тогда лучше детектить публичное наследование?

Может тогда лучше детектить публичное наследование?

Боюсь, много что запретим, например, std::set уж не публично ли наследуется?

Можно было бы проверять final-класс, но опять же, std::vector не помечен как final

Давайте я в очередной раз попробую подумать пару дней, и найти решение

Моя задача диагностировать следующую ошибку (аналогичная при внешнем операторе) при вызове == в обобщенном коде struct A { bool operator == (A const& other) const { return true; }}; struct B : A { int x; }; bool f() { B b1 = {1}, b2 = {2}; return b1 == b2; }

варнинга достаточно, не?

Давайте я в очередной раз попробую подумать пару дней, и найти решение

Я не тороплюсь, я накопипастил там уже кода вида, хорошо хоть буста нет. template <typename T> constexpr std::enable_if_t< !sfinae::has_nonmember_equal_to_1_<T>::value && !sfinae::has_nonmember_equal_to_1_std<T>::value && !sfinae::has_nonmember_equal_to_1_utils<T>::value && !sfinae::has_nonmember_equal_to_1_atl<T>::value && sfinae::has_member_equal_to<T>::value, typename traits::member_equal_to<T>::result_type > invoke_equal_to(T const& x, T const& y) { static_assert(!traits::has_possible_bad_member_equal_to<T>(), "Please make an implicit declarion of the member == operator"); return x.operator == (y); }

варнинга достаточно, не?

А как сделать warning?

А как сделать warning?

svn co http://llvm.org/svn/llvm-project/cfe/trunk clang

svn co http://llvm.org/svn/llvm-project/cfe/trunk clang

Кроме шуток. +1 за идею варнинга на подобное

Давайте я в очередной раз попробую подумать пару дней, и найти решение

Да, наверное стоит написать еще один "всплывший момент", полагаю, это должно быть менее холиварным. У std-контейнеров нет sfinae-friendly проверок при объявлении operator ==, operator < и так далее

Кроме шуток. +1 за идею варнинга на подобное

я абсолютно серьезно. надо хотя бы баг открыть

Class B overloads A and has additional members, but doesn't overloads operator==

к сожалению, operator в том же std будет объявлен внешним

к сожалению, operator в том же std будет объявлен внешним

//ох уж этот ужасный стандартный русский язык, в котором общепринято операция для operator и оператор для statement

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

которая гарантирует, что указанный тип - в точности тот, который назван

кажется что в ближайшее время только метаклассы это починят

кажется что в ближайшее время только метаклассы это починят

Антон, а скажите, насколько по ощущениям сырые новые модули и ждать ли их к 20 стандарту на самом деле?

(я про модули компиляции, разумеется)

Антон, а скажите, насколько по ощущениям сырые новые модули и ждать ли их к 20 стандарту на самом деле?

Антон, скажите, будут ли наши внуки жить при комму^W^W^W пользоваться модулями?

Мне они не кажутся сырыми, мне они кажутся сложно применимыми в текущем виде И тем не менее, в текущем виде они самые эффективные.

Если примут в текущем виде, скорее всего Boost и Стандартная библиотеки на них перейдут, пара крупных компаний для своих внутренних наработок... А остальные будут подтягиваться в течение лет 15

У меня достаточно много кода под генератором, я не знаю ограничений, но по сути у меня ~300 TU которые исключительно потребляют шаблонный код и за счет генератора могут быть перегнаны с опреденной легкостью

Если примут в текущем виде, скорее всего Boost и Стандартная библиотеки на них перейдут, пара крупных компаний для своих внутренних наработок... А остальные будут подтягиваться в течение лет 15

крупный опенсорс должен переползти, не?

ну тут детали нужны, в чем возникают проблемы при портировании и почему нельзя раз в минуту перегонять один TU

Основная проблема - макросы. Модули их не экспоритруют. А значит не работают include guards и проблемы с import std.iostream include <iostream>

Не очень легко переходить, потребует больших телодвижений

Основная проблема - макросы. Модули их не экспоритруют. А значит не работают include guards и проблемы с import std.iostream include <iostream>

ну это понятно было давно

Основная проблема - макросы. Модули их не экспоритруют. А значит не работают include guards и проблемы с import std.iostream include <iostream>

но... в ms visual studio никто уже лет 20 не пользуется include guard-ами

собственно в этом и был спор между шлангом и майками, не?

include guards автоматически можно прагмой заменить

а я не знаю, почему в стандарт не приняли #pragma once

pragma once не спасёт, она по идее тоже не экспортируется модулями

а это не может быть просто реализовано без проблем?

а, не может

pragma once не спасёт, она по идее тоже не экспортируется модулями

а этого я не знал