утро глупых вопросов, если сеттер создает новую сущность. например контейнер, потом уже ассайнит его в поле класса. nrvo и guaranted copy ellision все делают за меня ведь?

утро глупых вопросов, если сеттер создает новую сущность. например контейнер, потом уже ассайнит его в поле класса. nrvo и guaranted copy ellision все делают за меня ведь?

нет, где там NRVO

утро глупых вопросов, если сеттер создает новую сущность. например контейнер, потом уже ассайнит его в поле класса. nrvo и guaranted copy ellision все делают за меня ведь?

NRVO это когда ты говоришь auto c = Class(); return c;

нет, где там NRVO

вот return там нет, да,

собственно но видно что скоуп заканчивается

void set() { vector<int> a; a.push_back(1); this->vec = a; }

Всем привет

void set() { vector<int> a; a.push_back(1); this->vec = a; }

здесь не будет оптимизации

Спасибо за чат

void set() { vector<int> a; a.push_back(1); this->vec = a; }

this->vec = std::move(a); и норм же

здесь не будет оптимизации

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

void set() { vector<int> a; a.push_back(1); this->vec = a; }

думаю тут в итоге будет this->vec.emplace_back какой нибудь

щас код покажу,а

думаю тут в итоге будет this->vec.emplace_back какой нибудь

не думаю

с пуш беком естественно ничего не будет

думаю тут в итоге будет this->vec.emplace_back какой нибудь

как минимум нужен .clear() перед этим

this->vec = std::move(a); и норм же

вот вопрос был в том нужно кастить к rvalue или нет

компилятор догадается из за guaranteed copy elision. вроде кейс не сложный

вот вопрос был в том нужно кастить к rvalue или нет

nrvo - только при ретурнах, а guaranted copy ellision думаю тоже не должен сработать. Но ты ведь можешь к сету прикрутить или лямбду или другой метод

а в векторе только POD типы?

компилятор догадается из за guaranteed copy elision. вроде кейс не сложный

GCE вообще о другом

компилятор догадается из за guaranteed copy elision. вроде кейс не сложный

не догадается. guaranteed copy elision работает только для prvalue, а в примере с this->vec = a; будет lvalue

значит нужно кастить, спасибо.

#book Scott Meyers - Effective Modern C++ / Скотт Майерс - Эффективный и современный C++; Вильямс, 2016 г.

как минимум нужен .clear() перед этим

https://godbolt.org/g/SB9hqx выделение памяти происходит один раз, со сложными структурами думаю будет emplace_back в итоге

мной подразумевалась такая ситуация https://godbolt.org/g/cyhePY

мной подразумевалась такая ситуация https://godbolt.org/g/cyhePY

Шланг, кстати, всё в хлам заоптимизировал

мной подразумевалась такая ситуация https://godbolt.org/g/cyhePY

если заменить vec = std::move(a) на vec = a; на шланге и гсс ничего не поменяется

MSVC как всегда всё делает по стандарту

мной подразумевалась такая ситуация https://godbolt.org/g/cyhePY

ну да здесь шланг должен простым lifetime analysis-ом понять что это можно схлопнуть

ну да здесь шланг должен простым lifetime analysis-ом понять что это можно схлопнуть

Что он и сделол

пацаны всем привет А сколько будет стоить написать регистратор для одного сайта с проксями?

ellcc ваще оставил только main: # @main xorl %eax, %eax retq

шланг вообще увидел что мейн знает все в компайл тайме и...

или на чем лучше писать искать

или на чем лучше писать искать

Оффтоп

Оффтоп

для новичков есть чат?

для новичков есть чат?

@supapro

@supapro

ty

шланг вообще увидел что мейн знает все в компайл тайме и...

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

@supapro

это чат для новичков, да

https://godbolt.org/g/CXTYgY

если заменить vec = std::move(a) на vec = a; на шланге и гсс ничего не поменяется

Как это ничего не поменятеся? https://godbolt.org/g/TpPwZ9

