А у меня полностью реализованный велосипед для гуя над реактивной моделью и там лямбда это самая частая конструкция ;)

Хорошо, что мне не нужно читать этот код

Хорошо, что мне не нужно читать этот код

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

Типичные проблемы для функционального стиля программирования, как я понимаю

В общем из языков, которые не имеют императивов времени жизни

Я бы не обзывал только автоматические объекты объектами, которые имеют императивы времени жизни. Для примера, вот тот самый COM, у которого при правильной расстановке переменных, они ведут себя как автоматические объекты: https://github.com/slavanap/ssifSource/blob/master/ssifSource/Filter.ssifSource.cpp#L153

Я бы не обзывал только автоматические объекты объектами, которые имеют императивы времени жизни. Для примера, вот тот самый COM, у которого при правильной расстановке переменных, они ведут себя как автоматические объекты: https://github.com/slavanap/ssifSource/blob/master/ssifSource/Filter.ssifSource.cpp#L153

Императив времени жизни кроется в параметре для a_ref - по сути QueryInterface требует параметра-функтора, вызов которого соответствует требованию отпустить объект

Императив времени жизни кроется в параметре для a_ref - по сути QueryInterface требует параметра-функтора, вызов которого соответствует требованию отпустить объект

Да, в вашем примере максималное количество ссылок на объект = 1

Да, в вашем примере максималное количество ссылок на объект = 1

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

Почему не допускается? UB на то и UB, что может приводить к чему угодно

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

Да, в вашем примере максималное количество ссылок на объект = 1

По сути вы получаете одну ссылку и потом делаете ваш любимый shared_ptr

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

Это строгие гарантии времени смерти, которые безумно важны для непроверяемых ссылок

Заметьте, что я там [this] замыкаю без всяких проверок, потому что у меня есть такие гарантии

В итоге через весь гуй во всех callback-ах этот this замыкается через макрос только ради дебажной проверки что все соблюдают правила

Хорошо, что мне не нужно читать этот код

Да, вот еще одно очень интересное замечание. Ваш пример содержал прошивку shared_ptr<B> в определение А. Классом А (ресурс!) мог быть, например, файл, сетевое соединение или контроллер передачи сообщений, который вообще не слышал про класс В. В этом случае разница между нашими примерами неожиданно обнулится, если заметить, что ref_with_guard это более слабая версия вашего pair<A, shared_ptr<B>>, потому что ref_with_guard ничего не мешает быть именно такой парой (тройкой, в неё же надо положить параметр запроса), если В управляется счетчиком ссылок.

Да, вот еще одно очень интересное замечание. Ваш пример содержал прошивку shared_ptr<B> в определение А. Классом А (ресурс!) мог быть, например, файл, сетевое соединение или контроллер передачи сообщений, который вообще не слышал про класс В. В этом случае разница между нашими примерами неожиданно обнулится, если заметить, что ref_with_guard это более слабая версия вашего pair<A, shared_ptr<B>>, потому что ref_with_guard ничего не мешает быть именно такой парой (тройкой, в неё же надо положить параметр запроса), если В управляется счетчиком ссылок.

Замечу, что с файлом и сетевым соединением я обычно веду работу через методы обрамляющего класса B, а не напрямую обращаясь к A

Замечу, что с файлом и сетевым соединением я обычно веду работу через методы обрамляющего класса B, а не напрямую обращаясь к A

Это эквивалентно UserThatAlwaysHasB, класс BUser из примера это класс, в который ресурс инжектается, но которому он не обязателен

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

Замечу, что с файлом и сетевым соединением я обычно веду работу через методы обрамляющего класса B, а не напрямую обращаясь к A

must_have_b_user_view (по какой бы причине он не оказался вне В) получит просто прямую ссылку в конструктор, потому что в системе с императивами времени жизни очень легко обеспечивать предписания "давайте-ка я не переживу внешний объект"

Насколько я понял, вы выше пытались получить ссылку на nullpt? Насколько я знаю, шланг в какой-то версии в районе 3.9 переставал это собирать, не знаю, как сейчас.

Это про переносимость.

нет, не допускается

ПОДОЖДИ ЧТО

std::array<int, 0>{}.front() это переносимый аналог __builtin_unreachable? :)

как можно надеяться на UB?

std::array<int, 0>{}.front() это переносимый аналог __builtin_unreachable? :)

тогда уж сразу *(int*)nullptr = 0;

тогда уж сразу *(int*)nullptr = 0;

это дает варнинги

как можно надеяться на UB?

так вызов __builtin_unreachable это как раз UB

так вызов __builtin_unreachable это как раз UB

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

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

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

это же constexpr проверяемая ошибка

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

я думаю, что оно может не скомпилироваться

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

И результат вызова будет UB :)

а я вот не согласен

но я тоже Александр

Ну я смутно надеюсь, что оно обязано не скомпилироваться

И дефект репорт в противном случае

я и не говорю, что обязано не скомпилироваться, а как раз наоборот - оно никому ничем не обязано, это же UB!

я и не говорю, что обязано не скомпилироваться, а как раз наоборот - оно никому ничем не обязано, это же UB!

подожди, UB в constexpr не бывает

а, мы говорим про constexpr версию

нет, просто компилируемость это constexpr проверяемо

Тут надо в стандарте смотреть требуется ли чтоб UB было well formed

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

т.е. до линковки это максимум implementation defined (скажем константы платформы проверяем)

т.е. невозможно, что "проверка наличия front() у array<int, 0> это UB"

либо есть, либо нет, либо implementation defined :)

я запутался

ну смотри, метод класса в стандартной либе либо есть, либо нет, либо implementation defined

ответ на этот вопрос никогда не behavior of this check is undefined

