Всем хорошо известен данный проект на www.masm32.com. Реальный результат проекта это файл размером больше 1 mb c примитивной структурой (все просто свалено в одну кучу). Мне уже очевидны грядущие трудности его сопровождения. Быть может на его основе организовать альтернативный проект на wasm.ru обладающий более продуманной структурой и состоящий из нескольких файлов включаемых в windows.inc? Думаю что для начала полезно выделить значения всех сообщений в отдельный файл и сгрупировать их по значениям в соответствии win32.hlp Аналогично со структурами. Директивы includelib пестреющие в начале каждого нового проекта я бы перенёс в соответствующий библиотеке inc файл Хатч от подобных мероприятий отказался по принципу наименьших телодвижений - "делай это проще дурачок".
Asterix Легче искать и добавлять объявления. Тебе бы понравился windows.h размеров 50 мб, в котором весь PSDK? И интересно, как к нему отнёсся бы компилятор. Rockphorr В фасме отдельно файлы. И по мере надобности я добавляю к своим очередные порты из PSDK. Тем более, это становится всё проще.
Идея неплоха, но копаться в структурах, сделанных hutch - ещо то удовольствие... Хотя идея и полезна, но... Принять участие я вряд ли смогу - я лучше направлю усилия на изучения асма, а не оптимизацию инклудов P. S. Я вообще вынес все инклуды в программе(а также обьявление режима процессора, модели памяти и прочее) в отдельный файлик и делаю только include header.inc (так как в Masm неиспользуемые библиотеки не линкуются, то все путем)
Обычно большинство структур и констант (пишу на fasm) определяю вручную, копирую в начало кода или в отдельный инклудник, если их слишком много. Определения, правда, беру из windows.inc или сишных заголовочных. Имхо - так лучше понимаешь собственную программу
Ну и что получится? Второй сишный бардак. Чтобы найти объявление структуры или константы, приходится скакать по десятку разных файлов. В девяти хидерах ничего кроме ссылки на следующий хидер: #ifndef _BLA_ #include <something_01.h> #endif нету. А полезная инфа только в десятом файле. И пока доберешься до нужного, всё на свете проклянёшь. Трудно придумать более глупую систему, чем дробить цельное на куски. А в windows.inc все под рукой. Да и F3 для кого придуман? И для чего? Чтобы не листать вручную мегабайт. К тому же этот мегабайт раскидать по разным файлам - он что меньше станет? Наоборот. Плюс неизбежная путаница: а где у меня лежит такая-то структура, и в каком файле спрятана некая константа? Пользуйтесь F3 и будет вам счастие.
cresta Как раз не путаница - путаница, когда всё в куче. А так структуры и константы сгруппированы по сфере использования - user, shell, advapi и т.п. А для поиска grep никто не отменял, да и в PSDK всё описано.
Если определения в одном файле, мне всё равно, в каком порядке они там расположены. Хоть в алфавитном порядке, хоть сгруппированые по признакам user/shell/kernel, хоть перемешаные в случайном порядке. Разницы никакой. И никакого неудобства. Потому что в любом случае я для поиска буду использовать F3. А ему всё равно, что и в каком порядке расположено. В сишных инклюдах чтобы найти что-то, мне надо знать, к какой группе константа или структура относится. Чтобы примерно локализовать область поиска. Те константы, структуры и объявления, которые я помню по памяти, я нахожу достаточно быстро и в сишных инклюдах. Но дело в том, что те, которые я помню наизусть, мне не нужно искать. Искать приходится те, с которыми сталкиваешься в первый раз. А вот их местонахождение - совсем не очевидная вещь. И начинается беготня по файлам. Кроме того, разбиение на мелкие файлы неизбежно приводит к появлению ветвлений и затычек #ifndef-#ifdef. Посмотрите любой сишный инклюд - половина текста в них - это затычки и переопределения. И при этом регулярно возникают undefined symbol и symbol redifinition. Особенно показательны в этом смысле инклюды DDK. Сплошной маразм. Хорошо хоть есть виндовый поиск по тексту внутри файла, единственное спасение. Но и с ним приходится вручную отслеживать цепочки инклюдов, по пути исправляя ifdef на ifndef и наоборот. Или вы не сталкивались с исходниками, в которых несколько экранов листаются эти ifdef'ы, и в самом конце пара строчек с непосредственно кодом? Это всё издержки дробления. Хотя если вы мазохисты, кто может вам помешать? Дробите на мелкие части и получайте своё удовольствие )))
давеча обновлял Windows.inc, добавляя в него константы ресурсов (RT_MANIFEST etc), для этого просто нашёл RT_ICON и добавил после RT_HTML. соответствующий .h файл - WinUser.h, найти так же просто, как и случае одного-единственного файла: маска *.h, искать текст "RT_ICON". так что разницы особой нет, если искать с умом - найдётся любое камно в помойке .inc и .h в крайнем случае помогает MSDN, т.к. пишет, в каком .h лежит описание. в итоге (если вам так хочется), можете разбить всё содержимое Windows.inc по файлам с неким смыслом, т.к. всегда будет возможность собрать это в один Windows.inc ))
cresta Я предлагаю прежде чем дробить подумать КАК и СКОЛЬКО частей должно быть Мне пока очевидноа только целесообразность выделения сообщений в отдельный файл и групировка их по значениям согласно win32sdk.hlp Я с экранами IFDEF не сталкивался так как вообще не люблю С и С++ - популярность их зиждится на средствах работы с указателями, хотя наглядности ветвлений никакой глаза сломаешь пока поймешь что куда
Rockphorr Не могу понять, для чего это нужно? Чтобы сократить размер? Суммарный размер однозначно вырастет. Чтобы удобнее ковыряться в инклюдах в поисках объявлений? В инклюдах должен ковыряться компилятор, а ему всё равно 1 Мб или 100 х 10 Кб. Даже с одним файлом ему значительно проще. А для программера существует msdn/psdk, где всё и так уже давно структурировано и разложено по полочкам. Там и ищем структуры с объявлениями. Или охота оставить след в истории? Ну в таком случае конечно ))
cresta всё равно 1 Мб или 100 х 10 Кб. Например, программа простая, ей не нужны shell, ole, socket и т.п., то уже не 100. Rockphorr Быть может на его основе организовать альтернативный проект imho пустая трата времени. + не любишь Си и Си++ - не надо болтать про них глупости. 2 admin's Переносите тему в heep или project.
cresta чтобы проще было его сопровождать и вносить изменения то есть было очевидно куда это добавить + как правильно сказал q_q не всегда он нужен целиком q_q пустая только потому, коллективную работу тут организовать практически невозможно и вместо классного инструмента получится туфта я глупостей не говорил я выразил лишь свое мнение он наглядности листингов без претензий на абсолютную истину
Rockphorr пустая только потому, коллективную работу тут организовать практически невозможно Пустая трата времени, потому что не сформулирована цель. Невозможность организовать коллективную работу - это следствие отсутствия цели. Сформулируй цель, которая была бы интересна и/или являлась стимулом. "Более продуманная структура и несколько файлов" - это средства достижения цели, а какова цель? чтобы проще было его сопровождать и вносить изменения то есть было очевидно куда это добавить Это больше похоже на цель, только она не является достаточным стимулом, т.к. вносить изменения приходиться крайне редко. я выразил лишь свое мнение он наглядности листингов А как же: "... популярность их зиждится на средствах работы с указателями ...", или это не ты?
Это и есть моё мнение Сомневаюсь что все прочие его прелести вместе взятые дали бы ему такую поулярность Так например все паттерны из лежащего тут фрагмента книги основаны на работе с указателями