все очень сильно поменяется д

Как это ничего не поменятеся? https://godbolt.org/g/TpPwZ9

странно. для гсс смотрел этот же код

ellcc ваще оставил только main: # @main xorl %eax, %eax retq

А он крутой!

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

Как это ничего не поменятеся? https://godbolt.org/g/TpPwZ9

тут прикол в списке инициализации. если изменить на push_back - разницы не будет

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

питера нортона почитай)

питера нортона почитай)

Хорошо спасибо

мне кажется, этот чат и @supapro сделали неплохой такой вклад в общение по С++. Раньше точно не так обильно обсуждали проблемы и решения

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

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

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

+

Это-то всё понятно. Меня интересует вообще обоснованность таких утверждений хоть какая-либо. Утверждается (в контексте, как нечто самоочевидное), что существуют какие-то вообще фантастические "оптимизации" (с изменением семантики). Как-то не верится.

Што.

Ладно. Буду писать "што".

тоже так показалось

Это-то всё понятно. Меня интересует вообще обоснованность таких утверждений хоть какая-либо. Утверждается (в контексте, как нечто самоочевидное), что существуют какие-то вообще фантастические "оптимизации" (с изменением семантики). Как-то не верится.

всякие оптимизации бывают

а посему мне кажется ничего плохого не будет, если слить чат с supapro

но чтобы push_back на emplace_back менялся такого я не видел

а посему мне кажется ничего плохого не будет, если слить чат с supapro

с ультрамегапро лучше

но чтобы push_back на emplace_back менялся такого я не видел

чой-та? внутри пушбэка он и стоит

чой-та? внутри пушбэка он и стоит

вообще всегда?

а внутри него что стоит? почему не до этого, стоящего внутри него заоптимизируется?

Это-то всё понятно. Меня интересует вообще обоснованность таких утверждений хоть какая-либо. Утверждается (в контексте, как нечто самоочевидное), что существуют какие-то вообще фантастические "оптимизации" (с изменением семантики). Как-то не верится.

Трудно сказать, да и не хочется говорить за всех. Подозреваю, что это связано с феноменом того, что человек увтдел работу оптимизатора, удивился, как он хитро догадался, что некие X и Y эквивалентны, и потом домысливает, чт компилятор может огадаться, что X1 эквивалентен Y1

а посему мне кажется ничего плохого не будет, если слить чат с supapro

Опять 25

я говорю, что push_back может заинлайниться на 1 лвл (до emplace_back)

Трудно сказать, да и не хочется говорить за всех. Подозреваю, что это связано с феноменом того, что человек увтдел работу оптимизатора, удивился, как он хитро догадался, что некие X и Y эквивалентны, и потом домысливает, чт компилятор может огадаться, что X1 эквивалентен Y1

в гранит

я говорю, что push_back может заинлайниться на 1 лвл (до emplace_back)

в libstdc++ или какой это? то есть в частном случае

я говорю, что push_back может заинлайниться на 1 лвл (до emplace_back)

push_back внутри емплейса вижу https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L679 наоборот не вижу https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L1588

Вот оно в стикере)

push_back внутри емплейса вижу https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L679 наоборот не вижу https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L1588

ну лааадно, мог перепутать

на самом деле от имплементации зависит

где-то вполне может быть наоборот :)

на самом деле от имплементации зависит

то и имел ввиду

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

1. Оптимизировать надо только места, где оптимизация нужна. 2. Любую оптимизацию надо тестировать. 2. Про emplace контейнеров - в текущем проекте (сервер мморпг на плюсах) при старте много информации грузится из базы по подобным схемам, зачастую в итоге получается emplace. при этом замена container a = b; на container a = std::move(b) на скорость никак не влияет. Порядок - 1кк элементов

а посему мне кажется ничего плохого не будет, если слить чат с supapro

Не-не-не. Пусть вопросы про printf, лабы и прочие новичковские живут там, мы так долго боролись за это