Мдя... вот вроде и в комитете по стандартизации, а предлагают такие вещи делать :( Это конечно работает и достаточно надежно, но считать размер объекта в ручную... А еще весело, если проект собирается в одном случае под 32-х разрядную платформу, а в другом 64-х разрядную. Ну ОК, 128 разрядную :)
Хотя это не проблема Яндекса, конечно :)

А и главное, что если объект который с таким весельем запихиваем в pimpl делает аллокации, то выигрыш получается, только если мы много и часто создаем такие объекты. Но в целом идея прикольная, напоминает когда в С/C++ в конце сруктуры/класса размещали поле массив из одного элемента, а по факту, когда объект создавался размер массива менялся и в памяти после объекта дописывались элементы этого массива.

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

Я не говорю, что оно не достаточно безопасно, я прсто не очень понимаю выигрыш от таких приседаний, а вот дополнительные сложности вижу. Опять же, если меняется объект, который мы хотим спрятать (меняется его размер), то в классическом pimpl это бы header не затронуло и не вызвало бы лишних перекомпиляций, а тут вызовет.

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