Вы за то, чтобы 1. вместо f(x, y) можно было бы вызывать x.f(y), или 2. вместо x.f(y) можно было бы вызывать f(x, y), или 3. и то, и другое?

я за (2)

я за (2)

но зачем?

шобы нинаследоваться

шобы нинаследоваться

поясните, пожалуйста

Вместо наследования для расширения функциональности просто определяем метод, и вот мы расширили класс

Вместо наследования для расширения функциональности просто определяем метод, и вот мы расширили класс

это use case 1) определяем свободную функцию, но вызываем ее как member

поясните, пожалуйста

Чтобы обобщенное функциональное программирование можно было поддерживать.

Чтобы обобщенное функциональное программирование можно было поддерживать.

std::invoke решает эту проблему

Чтобы обобщенное функциональное программирование можно было поддерживать.

Без этого нельзя делать apply на методы

std::invoke решает эту проблему

Может быть

про 2) типичный пример с итераторами : x.begin vs begin(x)

Без этого нельзя делать apply на методы

struct X { void f(int); }; void test(X x, int y) { std::apply(&X::f, std::tuple(std::ref(x), y)); }

за счет того, что std::apply вызывает внутри себя std::invoke все прекрасно работает

std::invoke решает эту проблему

Но идея проползла Страустрап была и в том, что member functions и free functions выходят на один уровень друг с другом, с только той разницей, что у member первый параметр обязательный и this.

Но идея проползла Страустрап была и в том, что member functions и free functions выходят на один уровень друг с другом, с только той разницей, что у member первый параметр обязательный и this.

как и в шарпах кстати

Но идея проползла Страустрап была и в том, что member functions и free functions выходят на один уровень друг с другом, с только той разницей, что у member первый параметр обязательный и this.

Я знаю, только не понимаю, какую практическую проблему это решает. А недостатков вижу множество.

Но идея проползла Страустрап была и в том, что member functions и free functions выходят на один уровень друг с другом, с только той разницей, что у member первый параметр обязательный и this.

Отсюда далее идёт прыжок в множественную диспетчеризацию методов, по нескольким типам

Я знаю, только не понимаю, какую практическую проблему это решает. А недостатков вижу множество.

Как в CLOSS же...

про 2) типичный пример с итераторами : x.begin vs begin(x)

Кстати, да

Хороший вопрос нужны ли extension методы для встроенных типов..

про 2) типичный пример с итераторами : x.begin vs begin(x)

тоже решенная проблема — всегда вызывать свободную функцию

5.times([]{ cout « "hello\n"; })

Ребят, оффтоп Кто-то знает как посмотреть размер стека? Может есть какая-то функция для этого?

В вижуалке

можно сразу добавить синтаксический сахар как в kotlin , чтобы если последний параметр std::function, то можно сразу писать тело лямды 5.times { cout << "hi"; }

5.times([]{ cout « "hello\n"; })

руби какой то :D

руби какой то :D

ну а почему нет, что плохого?

можно сразу добавить синтаксический сахар как в kotlin , чтобы если последний параметр std::function, то можно сразу писать тело лямды 5.times { cout << "hi"; }

Хотя макрухой это решается уже сейчас

5.times([]{ cout « "hello\n"; })

Пользуйтей уже сейчас: struct Invoker { const size_t count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } void test() { using std::cout; 5._times([]{ cout << "hello\n"; }); }

Пользуйтей уже сейчас: struct Invoker { const size_t count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } void test() { using std::cout; 5._times([]{ cout << "hello\n"; }); }

Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } что уже и такое можно?

круто, пойду попробую

что будет если в заголовке екзешника указана неправильная контрольная сумма?

он запустится?

Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } что уже и такое можно?

c C++11 можно

Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } что уже и такое можно?

пользовательский литерал из вещественного числа, появились в с++11

пользовательский литерал из вещественного числа, появились в с++11

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

Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } что уже и такое можно?

Да https://wandbox.org/permlink/EShciwiFQFBs47lQ

Только без рекламы, пожалуйста.

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

почему лучше? 5_times не читаемо же?

почему лучше? 5_times не читаемо же?

что читаемо, а что нет вопрос довольно субъективный, но мне бы не хотелось, чтобы 3.1415926e+10_times([]{ cout << "hello\n"; }) компилировлось

ну наверное

что читаемо, а что нет вопрос довольно субъективный, но мне бы не хотелось, чтобы 3.1415926e+10_times([]{ cout << "hello\n"; }) компилировлось

хыхы

что читаемо, а что нет вопрос довольно субъективный, но мне бы не хотелось, чтобы 3.1415926e+10_times([]{ cout << "hello\n"; }) компилировлось

если перед _times целое то выглядит неплохо

если перед _times целое то выглядит неплохо

https://wandbox.org/permlink/EShciwiFQFBs47lQ

Пользуйтей уже сейчас: struct Invoker { const size_t count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(long double x) { return { static_cast<size_t>(x) }; } void test() { using std::cout; 5._times([]{ cout << "hello\n"; }); }

Только это, цикл с size_t и using std::cout; //имхо в этом случае не надо так cout << ;

Вот кстати, 2_times.call([]{ cout << "1\n"; }); не выйдет, придётся таки завернуть в скобки.

https://wandbox.org/permlink/EShciwiFQFBs47lQ

Давай std::size_t для индексов, все-таки

Давай std::size_t для индексов, все-таки

Дак поставь. Это POC

Дак поставь. Это POC

POчто?

Коньцепт

Коньцепт

Слышь, а когда разрешили auto параметры функции?

Слышь, а когда разрешили auto параметры функции?

Не разрешали)