так что std::array<int, 0>{}.front() либо компилируется, либо нет, либо компилируемость implementation defined

это логично

и если что-то кроме "не компилируется", у меня в очередной раз подгорит)

это логично

ну... вот слинкуется или нет уже бывает behavior is undefined :)

всем привет, кто-то работал с Media Foundation?

или с API DirectX/Direct3D

тогда уж сразу *(int*)nullptr = 0;

Стреляйте в ногу поездами аэрофлота

Стреляйте в ногу поездами аэрофлота

между прочим, это ровно то, во что превращается std::array<int, 0>{}.front() в реализациях libstdc++/libc++

must_have_b_user_view (по какой бы причине он не оказался вне В) получит просто прямую ссылку в конструктор, потому что в системе с императивами времени жизни очень легко обеспечивать предписания "давайте-ка я не переживу внешний объект"

Alright

Alright

Да, я еще немного подумал про нашу дискуссию и мне стало интересно, насколько возможна формальная преобразования вашего стиля кода в мой (зачеркнуто, наоборот, моего в ваш) Я возьму некоторый таймаут :)

между прочим, это ровно то, во что превращается std::array<int, 0>{}.front() в реализациях libstdc++/libc++

А если этот метод вообще убрать из специализации для 0 ?

А если этот метод вообще убрать из специализации для 0 ?

не ко мне вопрос :)

А если этот метод вообще убрать из специализации для 0 ?

Я не знаю, почему это не сделано, если это не сделано

ну смотри, метод класса в стандартной либе либо есть, либо нет, либо implementation defined

Вроде бы всё-таки интерфейс std::array не зависит от N - все члены должны присутствовать: http://eel.is/c++draft/sequences#array.zero Здесь указано, что должно работать при N == 0 и "эффект вызова front() или back() для array нулевого размера - undefined". Эффект вызова - это значит, что, если во время выполнения вызовутся front/back - может быть всё, что угодно. Но код, содержащий потенциальные вызовы этих функций должен компилироваться (и линковаться, и запускаться).

Вроде бы всё-таки интерфейс std::array не зависит от N - все члены должны присутствовать: http://eel.is/c++draft/sequences#array.zero Здесь указано, что должно работать при N == 0 и "эффект вызова front() или back() для array нулевого размера - undefined". Эффект вызова - это значит, что, если во время выполнения вызовутся front/back - может быть всё, что угодно. Но код, содержащий потенциальные вызовы этих функций должен компилироваться (и линковаться, и запускаться).

Ну что сказать... bunch of trolls

Зато теперь есть переносимый __builtin_unreachable!

Хотя он и раньше был, int f() {}, но теперь с объектами

а чё если reference front() { return reinterpret_cast<reference>(*this); }

это у меня мысли, чё запихать то внутрь этой функции

а чё если reference front() { return reinterpret_cast<reference>(*this); }

Можно объявлять конкурс на лучшее прикрытие костыля в стандарте

а чё если reference front() { return reinterpret_cast<reference>(*this); }

а ты там реализацию для MSC пишешь? :)

а ты там реализацию для MSC пишешь? :)

Ну вообще хочу переносимую, но тестирую под MSVC, да А как угадал?)

а чё если reference front() { return reinterpret_cast<reference>(*this); }

bit_cast ещё можно :)

bit_cast ещё можно :)

Мне под C++03 имлементацию надо

Кстати, а если объявить функцию, как noreturn ?

видимо, begin и end надо реализовать как this data() надо реализовать как return nullptr front() и back() надо реализовать как return *data()

Мне под C++03 имлементацию надо

Можно статическую переменную указанного типа объявить в шаблоне в c++03?

хотя можно front() и back() действительно [[noreturn]] и бросать исключение

или там требование noexcept для front()/back()?

А если этот метод вообще убрать из специализации для 0 ?

На всякий случай, приведу пример почему это нельзя убирать и почему это совсем не глупость: https://godbolt.org/z/NR_TRP

видимо, begin и end надо реализовать как this data() надо реализовать как return nullptr front() и back() надо реализовать как return *data()

а вдруг компилятор умный и он догадается что там nullptr разыменовывают и кинет ошибку компиляции

На всякий случай, приведу пример почему это нельзя убирать и почему это совсем не глупость: https://godbolt.org/z/NR_TRP

Это проблема индейца, если size(container) известен в constexpr

Это проблема индейца, если size(container) известен в constexpr

+1

Это проблема индейца, если size(container) известен в constexpr

Это пример программы не содержащей UB, которая должна компилироваться, запускаться и работать в правильной реализации языка.

Это пример программы не содержащей UB, которая должна компилироваться, запускаться и работать в правильной реализации языка.

*в реализации языка согласно стандарту

*в реализации языка согласно стандарту

Разумеется

Кстати, а *nullptr обязано компилиться?)

Раз уж такая пляска

Это пример программы не содержащей UB, которая должна компилироваться, запускаться и работать в правильной реализации языка.

Да, но это не значит, что версия языка правильна

Кстати, а *nullptr обязано компилиться?)

Нет.

Нет.

Оке, пасиб

Кстати, а *nullptr обязано компилиться?)

у nullptr_t нет этого оператора. Так что нет.

Это пример программы не содержащей UB, которая должна компилироваться, запускаться и работать в правильной реализации языка.

https://godbolt.org/z/oaNI_w

ПОЦАНЫ КТО ЗНАЕТ БЕЙСИК????

без шуток где чат по бейсику?

Нашёл, где спрашивать.

ПОЦАНЫ КТО ЗНАЕТ БЕЙСИК????

/warn оффтоп

Firstname has been warned (1/3)

Это пример программы не содержащей UB, которая должна компилироваться, запускаться и работать в правильной реализации языка.

https://godbolt.org/z/CElRUU вот чуть более полная версия