Принимай дозу живительной урины на ротешник, смайлофаг.

О, пацанчик со сленгом из подвортни :-) Слушай, пацанчик, и врубайся :-)

1) При исключении в конструкторе, std::unique_ptr<T> _impl автоматически удалится, T* _impl - нет.

Какое исключение может быть в конструкторе виде T(Impl* impl) : impl_(impl) {} ? :-) Жидкий аргументишко от пацанчика :-)

2) std::unique_ptr<T> _impl автоматически запрещает конструктор копирования с оператором присваивания и генерирует конструктор перемещения с оператор перемещения. Для T* _impl все это надо писать руками.

Пацанчик не в теме :-) Для того, чтобы изречённая тобою всем известная истина о генерациях работала, объявление класса Impl должно быть доступно в месте объявления включающего его класса :-) Такой Impl нужен разве что на твоём локалхосте или пацанчикам в твоей подворотне :-) А программисты любят объявлять Impl через forward declaration, чтобы содержимое Impl были невидимо :-) А раз так, то в случае unique_ptr<Impl> impl_ начинаются те же самые манёвры, что и в случае Impl* impl_ - следует объявить деструктор, а значит, следует объявлять и перемещающие оператор и конструктор :-) Так что аргумент жидкий-жидкий :-)

3) std::unique_ptr гарантированно выдает ошибку при попытке удалить объект неполностью определенный типа

Пацанчик, именно поэтому, если unique_ptr используется в качестве типа для члена impl_ класса T, то в классе T объявляют деструктор, а в ед. трансляции делают T::~T() = default; или T::~T() {} :-) Но ты то не в курсе, ты даже того же Мейерса, который это разжевал для особо одарённых, не читал :-) Зато горазд мне что-то там лепетать :-)

а такая попытка это, между прочим, UB

Слив засчитан пацанчик :-) Смотри стандарт - 20.8.1.5 The template parameter T of unique_ptr may be an incomplete type. :-)

Дважист в треде, все в абстрактный синглтон прокси фактори бин.

Это вообще не в тему, пацанчик :-)

Сценарий не сказать, чтобы особо вероятный, но в нелёгком деле командной разработки ни от чего зарекаться нельзя.

А не надо в конструкторе класса, в котором Impl, генерировать исключения :-) Прям как в unique_ptr :-)

Смотри стандарт - 20.8.1.5 The template parameter T of unique_ptr may be an incomplete type. :-)

Ниасилил понять ни стандарт, ни что тебе пишут здесь. Молодец, чо.

20.8.1.1.2: «Remarks: If T is an incomplete type, the program is ill-formed.»

На пальцах, для дислектиков: если ты случайно пишешь в хедере ~MyClass() { delete impl; }, компилятор генерирует херню и, если повезёт, выдаёт тебе warning. Если у тебя unique_ptr<MyClassImpl> impl; и ты случайно пишешь в хедере ~MyClass() = default;, то компилятор считает программу некорректной и выдаёт соответствующий error.

А не надо в конструкторе класса, в котором Impl, генерировать исключения :-)

То есть, ты хочешь наложить на класс дополнительные ограничения исключительно, чтобы быть никаквсе? Типичное «назло мамке шапку не одену».

Хм, а там по-умолчанию clang code model? Если так, то у меня на большом проекте работает, но с auto часто тупит.

Надо завтра на работе посмотреть.

Какое исключение может быть в конструкторе виде T(Impl* impl) : impl_(impl) {} ?

Сегодня нет исключений, а завтра есть, код имеет свойства меняться со временем. Какие дальше будут оправдания? Что в твоем hello world'е код никогда не меняется? Ну ок, принято :) ( тем более что даже про noexcept я смотрю ты все равно ничего не слышал )

Для того, чтобы изречённая тобою всем известная истина о генерациях работала, объявление класса Impl должно быть доступно в месте объявления включающего его класса :-)

И? Вообще никаких проблем, доступно объявление, пишешь в хидер foobar::foobar(foobar&&) = deafult и foobar& foobar::operator=(foobar&&) = default, не доступно - пишешь их же в cpp'шник.

