Этого не может быть хотя бы по причинам того, что к JIT-компилятору весьма высокие требования по скорости его собственной работы, что не позволяет в них делать тяжелые и сложные оптимизации, а простой компилятор никак в алгоритмах оптимизации не стеснен.
Это и так есть. Богатые классы могут способствовать выгодным для себя законодательным решениям путем лоббирования, коррупции и прочих механизмов, не доступных бедным классам.
Да, еще как возмутился. Но кроме того, вы слышали хоть об одном случае привлечения кого либо в США за какие-либо политические высказывания в интернете? А вот у нас здесь это суровая реальность
Как будто основная масса населения когда-то отличалась вкусом. Вы посмотрите, что сейчас собирает 99% у критиков и многомиллионные продажи(не только в играх, в кино, в музыке, в литературе) и окажется, что массовая популярность это скорее негативная характеристика произведения.
Почему же сейчас никто не болтается, не смотря на то, что на каждого богатого приходится сотня бедных, которые мечтали бы, что бы богатые с ними делились?
Поправка — тормозит разработку проприетарного софта компаний, которые хотят поднять денег на всём готовеньком, ничего не отдавая взамен авторам кода. Так туда им и дорога. Вам никто ничего не должен.
Требовать вы конечно можете что угодно, а тот, у кого вы требуете — так же может положить на ваши требования с прибором. К комментарию выше тоже относится.
Скорее всего это приведет не ко всеобщей автоматизации и коммунизму, а просто к сильному снижению оплаты труда. Пролетариату придется конкурировать с машинами, и единственное, что он сможет предложить бизнесу — стать дешевле машин.
> Доказываешь всем что сверхдержава, встающая с колен.
> Викимедия включает тебя в список благотворительной инициативы для беднейших стран вместе с Анголой
…
Стандарт об этом ничего не говорит и не должен, но компиляторы вольны оптимизировать это как считают нужным (std::string не "встроенный", но тем не менее для классов стандартной библиотеки компиляторы зачастую применяют особые оптимизации)
1.8. Во всех актуальных реализациях std::string есть small string optimization. Для маленьких, в том числе строк нулевого размера, аллокации в куче не будет.
1.10 Вредный совет.
vector при последовательном добавлении элементов всегда будет оптимальнее. Да, тогда когда он упирается в границы выделенной памяти, придется выделить новый блок, но все реализации выделяют память с запасом — в 1,5 / 2 раза больше от текущей. В результате, копирование и аллокация блока в куче — не такое уж частое явление, тогда как std::list делает аллокацию под каждый новый элемент. И это уж если не говорить о том, что у вектора самый быстрый последовательный и случайный доступ к элементам. В результате я бы сказал по другому — всегда используйте vector, если нет веских причин использовать list или deque.
2.6 — не правда. http://en.cppreference.com/w/cpp/language/copy_elision
И это не единственный пример дезинформации.
Вообще такое ощущение, что автор пишет о каких то древних компиляторах, не умеющих в оптимизацию. Они давно достаточно умны, что бы почти обо всех пунктах заботиться не приходилось.
Это бы происходило, если бы один бросок засчитывался и Алисе, и Бобу, а в данном случае они кидают монетки независимо, и если боб выкинет орла за решкой,, для Алисы это ничего не значит — она свои монетки кидает.
?
> Викимедия включает тебя в список благотворительной инициативы для беднейших стран вместе с Анголой
…
vector при последовательном добавлении элементов всегда будет оптимальнее. Да, тогда когда он упирается в границы выделенной памяти, придется выделить новый блок, но все реализации выделяют память с запасом — в 1,5 / 2 раза больше от текущей. В результате, копирование и аллокация блока в куче — не такое уж частое явление, тогда как std::list делает аллокацию под каждый новый элемент. И это уж если не говорить о том, что у вектора самый быстрый последовательный и случайный доступ к элементам. В результате я бы сказал по другому — всегда используйте vector, если нет веских причин использовать list или deque.
http://en.cppreference.com/w/cpp/language/copy_elision
И это не единственный пример дезинформации.
Вообще такое ощущение, что автор пишет о каких то древних компиляторах, не умеющих в оптимизацию. Они давно достаточно умны, что бы почти обо всех пунктах заботиться не приходилось.