Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, jazzer, Вы писали:

К>>>Не, секундочку. В каких случаях шаблон ищет объявления зависимостей в точке определения, а в каких случаях — в точке первого воплощения? Что-то я дезориентирован.
J>>Зависимые имена всегда ищутся в точке воплощения.
J>>

J>>Such (dependent — jazzer) names are unbound and are looked up at the point of the template instantiation (14.6.4.1) in both the
J>>context of the template definition and the context of the point of instantiation.

EP>Насколько я понял, эта цитата относится к тому когда делается lookup, а не где он ищет имена.

Ну да, ну так и вопрос-то был именно о "когда" (т.е. до точки использования или после, где введено еще одно определение foo). "Где" (т.е. в каком пространстве имен) о идет, не поменялось — мы ввели foo в том же самом глобальном пространстве. И как оказалось, вопрос теперь официально решается перемещением точки воплощения в конец файла.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Ну да, ну так и вопрос-то был именно о "когда" (т.е. до точки использования или после, где введено еще одно определение foo). "Где" (т.е. в каком пространстве имен) о идет, не поменялось — мы ввели foo в том же самом глобальном пространстве. И как оказалось, вопрос теперь официально решается перемещением точки воплощения в конец файла.

Я о том, что при осуществлении поиска в точке воплощения (пусть даже если она в конце файла) для одних типов поиск будет производится и в instantiation context (то есть во всём что находится перед этой точкой воплощения), а для других — только в том, что видно в точке определения шаблона. Хотя "когда" — для этих типов будет одинаковым — в точке воплощения.
пример.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Я о том, что при осуществлении поиска в точке воплощения (пусть даже если она в конце файла) для одних типов поиск будет производится и в instantiation context (то есть во всём что находится перед этой точкой воплощения), а для других — только в том, что видно в точке определения шаблона.

А, ты про это. Я вот все думаю, не правильнее было бы считать глобальное пространство имен ассоциированным со встроенными типами? Потому что сейчас довольно неприятная асимметрия получается.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>А, ты про это. Я вот все думаю, не правильнее было бы считать глобальное пространство имен ассоциированным со встроенными типами?

Я вот тоже об этом думаю. Или хотя бы ввести хоть какой-то namespace, с которым они ассоциированы, например что-то типа std::builtin_types — по идее старый код не сломается?

J>Потому что сейчас довольно неприятная асимметрия получается.

На что я и наткнулся:

// ...
class NullTerminated
{
     const char *position;
public:
     explicit NullTerminated(const char *position)
         : position{position}
     {}
     NullTerminated &operator++()
     {
         ++position;
         return *this;
     }
     const char &operator*() const
     {
         return *position;
     }
     friend bool empty(const NullTerminated &x)
     {
         return *x == 0;
     }
};

int main()
{
     for(auto x : make_range(NullTerminated{"Sentinel iteration"}))
         cout << x;
     cout << "!" << endl;
}

Если бы у char* было бы хоть какое-нибудь ассоциированное пространство имён, то можно было бы сделать так:

// ...
namespace std { namespace builtin_types
{
    bool empty(const char * const x)
    {
        return *x == 0;
    }
}}
int main()
{
     const char *str = "Sentinel iteration";
     for(auto x : make_range(str))
         cout << x;
     cout << "!" << endl;
}

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, jazzer, Вы писали:

J>>Так что, начиная с С++11, теперь официально точка инстанцирования может считаться расположенной в конце файла

К>Вот и накрылись медным тазом ремарковские compile-time счётчики инстанцирования...

А ты им дефект засабачь: "Freedom to count template instantiations at compile-time."

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>// ...
EP>namespace std { namespace builtin_types
EP>{
EP>    bool empty(const char * const x)
EP>    {
EP>        return *x == 0;
EP>    }
EP>}}
EP>int main()
EP>{
EP>     const char *str = "Sentinel iteration";
EP>     for(auto x : make_range(str))
EP>         cout << x;
EP>     cout << "!" << endl;
EP>}

это было бы правильно. но тогда каждый желающий считал бы своим долгом обогатить пространство имен std обогатить своей функцией.

Здравствуйте, jazzer, Вы писали:

J>Тут в процессе очередной дискуссии "С++ против всех" родился пример реализации полиморфной (т.е. шаблонной) лямбды в духе Boost.Lambda в три строчки на С++11.
J>Решил, что тут тоже многим будет интересно:

В общем обсуждали мы с товарищем sehe вопрос "to blog or not to blog", и я упомянул данный топик в качестве примера.
Он сделал вот такой твит. Just for reference — оставляю это здесь.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, jazzer, Вы писали:

J>>Тут в процессе очередной дискуссии "С++ против всех" родился пример реализации полиморфной (т.е. шаблонной) лямбды в духе Boost.Lambda в три строчки на С++11.
J>>Решил, что тут тоже многим будет интересно:

EP>В общем обсуждали мы с товарищем sehe вопрос "to blog or not to blog", и я упомянул данный топик в качестве примера.
EP>Он сделал вот такой твит. Just for reference — оставляю это здесь.

Спасибо! А кто такой sehe? А то профиль не сильно говорящий...

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Спасибо! А кто такой sehe? А то профиль не сильно говорящий...

Кроме профиля почти ничего не знаю. (по профилю: дал ~1.5k ответов по C++, в том числе ~250 по Boost.Spirit)