ЗАЧЕМ МНЕ НУЖЕН STD::UNIQUE_PTR, У МЕНЯ НЕТ ВРЕМЕНИ ЧТОБЫ ЕБАТЬСЯ С НИМ ЛУЧШЕ ЕЩЕ РАЗ НАПИШУ ПОЛНОЕ ОПРЕДЕЛЕНИЕ ДЕСТРУКТОРА И MOVE-КОНСТРУТКТОРА Я ПИШУ ДЕСТРУКТОРЫ И MOVE-КОНСТРУКТОРЫ ПО 100 РАЗА В ДЕНЬ :)

Зато горазд мне что-то там лепетать :-)

Ты вообще понял о чем я написал? С голыми указателями у тебя нет никаких гарантий от удаления неполностью опредеденного типа, только надежда на warning компилятора

Это вообще не в тему, пацанчик :-)

Так а что там на счет 100 классов-то? Каждый день наверное по сотне пишешь, да?

Ниасилил понять ни стандарт, ни что тебе пишут здесь. Молодец, чо.

Слив засчитан :-) В контексте 20.8.1.1.2 T - представляет собой аргумент void default_delete::operator()(T* ptr) const; :-) Т.е. речь идёт о месте вызова этого оператора, а не о месте определения std::unique_ptr<T> :-) Речь же о месте определения идёт в 20.8.1.1.1 - «The template parameter T of default_delete may be an incomplete type.» :-) Так что ты обделался :-)

На пальцах, для дислектиков: если ты случайно пишешь в хедере ~MyClass() { delete impl; }, компилятор генерирует херню и, если повезёт, выдаёт тебе warning.

Слив засчитан :-) Такое надо писать в единице трансляции, а не в заголовке :-)

Если у тебя unique_ptr<MyClassImpl> impl; и ты случайно пишешь в хедере ~MyClass() = default;, то компилятор считает программу некорректной и выдаёт соответствующий error.

Слив засчитан :-) Такое надо писать также в единице трансляции, иначе вся идея pimpl на смарку :-) А в единице трансляции полный тип MyClassImpl уже известен компилятору, а значит приведённый тобой пункт из стандарта за номером 20.8.1.1.2.4 уже не применим и программа не ill-formed :-)

То есть, ты хочешь наложить на класс дополнительные ограничения исключительно, чтобы быть никаквсе? Типичное «назло мамке шапку не одену».

Какие такие ограничения, если мне кроме как проинициализировать указатель в конструкторе больше ничего не надо :-) Лол :-)

точнее, идея единиц трансляции насмарку, да. Подскажу что ты можешь сделать: включить -flto. (или для экстремиствов - -fwhole-program) Тогда можно будет распилить код на сколько угодно файлов, и между ними всё еще будут работать инлайнинги и прочая хрень, нужная для релизной сборки

Сегодня нет исключений, а завтра есть, код имеет свойства меняться со временем.

Если твой пацанский код - времянка, которая рефакторится каждый день, тогда всем на этот код, кроме тебя, чихать :-) Применяй что хочешь, хоть unique_ptr, хоть ещё что-то :-)

И? Вообще никаких проблем, доступно объявление, пишешь в хидер foobar::foobar(foobar&&) = deafult и foobar& foobar::operator=(foobar&&) = default, не доступно - пишешь их же в cpp'шник.

За это и речь вообще-то, что это надо всё равно писать :-) Вообще никаких проблем написать 4 строчки оператора перемещения и одну строчку конструктора перемещения в ед. трансляции :-)

Ты вообще понял о чем я написал? С голыми указателями у тебя нет никаких гарантий от удаления неполностью опредеденного типа, только надежда на warning компилятора

Это аргумент, конечно :-) Но в цепепе нет гарантий и от выражений вида delete &«pacanchik»[0]; :-)

Так а что там на счет 100 классов-то? Каждый день наверное по сотне пишешь, да?

Балаболка, важно не то, сколько я их пишу, важно то, как я их пишу :-)

точнее, идея единиц трансляции насмарку, да.

Нет, идея pimpl в том, чтобы клиентский код не зависел он реализации вообще :-) И размер структур (классов, если хочется) должен оставаться в клиентском коде неизменным :-) Иначе нахрен этот pimpl не сдался :-)

Стиви, ты что, никогда не работал в проектах с унаследованной кодовой базой? Тот автор, может быть, задолго до твоего рождения уволился.

к сожалению, я только на таких проектах и работал. И знаешь что? У меня есть отличаная идея.

она звучит так: fuck this, I'm out

есть шуточная «теорема» на тему: качественно, быстро, недорого - одновременно только два из трех

