Это не так. Конструктор перемещения теперь присутствует, в том или ином виде, почти в любом классе и везде теперь придется учитывать возможности нового стандарта. Иначе все эти усложнения просто бессмысленны.

Я смотрел. Он сохранился. Более того, это теперь почти единственная оптимизация для строк которая есть на практике, т.к. требования к строке в С++11 таковы, что теперь даже COW невозможен и все реализации библиотек переделываются чтобы учитывать новые требования.

Я не говорил что мне не нравится С++, и в силу специфики работы мне нужен С++. Я просто хочу сказать о том, что кроме расширения стандарта, нужно заботится о том, что бы люди могли его правильно использовать. А вот тут информации и книг не достаточно пока, на мой взгляд.

Я согласен. Но, если не важны такты, то и С++03 достаточно, и все эти микрооптимизации интересны только комитету и чего мы тогда тут страдаем :)

Да конечно… :). Например в std::string, обычно, есть оптимизация, где маленькие строки, до 16 байт, хранятся в статическом массиве в самом std::string. Как, по вашему, должен быть реализован конструктор перемещения в таком случае?

По сути, все о чем мы тут рассуждаем и есть сплошные микрооптимизации. Это все базовые кирпичики размазанные тонким слоем и никого HotSpot-а в 30% в базывых примитивах в адекватном коде на С++ вы не увидите. С точки зрения высокоуровнего программиста, можно писать хоть на javascript. Ему С++ не нужен.

Понимают, но оптимизация в прикладном коде, к сожалению, не возникнет сама собой и везде. Выходит для того, чтобы пользовательский класс стал «эффективным» в рамках STL, народу также нужно разбираться во всех тонкостях и особенностях реализации стандартной библиотеки, а это, учитывая размер разбухающего стандарта, уже слишком, на мой взгляд…

На мой взгляд, тут дело не в том, чтобы остановить поток лавы. Все эти разношерстные фичи толкаются разными разработчиками библиотек и они реально им нужны для макро и микро оптимизаций. Они также делают много обобщений и постоянно сталкиваются с дублированием кода и им нужно все это оптимизировать. У этих людей весь С++ загружен в «кеш». Т.е. они полностью погружены в потроха С++ и глядя на код видят результат компиляции. Я сам, когда долго пишу низкоуровневую библиотеку, перехожу в это состояние. Но когда начинаешь решать реальную бизнес задачу, «наверху», использую свои наработки, то все эти детали быстро улетучиваются. И что делать прикладным программистам в этом случае??? Тут нужно вырабатывать автоматизм, а с таким зоопарком это очень трудно сделать. Приведу пример:

Был сеттер:
void SomeClass::SetName(const std::string& first, const std::string& last);

Теперь, в новом стандарте, есть move сематика. Теперь в лоб, получается, что для того, чтобы работали идеи авторов стандарта нужно писать что-то типа того:
void SomeClass::SetName(const std::string& first, const std::string& last);
void SomeClass::SetName(std::string&& first, const std::string& last);
void SomeClass::SetName(const std::string& first, std::string&& last);
void SomeClass::SetName(std::string&& first, std::string&& last);

т.е., на лицо, логарифмический рост количества перегрузок функций.
Я понимаю, что нужно теперь писать вот так:
void SomeClass::SetName(std::string first, std::string last);

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

Какой кошмар!!! (Я в положительном смысле :). Интересно, а комитет изучал вопрос, сколько людей в состоянии изучить современный С++ с нуля, а не практикуя его постепенно в течении 20 лет?
Мне кажется, что пора уже заканчивать с этим и нужно садиться за написание книг, где подробно описывать как теперь все это использовать и самое главное, что не использовать из старых практик, пока они сами не забыли как правильно.

Очень интересно. А вы не пробовали использовать несколько предсказателей? Например, по одному для каждой из битовых плоскостей или разложить изображение по масштабам в пирамиду и использовать свой предсказатель на каждом уровне.

Есть у этой книги небольшой недостаток, её желательно читать всю. Там последующий главы ссылаются на предыдущие. Седжвик приводит 2-3-4 деревья, как частный случай B-деревьев, лишь для того, чтобы показать как они отображаются на RB-деревья (что это одно и то же). Далее он говорит, что данный тип деревьев (2-3-4) не эффективен в виде «наивной» реализации для структур в ОЗУ, но т.к. любое дерево можно представить в виде бинарного, есть метод, как сделать это эффективно, используя лишь один дополнительный бит на узел, это и есть RB-деревья. Работа с бинарными же деревьями у него разбирается очень подробно. Также, в главе про 2-3-4 деревья упоминается, что в последующих главах будет представлена более общая реализация B-деревьев. Там узел может иметь любое заданное листьев (N), в том числе и 3, как в вашем случае. Но B-деревья более эффективны для работы с внешними источниками данных, таких как файловые системы и базы данных.

К сожалению, ни на хабре, ни на других ресурсах я не смог найти достаточно полную информацию на русском языке…

На всякий случай, может автору будет интересно. Все вопросы со структурами данных подробно и понятно описаны в книге Роберта Седжвика «Алгоритмы на С++. Анализ структур данных, сортировка, поиск алгоритмы на графах», в том числе и на русском языке. Вся теория подробна изложена с реализацией на С++. Там описаны, в том числе, 2-...-N деревья, как частный случай B-деревьев и сами B-деревья. Вообще книга, на мой взгляд, является лучшей книгой по структурам данных для программистов.

Да, похоже выравнивание есть. Просто сбил с толку термин — «плотная» упаковка. Всегда думал что плотно можно упаковать только по-байтово, наподобие сериализации.

А правильно ли я понимаю, что ваш контейнер будет работать только на x86 архитектуре, где пофигу на выравнивание. Иначе, я не вижу где выравнивается адрес начала объекта? Попробую пояснить:
Допустим data_size() = 0. sizeof(uint8_t) = 1. Кладем в кортеж байт. sizeof(uint32_t)=4. При попытке положить целое его начало уже не будет выравнено, т.к. адрес будет data_size() + 1.

Не, я немного не об этом. Веб-сокеты, как раз, работают на всех, более или менее, современных платформах. Не работает MSE (Media Source Extensions). В моем случае, к счастью, нет необходимости поддерживать старые браузеры (до принятия WebSockets, как стандарта).

Ну, к счастью, клиентов на IOS у нас пока нет. Мы используем Web клиент как дополнительный тонкий клиент к основному, без процедуры установки. Все работает только во внутри-корпоративных сетях, где очень мало мобильных клиентов. Не совсем понял про «старые» советы. Веб-сокеты, действительно, реализованы поверх обычных tcp, но сверху там еще есть: handshake, отдельные сообщения с заголовками и т.д. Что делать с IOS пока не понятно, так как MSE там выпилено, даже в Хроме.

Да, нет. Мы вот тоже реализовали свой велосипед на С++. Правда, даже не поняли что он сложный. Гоняем по нему видео для MSE. Отлично работает на всех клиентах, кроме IOS-based.

Тут все как сами пожелаете. Про конкретное решение решение и степень его применимости не шло никакой речи. Обсуждались лишь теоретические аспекты реализации работы с видео и их плюсы и минусы, а также от том, как должны, в идеале, быть устроены модули для работы с видео, для того чтобы их можно было бы применять во всех своих решения, а не писать велосипед каждый раз под каждый новый случай, а потом бороться с последствиями упрощений.