Я уже судорожно пошел перелопачивать cppref

Просто gcc кидает только ворнинг, а шланг ошибку.

только возвращаемое значение

Просто gcc кидает только ворнинг, а шланг ошибку.

Угу, это же имеет понятно какой смысл, просто почему-то синтаксис не сделали

ну в гцц концепты давненько

плюсач

можно ли замутить такую штуку: template <T, U> class A: public T { U GetVar() { T::GetVar(); } } class B { int GetVar(); } A<B, int> *a = new A<B, int>()

ну в гцц концепты давненько

кстати, концепты в шланге feature-complete

кстати, концепты в шланге feature-complete

в 7ке ?

в 7ке ?

в форке

https://github.com/saarraz/clang-concepts

можно ли замутить такую штуку: template <T, U> class A: public T { U GetVar() { T::GetVar(); } } class B { int GetVar(); } A<B, int> *a = new A<B, int>()

а что мешает? https://godbolt.org/g/syQGKi

Вот кстати, 2_times.call([]{ cout << "1\n"; }); не выйдет, придётся таки завернуть в скобки.

так не надо .call вызывать, так работает: #include <iostream> struct Invoker { const unsigned long long count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(unsigned long long x) { return { x }; } void test() { using std::cout; 2_times([]{ cout << "hello\n"; }); }

так не надо .call вызывать, так работает: #include <iostream> struct Invoker { const unsigned long long count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(unsigned long long x) { return { x }; } void test() { using std::cout; 2_times([]{ cout << "hello\n"; }); }

да, это более логичная версия с operator ()

так не надо .call вызывать, так работает: #include <iostream> struct Invoker { const unsigned long long count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(unsigned long long x) { return { x }; } void test() { using std::cout; 2_times([]{ cout << "hello\n"; }); }

О, ваще огонь, да!

так не надо .call вызывать, так работает: #include <iostream> struct Invoker { const unsigned long long count; template<typename F> void operator() (F f) { for (int i = 0; i != count; ++i) f(); } }; Invoker operator "" _times(unsigned long long x) { return { x }; } void test() { using std::cout; 2_times([]{ cout << "hello\n"; }); }

Андрей, зачем вы пишете через этот using? Вы понимаете, зачем вообще так пишут?

Андрей, зачем вы пишете через этот using? Вы понимаете, зачем вообще так пишут?

потому что topic starter хотел иметь возможность писать `5.times([]{ cout « "hello\n"; })`

за таким в скалку

потому что topic starter хотел иметь возможность писать `5.times([]{ cout « "hello\n"; })`

using name; операция с name это вообще-то очень специфическая конструкция языка

Отличная же.

Отличная же.

Отличная, но у неё специальное назначение

Ну уж прямо.

using name; операция с name это вообще-то очень специфическая конструкция языка

в данном случае я не вкладывал в нее сакрального смысла

Ну уж прямо.

Хм.. ну вот глубокое ИМХО это целенаправленное подключение ADL по name

Т.е. цель замена name lookup с qualified на unqualified

в данном случае я не вкладывал в нее сакрального смысла

такое встречается при вызове из шаблонов расширяемо-перегруженных функций, например //std::sort using std::swap; swap(a, b);

т.е. это указание, что за using идет extension point

такое встречается при вызове из шаблонов расширяемо-перегруженных функций, например //std::sort using std::swap; swap(a, b);

Я знаю, слава богу в С++20 благодаря http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html эта муть должна сгинуть.

Я знаю, слава богу в С++20 благодаря http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html эта муть должна сгинуть.

Я не хочу изучать предложение, но мне кажется, что там есть очень сильно скрытые ошибки В частности, емнип customization point можно закрыть функтором, которым сам будет perfect forward-ить параметры и скрывать using, но это обладает кучей минусов

Т.е. в действительности там почти что неустранимые проблемы

Я не хочу изучать предложение, но мне кажется, что там есть очень сильно скрытые ошибки В частности, емнип customization point можно закрыть функтором, которым сам будет perfect forward-ить параметры и скрывать using, но это обладает кучей минусов

да речь идет именно об этой идее

Т.е. в действительности там почти что неустранимые проблемы

какие именно?

да речь идет именно об этой идее

а там есть аргументация, что параметры всегда можно perfect forward-ить?

я как минимум вспомню две именованные сущности в C++, которые просто не имеют типа

это { bracket-init } и overloaded_function

и обе эти сущности не могут пройти через perfect forwarding

т.к. их интерепретация попросту зависит от целевого типа и он не может быть auto

какие именно?

скажем так, я немного размышлял и у меня получался, что без специального декларатора невозможно решить все проблемы customization point

где декларатор должен изменять правила name lookup для этого имени

и обе эти сущности не могут пройти через perfect forwarding

эти сущности и не могут быть переданы в такие customization points как std::{begin, swap, hash, ...}

эти сущности и не могут быть переданы в такие customization points как std::{begin, swap, hash, ...}

мне кажется, это неверно

мне кажется, это неверно

а пример приведете?