идея в том, чтобы полностью перестать иметь дело с проектами, где нужно «быстро и недорого». Это определение говнокода.

нужно работать с проектами, которые как в метком определении Тёмы Лебедева: «Долго. Дорого. Офигенно.». Или хоят бы так: «дорого и офигенно долго» (на случай, когда «офигенно» не получается несмотря на все усилия).

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

с моей точки зрения глубоко невыгодно оправдываться тем, что «ой, это легаси код, он из другого времени». Тупо не выгодно. Легаси протухло? Напиши свежее, чо.

мы делаем не какие-то ржавые ножички, мы делаем катаны.

Господа, а на кой черт вообще ваш pimpl? Что мешает ограничится интерфейсом в заголовках, «статическим конструктором», скрыв всю реализацию в библиотеке?

Вся эта херотень выглядит одинаково уродливо и провоцирует более агрессивное использование heap-а со всеми неприятными вытекающими в виде фрагментации.

Т.е. речь идёт о месте вызова этого оператора, а не о месте определения std::unique_ptr<T> :-) Речь же о месте определения идёт в 20.8.1.1.1 - «The template parameter T of default_delete may be an incomplete type.» :-) Так что ты обделался :-)

Из контекста того, что тебе говорили раньше, очевидно, что имелось в виду место вызова, дислектичное быдло.

Такое надо писать в единице трансляции, а не в заголовке :-)

Пока ты ваяешь RAII-костыль на ровном месте, тебе надо не забыть:

• что деструкторы пишутся в единице трансляции;
• что в конструкторе и операторе перемещения надо юзать std::swap;
• что в деструкторе надо обнулить указатель;
• что ни в одном конструкторе не должно быть исключений.

Ничего не забыл? Ещё стоит учесть то, что ваяние этой фигни руками - процесс рутинный и делать это приходится не каждый день, ошибиться довольно легко. И ещё стоит учесть, что во взрослой жизни твои классы порой приходится поддерживать кому-то ещё, и что ему может понадобиться впихнуть в конструктор - совершенно непонятно. Зачем создавать себе ментальную нагрузку, а другим - геморрой, когда есть компилятор?

мне кроме как проинициализировать указатель в конструкторе больше ничего не надо

Это только пока ты сидишь за тарелкой борща и ваяешь сферичные пимплы в вакууме.

важно то, как я их пишу :-)

Никак вы их не пишите. И вообще на C++ не пишете. Как вы сами неоднократно говорили.

Из контекста того, что тебе говорили раньше, очевидно, что имелось в виду место вызова, дислектичное быдло.

Давай, обделавшийся, покажи пруф :-)

что деструкторы пишутся в единице трансляции;

Правильно :-)

что в конструкторе и операторе перемещения надо юзать std::swap;

Не обязательно :-) Это, кстати, лишняя временная переменная :-)

что в деструкторе надо обнулить указатель;

Правильно :-)

что ни в одном конструкторе не должно быть исключений.

Правильно :-)

Ничего не забыл?

Забыл подтереться :-)

Ещё стоит учесть то, что ваяние этой фигни руками - процесс рутинный и делать это приходится не каждый день, ошибиться довольно легко.

Есть макросы :-) В цепепе они убогие, но есть :-)

Это только пока ты сидишь за тарелкой борща и ваяешь сферичные пимплы в вакууме.

Лол :-)

Никак вы их не пишите. И вообще на C++ не пишете. Как вы сами неоднократно говорили.

Лучше расскажи тому кадру про то, зачем нужен pimpl, и что в unique_ptr<T> impl_, T может быть неполным :-)

покажи пруф

Держи: «std::unique_ptr гарантированно выдает ошибку при попытке удалить объект неполностью определенный типа»

Пока подтверждается только твоя дислексия, балаболка.

Это, кстати, лишняя временная переменная :-)

Её отсутствие - это лишняя строчка в конструкторе и фэйл в операторе присваивания. Ну, и пресловутая лишняя ментальная нагрузка. Кстати, не ты ныл недавно, что кресты - сложный язык? Если ты, зачем сейчас предлагаешь создавать себе сложности на ровном месте?

Есть макросы

Ты серьёзно? За них коллеги тебе скажут отдельное спасибо.

Господа, а на кой черт вообще ваш pimpl?

Без него в цепепе нельзя полностью скрыть детали реализации от клиента :-) В Си же принято использовать «opaque»-указатели для этого :-)

