Страницы

Поиск по вопросам

понедельник, 15 октября 2018 г.

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

Многие моменты непонятны, к примеру этот : #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 плохо. Дело тут в том, что: такой код не преследует образовательные цели предполагается хорошее знание предмета (т.е. что в какой ситуации делает функция, а вовсе не познание функциональности путем чтения кода) обычно код мультиплатформенен (это его часто либо засоряет, либо заставляет разработчика делать достаточно абстрактную структуру, где реализация конкретной функциональности лежит внизу, да и связи по данным не всегда очевидны) желающие могут дополнять до бесконечности... -- Но, все равно читайте чужой код (особенно известных библиотек).

Комментариев нет:

Отправить комментарий