Pzz>Для компании, интересы которой пересекаются с мелкософтом, держать в штате человека, который копался в исходниках ядра, может быть опасно. Одно дело, если человек про это молчит, компания не обязана его допрашивать с пристрастием при приеме на работу (расписочку, впрочем, могут и попросить). Совсем другое дело, если человек хвастается этим на каждом углу.
Это так, но а) в Америке б) если интересы пересекаются с мелкософтом. Не у всех они пересекаются.
Pzz>Что такого содержательного делает эта функция, что не делает ее посиксный аналог?
Backup semantics, возможность указать ACL для вновь создаваемого файла.
Pzz>Ну вот, например, bus driver от тостера. Он работает с 2-мя видами девайсов, PDO и FDO, и у каждого своя логика обработки запросов. Нормальный человек записал бы в Device Extensions табличку указателей на обработчики, а в MajorFunction[] засунул бы указатели на функции, которые достают указатель на нужный обработчит из Device Extensions конкретного DEVICE_OBJECT, и передают туда управление.
Ну я именно так и делаю, но ничто не мешает сделать иначе.
Pzz>Нет, в сампле каждый обработчик по-отдельности разбирается с тем, PDO или FDO ему дали, и по-разному с ними работает.
Минус, но маленький.
Pzz>Да ну, перестаньте. Я в DDKных самплах и настоящие ошибки находил, которые могут систему порушить, если не повезет. Лень просто сейчас вспоминать, где это было, но в каком-то из простых примеров — синхронизация вокруг IRP cancellation была с ошибкой.
Ага, было такое раз. Причем это был именно безделушечный sample типа toaster, но не
Пример этот я, кстати, читал именно что бы разобраться в этом самом cancellation'е
Pzz>Памилте. В одном из моих драйверов было 60 тышш строк кода
У меня тоже такое было.
Pzz>Просто Вы сложных драйверов не писали.
Точнее — не писал портабельных. Не были интересны моим работодателям платформы, отличные от винды.
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, netch80, Вы писали:
N>>А ведь менеджеру в том числе нужно чтобы, если ты не дай бог попал под трамвай, или бросил всё и уехал в Шамбалу искать смысл жизни — чтобы заменить тебя было реально решаемой проблемой в течение максимум недель...
TL>А теперь представь себе что все, кто начинал и продолжал писать эту программу, попали под трамвай и уехали в Шамбалу — и остался ты с программой один на один и есть у тебя описания всех функций и классов и даже названия у них очень даже "говорящие" и каждый отдельный алгоритм вполне понятен, но вот нет никаких данных а) что система делает вообще; б) что она должна делать в принципе.
Давай не представлять себе подобные крайние случаи? Я не представляю себе, как можно достичь подобного результата и, главное, зачем. Ну а сферических коней в вакууме рассматривать не хочу.
TL> А проблемой замены "попавших под трамвай" в течение недели (после взятия на работу, да: поиск и найм — отдельный вопрос) я давно "озабочен" и определенные наработки имеются — в том числе, например, по динамическому переключенению имеющихся ресурсов на "горящие" участки. Так вот: доксиген там не только не помогает, а очень даже наоборот. А почему? А потому что писать много, а смысла — мало. Описывать хороший код по параметрам функций — смысла нет — описывать надо конкретные цели, которых добивались, конкретные решения, которые правили, и конкретные результаты, которых достигли. А для описания технической сути решения часто не только достаточно 2-3-х диаграмм — часто как эти 2-3 диаграммы дают гораздо более полное и полезное описание системы, модуля, etc., чем целый вагон доксигена. :user: Знаем — плавали. :crash:
Ну так я и не говорю, что doxygen (или аналог — мне достаточно без разницы, как оно зовётся) приоритетнее _этой_ документации или общей. Нет, скорее наоборот. Но общая нужна всегда, а пофункциональная имеет свою специфическую область применимости — и вот именно её многие не хотят осознавать и адекватно оценивать.
Здравствуйте, netch80, Вы писали:
TL>>... но вот нет никаких данных а) что система делает вообще; б) что она должна делать в принципе.
N>Давай не представлять себе подобные крайние случаи? Я не представляю себе, как можно достичь подобного результата и, главное, зачем. Ну а сферических коней в вакууме рассматривать не хочу.
Вы можете лично устроить опрос и оценить статистику — хорошо если "подобного результата" будет процентов 50...
N>Ну так я и не говорю, что doxygen (или аналог — мне достаточно без разницы, как оно зовётся) приоритетнее _этой_ документации или общей. Нет, скорее наоборот. Но общая нужна всегда, а пофункциональная имеет свою специфическую область применимости — и вот именно её многие не хотят осознавать и адекватно оценивать.
Генерацию "документального" представления описания функций по составленному специальным образом описанию в исходном коде? Ну, гипертекстовая навигация по коду оказывается удобной — однако ту же функциональность весьма успешно обеспечивает все та же "микрософт студия" — имхо, удобнее просто текстовые пояснения в комментариях по коду писать, если уж есть что написать. Получется "документы, зачем-то зашитые форматированием в код" — а зачем?
Здравствуйте, shrecher, Вы писали:
S>Стиль кода, кстати, очень характерный для всех драйверов, никакого c++. Доморощенные списки и очереди. Нормально названные переменные и пр.
А Вы еще не заметили, какой здесь бред обсуждается?
Ну в каком стиле C++ написано ядро Windows?!
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Здравствуйте, SP_, Вы писали:
SP_>Здравствуйте, Unmanaged, Вы писали:
U>>Разжёвывать мне сейчас лень, кому надо — правильно поймут, что я имел в виду.
SP_>Батенька, складывается впечатление, что круче вашей фирмы только яйца. Озвучте пожалуйста название вашей конторы.
Здравствуйте, bkat, Вы писали:
B>Извини, но такие вещи тупо декларируются в фирменном "coding guideline", B>который просто вручается каждому новичку. B>Совершенно формальная штука. B>Ты уж лучше интересуйся не стилем, а тем фактом, работал ли человек B>на проекте, где единый стиль был определен и им необходимо было пользоваться.
Та вы шо??? Никак не можно!!! У них там на фирме даже стулья расставлены как в Майкрософт (как в отделе разработки ядра), воздух дует как в Майкрософт (как в отделе разработки ядра), и ваще, если вы кнопки жмете как не-кернел программер, то не судьба в этой конторе поработать.
AZ>>Все "забивают" на апдейт коментариев...
U>А вы обновляете их ежедневно ? U>Наверное, глупо.
U>При нормально поставленном процессе это необходимо делать раз в месяц, а то и реже.
Каков тогда смысл в комментариях, если изменили функцию, комменты еще не исправили, а я уже успел на основе старых комментов разработать другую функциональность, которая совсем не учитывает внесенных изменений. И синий экран мне в подарок... Может лучше править комменты сразу?
Здравствуйте, kaa.python, Вы писали:
KP>ну.. яб не стал ровнять начинающих руководителей и самодуров KP>но, в целом, подмечено очень верно. какой-то юношеский максимализм у товарища присутствует. хотя, возможно, эдакая антиреклама фирмы, сейчас кто либо брякнет название компании автора топика, и прослывет она еще одной нежелательной для прохождения собеседований компанией.
Что-то автор боится называть контору. Может понял, что антирекламу уже сделал?
Здравствуйте, Unmanaged, Вы писали:
B>>Чтобы сэкономить время на поиск программеров, вы можете просто зафиксировать свои представления B>>о хорошем стиле и поместить их на фирменный сайт. B>>Тем самым вы избавите себя от тех кандидатов, которые не захотят писать код в таком стиле
U>Интересная мысль. U>Спасибо за идейку .
И все же, может озвучите название фирмы и дадите ссылку на сайт ваш?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Шелл у нас мдааа... но, говоря про "хороший стиль кодирования виндов" — говорят именно о кернеле и вообще о native OS. Шелл писала другая команда, команда Win95, и написан он именно такими же руками, что и вся Win95.
Здравствуйте, trophim, Вы писали:
T>Каков тогда смысл в комментариях, если изменили функцию, комменты еще не исправили, а я уже успел на основе старых комментов разработать другую функциональность, которая совсем не учитывает внесенных изменений. И синий экран мне в подарок... Может лучше править комменты сразу?
первоисточником был и пока что остается код. Не вижу причин к изменению этого дела и в ближайшем будущем.
Зачем слепо верить комментариям, лучше посмотрите в код и с помощью комментариев уточните смутные места. А внося исправления в код — не забудь исправить и комментарий, если он перестает быть адекватным. По-моему это азы. И не надо для этого выдерживать гроссмейстерскую паузу в месяц — это просто нужно делать сразу.
PS Синий экран на основе комментариев это любопытно. при правильном использовании API и имея понятие зачем оно и где применимо, а где нет — как правило синие экраны очень редки — из-за опечаток чаще, пожалуй.
PPS Я не говорю о black boxes, где кроме спецификаций\документации на интерфейс/API ничего нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
.