«статическим конструктором», скрыв всю реализацию в библиотеке?

Можно подробнее, что ты имеешь в виду? :-)

Без него в цепепе нельзя полностью скрыть детали реализации от клиента :-) В Си же принято использовать «opaque»-указатели для этого :-)

СОКРЫЛ!

// interface.hpp
class public_interface {
  public:
    virtual ~public_interface() {}
    virtual int voo() = 0;
    virtual void bar(int) = 0;
};

public_interface *make_interface(int parameter);

//implementation.cpp
#include "interface.hpp"
class private_implementation : public public_interface {
public:
  private_implementation(int param) { /* ... */ }
  // put implementation here
};

public_interface *make_interface(int parameter)
{
  return new private_implementation(parameter);
}

Господа, а на кой черт вообще ваш pimpl?

Бинарная совместимость, нет?

Что мешает ограничится интерфейсом в заголовках

Вот захотел ты добавить приватную функцию, которая не влияет на API - а ABI уже сломал. Вот для этого.

в виде фрагментации.

Слышал звон не знаю где он.

А потом кадры типа джобса удивляются откуда в плюсах быдлокод - вот из-за таких как вы.

А потом кадры типа джобса удивляются откуда в плюсах быдлокод - вот из-за таких как вы.

Обоснуй за быдлокод, или сольешься как обычно?

В 4.0.1 у меня по умолчаию clang. На работе комп не самый быстрый - так секунд 5-7 может думать, но выдает ответы верно(в случае auto тоже). Дома ноут помощнее - так уже 0.3-2 сек.

«std::unique_ptr гарантированно выдает ошибку при попытке удалить объект неполностью определенный типа»
Пока подтверждается только твоя дислексия, балаболка.

На это утверждение был дан ответ здесь :-) Ты же мне начал лепетать ни к месту такой вот куд-кудах «Ниасилил понять ни стандарт, ни что тебе пишут здесь.», «20.8.1.1.2: «Remarks: If T is an incomplete type, the program is ill-formed.»» :-) Так что подтверждается то, что ты обделался :-)

Её отсутствие - это лишняя строчка в конструкторе и фэйл в операторе присваивания.

С чего это? :-) operator(Foo&& other) noexcept { delete impl_; impl_ = other.impl_; other.impl_ = nullptr; return *this } :-) Только не надо кудахтать про отсутствие проверке на присваивание самому себе :-)

Если ты, зачем сейчас предлагаешь создавать себе сложности на ровном месте?

А unique_ptr медленнее, чем голый указатель в 2 раза без флага оптизимации -O :-)

Ты серьёзно? За них коллеги тебе скажут отдельное спасибо.

Коллеги, не знающие что такое макросы, мне не коллеги :-)

Сорри, ответ на «std::unique_ptr гарантированно выдает ошибку при попытке удалить объект неполностью определенный типа был дан здесь :-) Здесь уже был ответ на твой лепет :-)

СОКРЫЛ!

Нихрена ты не сокрыл :-) Добавление виртуальной функции перед или между имеющимися приведёт к тому, что в клиентском коде будет вызвана не та функция после перелинковки :-) Это ж цепепе :-)

То есть мифическая фрагментация вас волнует, а то, что интерфейс обязать быть полностью виртуальным, что реально ударит по производительности, - нет?

То есть мифическая фрагментация вас волнует, а то, что интерфейс обязать быть полностью виртуальным, что реально ударит по производительности, - нет?

Расскажи про производительность в контексте виртуальных интерфейсов авторам стандартных stream :-)

Т.е. лучше бы в цепепе вместо всяких костылей типа unique_ptr сделали бы возможным скрывать vtable из клиентского кода, чтобы можно было писать так, как ты показал :-) Иными словами, чтобы pimpl можно было бы готовить автоматически :-)

Операции со строками займут в тысячи раз больше времени, чем работа vtable.

Операции со строками займут в тысячи раз больше времени, чем работа vtable.

Какие тогда претензии к виртуальным функциям, я пойму? :-) Хочешь и рыбку съесть, и чтобы без виртуальных функций? :-)

А зачем они мне? У меня pimlp, а не костыль ТС.

А зачем они мне? У меня pimlp, а не костыль ТС

У него не костыль, у него как раз реальное использование рантайм-полиморфизма, предусмотренного C++ из коробки :-) И вот в его-то случае unique_ptr действительно полезен :-) А вот pimpl - это костыль, потому что по-другому полностью скрыть реализацию в C++ нельзя :-)

