История изменений

ну проблема в том что если не прятать поля, то ими обязательно начнут пользоваться.

Проблема для кого? Для линукса? Ну может быть и проблема. Хотя с их stable api is nonsense и Линусом, матерящим всех, как будто бы и не проблема. Напиши в комментарии, что это поле внутреннее, назови его через подчёркивание или через internal_, вариантов на уровне соглашения придумать можно.

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

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

Понимаешь, если ты поменяешь название поля (или его уберёшь), то у человека сломается код и может быть он подумает, что делает.

А если ты поле не выставляешь, то человек всё равно туда залезет. Через что-нибудь вроде (uint32_t)((char*)ptr + 12). Если уж ему приспичило. А бывает, что нужно, нельзя всё в API идеально продумать, а ждать новой версии можно долго. И вот такой код точно сломается очень неприятно.

Уж лучше залезать в кишки осознанно и типобезопасно.

сделать всё хедер онли.

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

PS почитать было в любом случае интересно, спасибо, может и пригодится

ну проблема в том что если не прятать поля, то ими обязательно начнут пользоваться.

Проблема для кого? Для линукса? Ну может быть и проблема. Хотя с их stable api is nonsense и Линусом, матерящим всех, как будто бы и не проблема. Напиши в комментарии, что это поле внутреннее, назови его через подчёркивание или через internal_, вариантов на уровне соглашения придумать можно.

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

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

Понимаешь, если ты поменяешь название поля (или его уберёшь), то у человека сломается код и может быть он подумает, что делает.

А если ты поле не выставляешь, то человек всё равно туда залезет. Через что-нибудь вроде (uint32_t)((char*)ptr + 12). Если уж ему приспичило. А бывает, что нужно, нельзя всё в API идеально продумать, а ждать новой версии можно долго. И вот такой код точно сломается очень неприятно.

Уж лучше залезать в кишки осознанно и типобезопасно.

сделать всё хедер онли.

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