Многие моменты непонятны, к примеру этот :
#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, потому как вряд ли там своя экосистема и они уже встречали подобные коды в разных источниках. Возможно когда-нибудь и я смогу делать это с простотой, но сейчас хотелось бы какой то документации(по исходному коду, а не по тому что он дает) для чайников что-ли).
Ответ
@strol, по сути этот код сводится к 4-м макросам #define _IOSskipws 1 #define _IOSunitbuf 2 #define skipws _IOSskipws #define unitbuf _IOSunitbuf все остальные буковки неужны для того, чтобы компилятор вдоволь поругался на возможные ошибки программиста в разных частях кода. Обычно это называют заботой о качестве программного обеспечения (или чем-то в этом духе) и пишут на эту тему целые книги. Вы спросите: Почему 4, а не 2 макроса? Скорее всего это связано с некой несогласованностью при проектировании (короче, просто исторически так сложилось...) Но сразу напишу, что реально большой плюс enum _Fmtflags заключается не только в том, что компилятор проверяет типы, но и отладчик "видит" эти имена (в отличие от имен в #define). Тоже - так сложилось. Лично я предпочел бы улучшить отладчик (хотя, конечно, одно другому не мешает). -- А это уже ответ на комментарий Ясно). А стоит ли в каких-то других исходниках больших библиотек копаться? К примеру в некоторых частях буста. Или там не лучше с читабельностью? @strol, думаю не лучше. Это не означает, что в STL плохо. Дело тут в том, что: такой код не преследует образовательные цели предполагается хорошее знание предмета (т.е. что в какой ситуации делает функция, а вовсе не познание функциональности путем чтения кода) обычно код мультиплатформенен (это его часто либо засоряет, либо заставляет разработчика делать достаточно абстрактную структуру, где реализация конкретной функциональности лежит внизу, да и связи по данным не всегда очевидны) желающие могут дополнять до бесконечности... -- Но, все равно читайте чужой код (особенно известных библиотек).
Комментариев нет:
Отправить комментарий