operator(Foo&& other) noexcept { delete impl_; impl_ = other.impl_; other.impl_ = nullptr; return *this }

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

На это утверждение был дан ответ здесь

Это другой пост, другого человека.

Ты же мне начал лепетать ни к месту

У меня был ответ на два твоих твой поста сразу. Решил не плодить два треда, не ожидал от тебя таких выдающихся качеств. Лепетание же не к месту было только у тебя.

Только не надо кудахтать

Ну, так прекращай.

про отсутствие проверке на присваивание самому себе

Почему? Либо делай ассерт, либо обеспечивай работу. Не сношай пользователям класса мозг UB.

А unique_ptr медленнее, чем голый указатель в 2 раза без флага оптизимации -O

Кому нужны кресты без оптимизации?

Коллеги, не знающие что такое макросы, мне не коллеги

Нежелание разбираться в твоих личных макрокостылях ничего не говорит об их знаниях макросов.

Сорри, ответ на «std::unique_ptr гарантированно выдает ошибку при попытке удалить объект неполностью определенный типа был дан здесь :-)

Расскажи тогда, на что отвечает это: «Слив засчитан пацанчик :-) Смотри стандарт - 20.8.1.5 The template parameter T of unique_ptr may be an incomplete type. :-)»

Дальше можно не продолжать. Возвращайтесь, когда напишите что-то побольше HelloWorld.

Вам того же. Поработаете с крупным проектом - поймете, о чем речь.

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

Так в рассматриваемом примере как раз простой код с копипастой становится более сложным кодом с лямбдой и неочивидными зависимостями, которые невыводимы из контекста. Да, копипаста сама по себе не проблема. Проблема - дублирование кода, которое ведет к усложнению поддержки, когда разнесено по проекту (если участок кода сдублирован рядом - это вообще никогда не проблема). При этом для того, чтобы избежать дублирования, код всегда приходится усложнять, по-этому на практике следует выбирать золотую середину - достаточно простой код и достаточно мало копипасты. В рассматриваемом случае усложнение очень сильное, а дублирование практически не снижается (да и локализовано, а значит непроблематично и не приведет к каким-то негативным последствиям ни в каком случае), овчинка выделки не стоит.

Да, и прочитайте где-нибудь о плюсовых лямбдах, захватах контекста и пр. Чтобы не нести бред про какой-то внешний контекст. Заодно почитайте про локальные функции, дабы было понятно, в какой роли выступает handle_halign.

Захват мутабельных переменных в лямбде ничем абсолютно от глобальных переменных не отличается. И то и другое ведет ровно к одним и тем же негативным последствиям для кода - неявные зависимости и непрослеживаемый поток управления.

Ложь названа ложью. В чем проблема такого заявления?

В чем проблема такого заявления?

Проблема конкретно заявления Ушат помоев в сторону крестолюбов (комментарий) - в том, что оно бредово.

Давайте уточним: «чем меньше кода - тем легче его воспринимать» - это ложь?

Я бы еще поверил во вкусовщину, но отрицание - это клиника.

как минимум (в nginx ковыряться по работе не приходилось), freebsd, и, особенно, redis — тот ещё адок

Поработаете с крупным проектом - поймете, о чем речь.

Прекрасно понимаю о чем речь. Как раз последние два дня занимался устранением последствий копипасты.

Так в рассматриваемом примере как раз простой код с копипастой

Простой код с копипастой всегда является бомбой замедленного действия. Если вам никогда не приходилось ловить одну и ту же ошибку в разных местах из-за того, что фрагмент кода тупо растиражировали, то вы не понимаете о чем речь.

становится более сложным кодом с лямбдой и неочивидными зависимостями, которые невыводимы из контекста.

Где вы там увидели сложный код, неочевидные зависимости и невыводимость из контекста?

Захват мутабельных переменных в лямбде ничем абсолютно от глобальных переменных не отличается.

Скажите честно: вы просто дебил или захотелось пофлеймить на форуме?

что в деструкторе надо обнулить указатель;

омг, ещё один

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

... что отсутствует ревью :)

от языка это никак не зависит, кстати

17 страниц подряд умученые плюсами жабисты, лисперы, и прочие любители экзотики рассказывают, как _им_ невозможно писать на c++.

