https://godbolt.org/g/jRNHJX

sort у GCC часто ломает оптимизации. Скорее всего связано с https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82394 (плохо оптимизируют итераторы)

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

Должно уметь

Должно уметь

а это не запрещено разве? так как non-trivial ctro and dtor

по моим тестам оно не выкидывается

Должно уметь

https://godbolt.org/g/dVavLz

https://godbolt.org/g/dVavLz

а что, компилятор обязан синтезировать new и потом delete?

а что, компилятор обязан синтезировать new и потом delete?

ну типа vector имеет non-trivial ctor

с выделением памяти, поэтому и низя выкинуть

если ты сделаешь тоже самое со std::string

то он выкинется, ибо SSO

с выделением памяти, поэтому и низя выкинуть

я не понимаю, какой side-effect запрещает компилятору оптимизировать new/delete одного указателя

я не понимаю, какой side-effect запрещает компилятору оптимизировать new/delete одного указателя

мне тоже интересно

поэтому и кастую @antoshkka

я не понимаю, какой side-effect запрещает компилятору оптимизировать new/delete одного указателя

int side_effect = 0; struct foo { foo() { ++side_effect;} }; ... foo* f = new foo(); delete f;

с выделением памяти, поэтому и низя выкинуть

clang new выкидывает только в путь

clang new выкидывает только в путь

он выкидывает просто new

а не внутри вектора

int side_effect = 0; struct foo { foo() { ++side_effect;} }; ... foo* f = new foo(); delete f;

а какой side_effect в конструировании std::vector<int> ?

а какой side_effect в конструировании std::vector<int> ?

это может быть не только int, но и std::vector<foo>

это может быть не только int, но и std::vector<foo>

я говорю конкретно про int

про кастомные типы и так всё ясно

ну, то есть ты предлагает для фундаметельных типов использовать это

типы с trivial ctor

ну, предложими им

он выкидывает просто new

да, но вообще странно - если он вызов конструктора вектора ВЫКИНУЛ то можно и окружающий new выкинуть же

это бага

окей, вечером зарепорчу им. а пока у меня зачёт по политологии

а не внутри вектора

Оно упирается вот в эту багу: https://bugs.llvm.org/show_bug.cgi?id=34797

похоже на то да

Там разадресация проаллоцированного массива убивает оптимизацию

сейчас чуть более точный пример напишу

#include <memory> struct stored { int x = 42; stored() = default; stored(stored &&) = delete; stored(stored const&) = delete; }; struct inner { stored x; }; struct some { inner inner_; inner const&& get_inner() const&& { return std::move(inner_); } }; int f() { auto & ref = some().get_inner().x; //можно как-нибудь поломать эту строчку? return ref.x; }

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

я правильно понимаю, что что бы я не делал, мне все равно разрешат прострелить ногу из-за возможности приведения всего, что угодно, к const& ?

@zamazan4ik а как планируется пофиксить, что если [[pack]] меняет порядок элементов структуры, то экземпляры структуры с одинаковым объявлением перестают быть совместимы сами с собой? то есть каким вообще образом гарантировать, что эта структура одинаковая в разных TU?

@zamazan4ik а как планируется пофиксить, что если [[pack]] меняет порядок элементов структуры, то экземпляры структуры с одинаковым объявлением перестают быть совместимы сами с собой? то есть каким вообще образом гарантировать, что эта структура одинаковая в разных TU?

All. Bets. Are. Off! ©

@zamazan4ik а как планируется пофиксить, что если [[pack]] меняет порядок элементов структуры, то экземпляры структуры с одинаковым объявлением перестают быть совместимы сами с собой? то есть каким вообще образом гарантировать, что эта структура одинаковая в разных TU?

Если собраны одним компилятором с одинаковыми флагами, то они будут одинаковы

Ситуация ровно такая же будет, как и сейчас

Ситуация ровно такая же будет, как и сейчас

А в С++ нет концепции доступа по общему одинаковому префиксу?

А в С++ нет концепции доступа по общему одинаковому префиксу?

шта

http://en.cppreference.com/w/cpp/language/data_members#Standard_layout

нашел

@zamazan4ik вот с этой фигней что делать?

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

https://wandbox.org/permlink/AXNXryuWTpQakneK Кто-нибудь был в курсе, что можно делать так?

только не перегрузка ->* пожалуйтса

вроде это не разрешено стандартом, нет?)

жесть!

про стандарт не знаю

так скоро до окамля с хаскилем дойдет с их |:> и прочими закорючками

только не перегрузка ->* пожалуйтса

кек

о, кажись, телега багает если пытаться сделать сначала reply а потом forward в этот реплай)

О! Придумал отличную идею. Нужно ввести в С++ новый operator *|* который может быть применен на переменную текущего scope, работает как std::move и запрещает последующее использование этой переменной

кодовое название "оператор пнх" (это шютка)

О! Придумал отличную идею. Нужно ввести в С++ новый operator *|* который может быть применен на переменную текущего scope, работает как std::move и запрещает последующее использование этой переменной

Константин изобретает Раст

Константин изобретает Раст

Мне не нравится идея раста полного отказа от расширяемого динамического полиморфизма (как я понял)

Мне не нравится идея раста полного отказа от расширяемого динамического полиморфизма (как я понял)

ты видимо как-то не так понял

ты видимо как-то не так понял

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

трейтсы вполне себе динамический полиморфизм юзают, даже vtbl есть

То есть я обязан предоставить список всех потомков

трейтсы вполне себе динамический полиморфизм юзают, даже vtbl есть

тогда я не понимаю, как они избегают проблем, вызванных динамическим полиморфизмом

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

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

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

ну про неполиморфные ссылки это то, что принимает operator ==

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

Вот например. Представь, что у тебя есть статический полиморфизм следующего вида: класс Type с требованиями BaseA у которого есть публичное поле value с требованиями BaseB. Забавно, что такое вообще не переводится нормально в динамический полиморфизм, если BaseB содержит, скажем, MoveContructible.

Ты просто не можешь ну никак статически проверить, что это объект допустимого типа для поля value

Ну я ж говорил что надуманная проблема

Ну я ж говорил что надуманная проблема

Совершенно не надуманная. Это невозможность не-константой композиции

Динамический полиморфизм справляется, если не определен один тип. Если в выражении не определено два типа (читай operator ==) то динамический полиморфизм фейлит

лол

срочно несите в расточат

compile-time raytracer

а что ещё turing-complete, кроме сишного препроцессора и темплейтов?

а что ещё turing-complete, кроме сишного препроцессора и темплейтов?

сам язык

а, ок %)

а что ещё turing-complete, кроме сишного препроцессора и темплейтов?

constexpr к темплейтам вроде не относят

препроцессор же не полон по тьюрингу, не?

http://www.ioccc.org/2001/herrmann1.hint