Как разбираться в исходном коде stl?

#stl #cpp

Многие моменты непонятны, к примеру этот :
#define _IOSskipws      0x0001
#define _IOSunitbuf 0x0002
enum _Fmtflags
        {   // constants for formatting options
        _Fmtmask = 0xffff, _Fmtzero = 0};

    static const _Fmtflags skipws = (_Fmtflags)_IOSskipws;
    static const _Fmtflags unitbuf = (_Fmtflags)_IOSunitbuf;

Это части кода из файла xiobase. Зачем _IOSunitbuf приводится к _Fmtflags и как работает
это приведение?
В общем это один из вопросов. Может есть где-нибудь статьи/книги/..., которые бы
если не полностью, то частично объясняли код в исходниках? Вероятней всего, что опытные
программисты поймут почти весь код и при первом знакомстве с STL, потому как вряд ли
там своя экосистема и они уже встречали подобные коды в разных источниках. Возможно
когда-нибудь и я смогу делать это с простотой, но сейчас хотелось бы какой то документации(по
исходному коду, а не по тому что он дает) для чайников что-ли).    

Ответы

Ответ 1

@strol, по сути этот код сводится к 4-м макросам
#define _IOSskipws  1
#define _IOSunitbuf 2
#define  skipws     _IOSskipws
#define  unitbuf    _IOSunitbuf

все остальные буковки неужны для того, чтобы компилятор вдоволь поругался на возможные
ошибки программиста в разных частях кода.
Обычно это называют заботой о качестве программного обеспечения (или чем-то в этом
духе) и пишут на эту тему целые книги.
Вы спросите: Почему 4, а не 2 макроса?
Скорее всего это связано с некой несогласованностью при проектировании (короче, просто
исторически так сложилось...)
Но сразу напишу, что реально большой плюс enum _Fmtflags заключается не только в
том, что компилятор проверяет типы, но и отладчик "видит" эти имена (в отличие от имен
в #define).
Тоже - так сложилось. Лично я предпочел бы улучшить отладчик (хотя, конечно, одно
другому не мешает).
--
А это уже ответ на комментарий
Ясно). А стоит ли в каких-то других исходниках больших библиотек копаться? К примеру
в некоторых частях буста. Или там не лучше с читабельностью?

@strol, думаю не лучше. Это не означает, что в STL плохо.
Дело тут в том, что:


такой код не преследует образовательные цели


предполагается хорошее знание предмета (т.е. что в какой ситуации делает функция,
а вовсе не познание функциональности путем чтения кода)


обычно код мультиплатформенен (это его часто либо засоряет, либо заставляет разработчика
делать достаточно абстрактную структуру, где реализация конкретной функциональности
лежит внизу, да и связи по данным не всегда очевидны)


желающие могут дополнять до бесконечности...


--
Но, все равно читайте чужой код (особенно известных библиотек).