топикстартер вон вообще попытался закосить под «своего». скоро видимо пойдут сальные истории «я пишу на С++ и он такой ужасный».

зачем? я вот не пишу на лиспе, и мне пофиг на него. ну не пишите на нём. просто не пишите. каждую неделю шоу «бомбящие пуканы» на форуме устраиваете.

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

Добавление виртуальной функции

Я так понимаю, понятие «стабильный ABI» тебе неведомо. Тем не менее, такое встречается даже в крестах.

У меня был ответ на два твоих твой поста сразу. Решил не плодить два треда, не ожидал от тебя таких выдающихся качеств. Лепетание же не к месту было только у тебя.

У тебя получилось только обделаться :-)

Почему? Либо делай ассерт, либо обеспечивай работу. Не сношай пользователям класса мозг UB.

Конкретно здесь была конкретная демонстрация, что временная переменная в операторе присваивания не нужна, а не демонстрация полной версии этого оператора :-) Своё ко-ко-ко про UB оставь для таких же обделывающихся :-)

Кому нужны кресты без оптимизации?

Снова обделался :-) Кому нужны ассерты? :-) Кому нужны дебажные сборки? :-) Мне нужны :-) К твоему сведению, они даже в продакшене применяются :-) Об этом даже Страуструп писал :-)

Нежелание разбираться в твоих личных макрокостылях ничего не говорит об их знаниях макросов.

Ты в них и не будешь разбираться :-) Не переживай, это не для тебя :-)

Я так понимаю, понятие «стабильный ABI» тебе неведомо.

Ты сейчас теоретизируешь, или ты пробовал? :-)

Тем не менее, такое встречается даже в крестах.

Последний раз, когда я попробовал так сделать с GCC, написав маленький тест, то клиентский код вызвал не ту функцию после перелинковки :-)

Ты сейчас теоретизируешь, или ты пробовал? :-)

Пробовал. Если у тебя меняется интерфейс, то можно просто поменять имя so-шки (-Wl,-soname). Через несколько лет научишься сходу делать нормальные интерфейсы.

Последний раз, когда я попробовал так сделать с GCC, написав маленький тест, то клиентский код вызвал не ту функцию после перелинковки :-)

Сделай еще раз и покажи. КрестоABI вполне себе детерминированное, и если ты не делаешь херни, все работает. Но если бы крестодевелоперы не делали херни, они бы не лабали на лучшем в мире языке для написания глюкавых, текущих памятью, падучих крестоподелий.

Сделай еще раз и покажи.

Ну вот, накатал на скорую руку :-) GCC 5.3.0.

lib_api.hpp:

struct S {
  virtual ~S() = 0;
  // будет добалена позднее для теста перелинковки
  // virtual void f3() const = 0;
  virtual void f1() const = 0;
  virtual void f2() const = 0;
};

S* make_s();

lib_api.cpp:

#include "lib_api.hpp"

S::~S() = default;

lib_impl.hpp:

#include "lib_api.hpp"

struct S_impl : S {
  // будет добалена позднее для теста перелинковки
  // void f3() const override;
  void f1() const override;
  void f2() const override;
};

lib_impl.cpp:

#include "lib_impl.hpp"
#include <stdio.h>

void S_impl::f1() const
{
  printf("S_impl::f1\n");
}

void S_impl::f2() const
{
  printf("S_impl::f2\n");
}

// будет добалена позднее для теста перелинковки
// void S_impl::f3() const
// {
//   printf("S_impl::f3\n");
// }

S* make_s()
{
  return new S_impl;
}

app.cpp:

#include "lib_api.hpp"

int main(int argc, char *argv[])
{
  S* obj = make_s();
  obj->f1();
  obj->f2();
  return 0;
}

Сборка и проверка:

$ g++ -std=c++14 -shared -fPIC -oliblib.so lib_api.cpp lib_impl.cpp
$ g++ -std=c++14 -oapp app.cpp -L. -llib
$ LD_LIBRARY_PATH=. ./app
S_impl::f1
S_impl::f2

Добавляем функцию f3() в API и реализацию, пересборка API и проверка:

$ g++ -std=c++14 -shared -fPIC -oliblib.so lib_api.cpp lib_impl.cpp
$ LD_LIBRARY_PATH=. ./app
S_impl::f3
S_impl::f1

Упс :-) Добавление вирт. функции не работает, как и ожидалось :-)