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

Есть еще одна мысль рядом. Может быть, мы вообще неправильно организуем области доступа?

class Some {
private:
    int data; //участвует в вычислении размера
    virtual void poly(); //добавляется в таблицу виртуальных функций
    void nonpoly(); //декларирована только потому, что нужен доступ в приватные данные
public:
    friend operator << (std::istream&, Some); //декларирована только потому, что нужен доступ в приватные данные
};

Скажем, может быть вот так и существует понятие пространства имён класса?

class Some {
private:
    int data; //участвует в вычислении размера
    virtual void poly(); //добавляется в таблицу виртуальных функций
};
namespace class Some::private {
    void nonpoly(this Some& self);
}
//some.cpp
namespace class Some::private {
     namespace {
         void nonpoly_detail(this Some& self) {}
     }
    void nonpoly(this Some& self) {
         self.nonpoly_detail();
    }
}

class Some {
private:
    int data; //участвует в вычислении размера
    virtual void poly(); //добавляется в таблицу виртуальных функций
    void nonpoly(); //декларирована только потому, что нужен доступ в приватные данные
public:
    friend operator << (std::istream&, Some); //декларирована только потому, что нужен доступ в приватные данные
};

class Some {
private:
    int data; //участвует в вычислении размера
    virtual void poly(); //добавляется в таблицу виртуальных функций
};
namespace class Some::private {
    void nonpoly(this Some& self);
}
//some.cpp
namespace class Some::private {
     namespace {
         void nonpoly_detail(this Some& self) {}
     }
    void nonpoly(this Some& self) {
         self.nonpoly_detail();
    }
}

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

final?

Возможность написать #define private public не рассматривается. C++ не предполагает защиту от целенаправленной стрельбы себе в ногу, это базовая концепция языка.

И, тем не менее, от #define private public мы хотя бы формально защищены стандартом, поскольку это UB из-за дефайна ключевого слова и из-за ODR violation. А тут мы прямо таки выдаём новый инструмент, чтобы стрелять стало ещё удобнее и чтобы нас вообще только честное слово останавливало от стрельбы по себе же

UB только говорит, что программист сам несёт ответственность за эти действия. Мне кажется, что за запись в приватные данные чужого класса точно так же отвечает понятно кто. C++ идеологически считает, что программист при наличии умысла все равно обойдет любую защиту от дурака. Если вам кажется, что C++ основан на других принципах, объясните существование const_cast.

И да, сложно представить мои слова благодарности Бьёрну за этот подход, когда я написал 30 штук const_cast за день. А вот как из std::bitset достается первая единица я промолчу.

"Я не менял конст-значение. Это просто пацаны за гаражами интерфейс на С89 использовали, а я просто рядом стоял".

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

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

да кстати, нужны перегрузки std::contr_zero и прочих для std::bitset

Ничто не помешает другому пользователю написать

namespace class Some::private {
   void nonpoly(this Some& self);
}
в своём файле, получив доступ к приватным полям

Защититься фундаментально невозможно, конечно же, но я не уверен, что стоит ещё сильнее упрощать способ делать опасные вещи

а, ну тут да, предлагается нарушение инкапсуляции

Ничто не мешает мне исправить заголовочный файл, заменив там слово private на public для всех полей

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

В общем, за обсуждением см. design & evolution of C++, раздел 2.10 protection model

Вдруг вам будет интересно. Нашел пример: https://habr.com/ru/post/111275/
Он, конечно, так сходу не завёлся, в нём есть пара косяков - возвращали адрес локального буфера, забыли в плюсовом коде вызвать функцию, которая в ассемблере заимплеменчена, но если всё исправить, то оно компилируется и работает. Из минусов - непонятно пока, как всё это сделать с cmake, потому что сейчас нужно проекты в IDE конфигурировать

Классический антипаттерн "Паблик Морозов"

CMake из коробки умеет в enable_language(ASM)