#[unsafe(no_mangle)]
pub extern "C" fn _start() -> ! {
let mut game = Arkanoid::new();
Ага. Осмотрелся повнимательнее. Я правильно понимаю, что это заклинание как раз сделало то, что категорически не приветствуется. Объявило unsafe контекст на весь код. И дальше не столь важно будет или не будет вложенный блок (функция) помечена как unsafe - это уже ничего не изменит. А данный пример, делает по сути не больше и не безопаснее, чем аналогичный С код? Так получается?
Тем более интересно посмотреть подстрочную трансляцию. И в первую очередь третьей строчки в этом частичном листинге.
И еще - а что реально такая большая разница между asm! в Rust и asm{} в С? Я полагал что это куда как более близкие родственники, чем #define.
Потом - не всякий ассемблер небезопасен. В частности примеры автора - надо сильно много думать, чтоб придумать их небезопасное поведение. nop как инструкция абсолютно безопасна - она просто не делает ничего (кроме инкремента PC). Чтение порта... Ну, черт знает. Была бы запись - да, возможно. Чтение... На вскидку даже не предположу что и как оно может поломать. Правда и на 100% уверенно сказать что не может не возьмусь. Но на 99,9 точно уверен - не может. Если к кого есть пример как оно может поломать - пишите. Будет интересно заняться цифровой археологией. Раз уж все равно клавиатуру из 0x60-ого порта считываем (это даже не юность - это мое детство).
Собственно потому и удивляет безусловное недоверие ассемблерным вставкам. Фобией попахивает. Или параноей. Кому что ближе.
На Rust пишут полубоги и боги - они читают документацию на все, и все без исключения. А на unsafe функции с особой тщательностью. А на C быдлокодеры, которые документацию не читают и не пишут в принципе. Вообще и никогда. И отладке не обучены - потому где программа ломается они не знают.
А если серьезнее, то мне казалось что unsafe - это указание компилятору о том, что результат функции не безопасен и может выходить за пределы ожидаемых значений. Возможно, потребуется дополнительный контроль и выброс исключения.
Теперь буду знать, что unsafe - это не для компилятора, а для программиста. Указание на то, что надо посмотреть документацию или реализацию.
Ладно, подождем когда оно в мой мир доползет. Там и будем разбираться серьезнее. Вообще, очень хотелось бы посмотреть на ассемблерный код данного примера в режиме параллельного перевода. Как это бы транслировалось с С я понимаю. Интересно чем будет отличаться кодогенерация с Rust.
Знаете, я уже третий раз пытаюсь ответ написать. Так чтоб ненароком не обидеть тонкие чувства. Но:
Это не ответ на заданный вопрос. Если любой asm! автоматически считается небезопасным, то зачем это указывать явно в коде?
Использовать у себя код, которому нет доверия? Вы серьезно?
Если у обертки asm! не стоит unsafe, то по той же логике мы вполне доверяем. И чего спрашивается? Или это работает как-то по другому?
Впрочем, ну его. И так скорее всего из банальной опечатки столько текста наплодили.
Тем более, что главная-то претензия не здесь была. Она была к нарезки времени пустым циклом. Очень зависимо от конкретного ПК и даже его настроек энергосбережения. В свое время над Digger'ом ржали. Там такое решение было, в итоге даже на 386 он носился как наскипедаренный. А именно эту часть пропустили.
Впрочем оно тоже понятно - библиотеки с задержкой нет. А значит тут "путь самурая".
По сути принято и понято. По факту мне сложно представить как "nop" или "in" на это способны. Если in, хоть и с большим трудом и аппаратными особенностями, но можно притянуть, то nop... Я просто хочу понять логику автора кода. И да, я крайне плохо знаю Rust. Потому часть вопросов задаю с позиции привычных мне языков (С/asm).
... компилятор решит выкинуть повторное чтение из одного и того же порта или переставит местами две операции ввода-вывода
Интересно... А вариант использовать unsafe вокруг "core::arch::asm!("in al, dx", out("al") value, in("dx") port);" как это сделано в main() вокруг "nop" не прокатит? Компилятор просто выбросит не проверяя что именно функция делает?
И что же это получается - "великий и могучий" использует худшие практики SUN'овского компилятора - выбрасывать и переставлять ассемблерные вставки пользователя если ему это специально не запретить? А за одно не избавляет от избыточно умных оптимизаций кода (главная проблема на-Си-льников во встраиваемых системах)?
for _ in 0..50_000 {
unsafe { core::arch::asm!("nop") };
}
Вот интересно, что было бы если бы подобное было написано d основном цикле на C? А так да - великий и могучий Rust.
И еще вопрос.
pub unsafe fn inb(port: u16) -> u8
А здесь-то почему unsafe? Казалось бы безопаснее функции, чем чтение порта и придумать сложно. Оно гарантированно завершится с абсолютно известным результатом?
По первой части - ну да, ну да. Правда, именно к нашему брату это редко относится. Скорее наоборот - примерить на себя то что надо, и что не надо. Опять же - про себя я все знаю, но... Ко мне, как к старшему, молодежь не только по рабочим моментам обращается. Тем более, что к счастью и в нерабочей жизни все совсем не плохо. Но одно дело когда я рассказываю, и совсем другое когда практикующий специалист. Степень доверия разная. Во всяком случае, если мнения не совпадают. А я, в отличии от вас, могу судить только по себе любимому и своим наблюдениям за друзьями. Узок круг этих революционеров, как говаривал один из великих.
По семейной жизни - просто очень часто в последнее время эти вопросы стали задавать. Обычные страхи в стиле
я никому не нужен и не интересен
сегодня не делают таких, как мне надо
хочу чтоб глаз радовался и было о чем поговорить
я не знаю о чем говорить, чтоб обоим интересно было
не IT'шник никогда не поймет и не будет разделять моих увлечений
детей хочу, но какой из меня отец - всегда в работе (вариант - но я же сатрап и деспот)
у меня есть ответы, но... Есть и опасения, что они исключительно мои. Не готов я выдавать не то что рецепты, но даже рассуждения. Да и на итоговый обобщенный опыт я бы и сам посмотрел. По моим мироощущениям счастье случается когда выдыхаешь и начинаешь понимать - хобби и работа разные вещи. В работе профи, а хобби можно по дилетантски, его заказчику сдавать не надо, а не понравится - за то что выкинешь никто ругаться не будет. Как и на то, что одно хобби надоело - взялся за другое. И все равно что - от бально-танцевательного кружка (с) до спорта и аквариумистики. Лучше, правда, от IT и логики подальше. Вот именно тогда круг общения расширяется. И темы для разговоров находятся. И IT помогает, но не подменяет. Это про знакомство и начало отношений.
А дальше обычно нормально. Обязательность работает на руку. Правда от половинки многое зависит. Если там есть та самая женская "химия" - то все, повода для беспокойства нет. Как и с детьми. Ну некоторое время получат они в избытке того, чего самому в детстве не хватало. Но и это пройдет. Вообще по детям мне очень нравится подход вашей коллеги - Екатерины Мурашовой. Лекций на ныне не работающем хватает. Умеет она доходчиво объяснить. Хуже когда у будущей супруги цель "выйти замуж за успешного и перспективного". И к ней идёт всеми правдами и неправдами. И относятся как к проекту. К счастью такое относительно редко встречается.
Так что запрос не о детях, а о родителях. Так сказать погасить страхи, что не получится из IT'шника толкового родителя. Получится. И далеко не самый плохой.
По теме статьи - ну да, ну да... Тревожность по поводу "это еще разгрузка или уже лень" - она лет до 35. Потом потихоньку доходит - если дело делается в установленные самим сроки - значит разгрузка. Если нет - уже лень. И на окружающих смотреть перестаешь. А равно задаваться вопросом "где люди денбги берут?" Отчасти потому, что знаешь ответ, и знаешь чем это грозит, а отчасти потому что понимаешь - не стоит оно этих денег. Да и про все остальное тоже. Справедливость? Да нет ее. И не было. И не будет. Ну и славно - делай, что должно и будь что будет. Интеллект? Трубу в ванной одним только интеллектом не поменяешь. А у меня еще и Питер - тут можно нарваться на бомжа, который философских трактатов куда больше твоего прочитал и по памяти дословно цитирует. Ответственность - ну да. Такова жизнь. Главное самому не кусать больше, чем проглотить сможешь. Но до этого до всего надо дожить и набить свои шишки. По возможности не скатившись до зависимостей. От чего угодно.
Хотите предложение для следующей статьи? Семейная жизнь и отношения с детьми типового IT'шника. Тут тоже есть много своеобразных особенностей. Они похожи с рабочими, но некоторые светят сильно ярче. Полагаю той аудитории, которая 25-30 это было бы полезно.
SUNO AI 3.5 - офигенно! Не, безусловно, "пластмассовый мир победил (с)", но результат реально впечатляет. Интересно было бы дать подобное музыкантам и сравнить результаты. Особенно интересно как бы выглядело "Кря" в каком-нить регги, буги-вуги или Death-Metal.
Я верю. В бесконечной вселенной возможно все. И, право слово, было бы даже любопытно посмотреть на подъем 50 кг на пятый этаж (у меня в фитнес зал-то многие на шестой на лифте катаются, куда там еще и груз в половину своей массы сверху).
Безусловно, это лишь мои наблюдения. Особенно он заметно в походах или выполнении погрузо-разгрузочных работ. Да, те кто в границах ИМТ в моменте могут поднять даже на 10-15% больше, чем те кто по верхней границе и чуть выше. Но приемрно час нагрузки для них уже смертельно. Нужен привал с энергетической подпиткой или хотя бы просто перерыв. Взрывное выделение энергии. А те, кто немного выше - наоборот способны работать по несколько часов. Безусловно это не догма, но в своем окружении я не вижу ни одного опровержения.
Что до мешка картошки, то это более-менее хороший тест на выносливость. Нет сомнений, что так или иначе его доставит любой. Вопрос как это сделают, и как после этого себя будут чувствовать. Ноги и спина нагружены в любом случае, какая часть рук - зависит от хвата. Сделать это в один заход не так просто, как кажется. А уж повторить... Но в любом случае очень энергозатратное упражнение. Хуже только разгрузка бутилированной воды. Там вес и количество этажей, как правило меньше, но объемы сильно больше. Просто посмотрите на тех, кто занимается ее доставкой и разгрузкой.
Может быть. Мне, как человеку заставшему код на 80186 без всяких MSDOS и в последствии занятым как раз низкоуровневым для ПК (в основном для Linux), да контроллерами, включая незабвенные 8051 с очень похожим ассемблером, уже начинает казаться что это нечто типа набившего оскомину Cobol'а у импортных финансистов.
Типа есть и есть. По возможности не трогай, чтоб не воняло. А если вдруг что, то немного денег кинем и нам все починят. Потому сюда особо народ не рвется. Навыки нужны несколько специфичные, денег больших нет, спрос и ответственность офигенные, результата работы в идеале не видно вообще. Стоишь ядовитой слюной забрызганный в стиле мы круты, а вы все криворукие, но ничего скоро наша ржа вас всех сожрет и не подавится. Только вот как-то не жрет. Скотина такая. Самим выкручиваться приходится.
Не пиши «TODO» просто в коде. Создавай полноценную задачу в трекере с описанием проблемы и желаемым решением. Так о ней не забудут.
Это если есть трекер. И если есть проблема. Мой проект, как правило, при сборке выдает пяток варнингов, все они результат кода типа
#warning FixMe: I don't know border value now
#warning ToDo: This time input garbage ignored. May be error generated here?
И даже если трекер есть, то я добавлю сюда код в трекере. Ошибки и предупреждения при сборке мозолят глаза. И когда их становится критично много с ними приходится или как-то бороться или удалять как неважные.
Безусловно, такой подход требует написания "чистого кода", в котором собственные предупреджения не потеряются на фоне многочисленных предупреждений компилятора (к слову ненавижу VHDL за генерацию простыни предупредений в абсолютно любом проекте - но это и не про программирование как таковое). Впрочем, мне кажется что это просто правила хорошего тона, и говорить о их соблюдении как-то странно. Они или безусловно соблюдаются, или безусловно игнорируются.
Да уж. Прямо детство. Не пионерское, постарше. Но детство. debug.com, правда, не сильно любили. Скорее Turbo Debuger, а потом и более интересные варианты. Буквально следом должен идти перевод Криса Касперски о том, как взломать хиты времен MsDOS.
Надо ли только это хоть кому-то? Уже и в ассемблер для контроллеров мало кто заглядывает, что тут про специфичную археологию времен DOS да еще с "$"-терминированными строками. Хотя, безусловно, там было очень много интересного.
Смотря что брать за критерии оценки. Я видел классные проекты, сделанные единственным реально высококлассным разработчиком. К сожалению, я гораздо чаще видел, мягко говоря, весьма посредственные проекты, сделанные тем, кто таковым себя считал. При этом ценность "встречных плюшек" обычно была не очевидна ни для кого, кроме самого автора.
И не надо меня спрашивать про реальные проекты. Я не имею привычки злопамятно хранить плохие решения и не занимаюсь и не занимался их сопровождением. В лучшем случае доработкой, но обычно переработкой. И, самое главное - помимо проекта надо доставать контекст. Это практически не возможно в рамках комментариев и ровно по тем же причинам отсутствует в вашей статье. Не брать же за реальные примеры описание всяческих конструкций, выполненных дендрофекальным методом на потребу дня.
Плюс всегда есть возможность сказать - ну это же точно делал не мастер. Я же не такой. Круче меня только яйца, и то если очень долго варить. Критичнее надо относиться. И в первую очередь к себе. В частности рекомендация не писать простой код (без крайней на то необходимости) - это явное наплевательское отношение к тем, кто по каким-то причинам будет этот код сопровождать. И, на самом деле, совершенно не важно с какой стороны пятилетки от сдачи кода это понадобится. Включая (но не ограничиваясь) наплевательское отношение к будущему себе. Впрочем, оговорюсь, есть моменты когда сложный код необходим.
А пользоваться реально хорошими решениями сторонних разработчиков - да безусловно. Но только в том случае, если персонально тебе кристально понятно как они работают и какие накладные расходы создают для твоего проекта. Иначе это будет не проект, а монстр-Франкенштейн (ну или лоскутное одеяло, если такая аналогия понятнее). Да, оно будет работать, но жгучего желания делать так же не вызовет. Что, в свою очередь, соответствующим образом охарактеризует автора.
Ну да, если ты Rockstar и единственный разработчик на проекте, то все так. В остальных случаях надо смотреть. Идеи здравые, но... Видели мы и их последствия. Скажем так - очень часто они не подпадают под "тащи к себе лучшее, из увиденного".
Ага. Осмотрелся повнимательнее. Я правильно понимаю, что это заклинание как раз сделало то, что категорически не приветствуется. Объявило unsafe контекст на весь код. И дальше не столь важно будет или не будет вложенный блок (функция) помечена как unsafe - это уже ничего не изменит. А данный пример, делает по сути не больше и не безопаснее, чем аналогичный С код? Так получается?
Тем более интересно посмотреть подстрочную трансляцию. И в первую очередь третьей строчки в этом частичном листинге.
И еще - а что реально такая большая разница между asm! в Rust и asm{} в С? Я полагал что это куда как более близкие родственники, чем #define.
Потом - не всякий ассемблер небезопасен. В частности примеры автора - надо сильно много думать, чтоб придумать их небезопасное поведение. nop как инструкция абсолютно безопасна - она просто не делает ничего (кроме инкремента PC). Чтение порта... Ну, черт знает. Была бы запись - да, возможно. Чтение... На вскидку даже не предположу что и как оно может поломать. Правда и на 100% уверенно сказать что не может не возьмусь. Но на 99,9 точно уверен - не может. Если к кого есть пример как оно может поломать - пишите. Будет интересно заняться цифровой археологией. Раз уж все равно клавиатуру из 0x60-ого порта считываем (это даже не юность - это мое детство).
Собственно потому и удивляет безусловное недоверие ассемблерным вставкам. Фобией попахивает. Или параноей. Кому что ближе.
Спасибо, стало понятнее
На Rust пишут полубоги и боги - они читают документацию на все, и все без исключения. А на unsafe функции с особой тщательностью. А на C быдлокодеры, которые документацию не читают и не пишут в принципе. Вообще и никогда. И отладке не обучены - потому где программа ломается они не знают.
А если серьезнее, то мне казалось что unsafe - это указание компилятору о том, что результат функции не безопасен и может выходить за пределы ожидаемых значений. Возможно, потребуется дополнительный контроль и выброс исключения.
Теперь буду знать, что unsafe - это не для компилятора, а для программиста. Указание на то, что надо посмотреть документацию или реализацию.
Ладно, подождем когда оно в мой мир доползет. Там и будем разбираться серьезнее. Вообще, очень хотелось бы посмотреть на ассемблерный код данного примера в режиме параллельного перевода. Как это бы транслировалось с С я понимаю. Интересно чем будет отличаться кодогенерация с Rust.
Знаете, я уже третий раз пытаюсь ответ написать. Так чтоб ненароком не обидеть тонкие чувства. Но:
Это не ответ на заданный вопрос. Если любой asm! автоматически считается небезопасным, то зачем это указывать явно в коде?
Использовать у себя код, которому нет доверия? Вы серьезно?
Если у обертки asm! не стоит unsafe, то по той же логике мы вполне доверяем. И чего спрашивается? Или это работает как-то по другому?
Впрочем, ну его. И так скорее всего из банальной опечатки столько текста наплодили.
Тем более, что главная-то претензия не здесь была. Она была к нарезки времени пустым циклом. Очень зависимо от конкретного ПК и даже его настроек энергосбережения. В свое время над Digger'ом ржали. Там такое решение было, в итоге даже на 386 он носился как наскипедаренный. А именно эту часть пропустили.
Впрочем оно тоже понятно - библиотеки с задержкой нет. А значит тут "путь самурая".
<сарказм: включено>
Ничего личного, но не спросить не могу
Думаете с мужчинами будет проще?
<сарказм: выключено>
Это ритуал такой? Типа обязательной утренней молитвы?
Или тотальное недоверие программисту по определению не умеющему safe на ассемблере?
И зачем тогда требовать его явно указывать, если это реально ВСЕГДА так?
По сути принято и понято. По факту мне сложно представить как "nop" или "in" на это способны. Если in, хоть и с большим трудом и аппаратными особенностями, но можно притянуть, то nop... Я просто хочу понять логику автора кода. И да, я крайне плохо знаю Rust. Потому часть вопросов задаю с позиции привычных мне языков (С/asm).
т.е. unsafe fn здесь реально бесполезна, как я писал в первом комментарии, как и блок unsafe вокруг asm? А опасения @Deosis абсолютно беспочвенны?
Опция "хозяйственная" исключена в принципе? Или подразумевается по-умолчанию? Или ради нее чем-то еще придется пожертвовать?
Интересно... А вариант использовать unsafe вокруг "core::arch::asm!("in al, dx", out("al") value, in("dx") port);" как это сделано в main() вокруг "nop" не прокатит? Компилятор просто выбросит не проверяя что именно функция делает?
И что же это получается - "великий и могучий" использует худшие практики SUN'овского компилятора - выбрасывать и переставлять ассемблерные вставки пользователя если ему это специально не запретить? А за одно не избавляет от избыточно умных оптимизаций кода (главная проблема на-Си-льников во встраиваемых системах)?
Вот интересно, что было бы если бы подобное было написано d основном цикле на C? А так да - великий и могучий Rust.
И еще вопрос.
А здесь-то почему unsafe? Казалось бы безопаснее функции, чем чтение порта и придумать сложно. Оно гарантированно завершится с абсолютно известным результатом?
По первой части - ну да, ну да. Правда, именно к нашему брату это редко относится. Скорее наоборот - примерить на себя то что надо, и что не надо. Опять же - про себя я все знаю, но... Ко мне, как к старшему, молодежь не только по рабочим моментам обращается. Тем более, что к счастью и в нерабочей жизни все совсем не плохо. Но одно дело когда я рассказываю, и совсем другое когда практикующий специалист. Степень доверия разная. Во всяком случае, если мнения не совпадают. А я, в отличии от вас, могу судить только по себе любимому и своим наблюдениям за друзьями. Узок круг этих революционеров, как говаривал один из великих.
По семейной жизни - просто очень часто в последнее время эти вопросы стали задавать. Обычные страхи в стиле
я никому не нужен и не интересен
сегодня не делают таких, как мне надо
хочу чтоб глаз радовался и было о чем поговорить
я не знаю о чем говорить, чтоб обоим интересно было
не IT'шник никогда не поймет и не будет разделять моих увлечений
детей хочу, но какой из меня отец - всегда в работе (вариант - но я же сатрап и деспот)
у меня есть ответы, но... Есть и опасения, что они исключительно мои. Не готов я выдавать не то что рецепты, но даже рассуждения. Да и на итоговый обобщенный опыт я бы и сам посмотрел. По моим мироощущениям счастье случается когда выдыхаешь и начинаешь понимать - хобби и работа разные вещи. В работе профи, а хобби можно по дилетантски, его заказчику сдавать не надо, а не понравится - за то что выкинешь никто ругаться не будет. Как и на то, что одно хобби надоело - взялся за другое. И все равно что - от бально-танцевательного кружка (с) до спорта и аквариумистики. Лучше, правда, от IT и логики подальше. Вот именно тогда круг общения расширяется. И темы для разговоров находятся. И IT помогает, но не подменяет. Это про знакомство и начало отношений.
А дальше обычно нормально. Обязательность работает на руку. Правда от половинки многое зависит. Если там есть та самая женская "химия" - то все, повода для беспокойства нет. Как и с детьми. Ну некоторое время получат они в избытке того, чего самому в детстве не хватало. Но и это пройдет. Вообще по детям мне очень нравится подход вашей коллеги - Екатерины Мурашовой. Лекций на ныне не работающем хватает. Умеет она доходчиво объяснить. Хуже когда у будущей супруги цель "выйти замуж за успешного и перспективного". И к ней идёт всеми правдами и неправдами. И относятся как к проекту. К счастью такое относительно редко встречается.
Так что запрос не о детях, а о родителях. Так сказать погасить страхи, что не получится из IT'шника толкового родителя. Получится. И далеко не самый плохой.
Сергей, давно вас не было слышно.
По теме статьи - ну да, ну да... Тревожность по поводу "это еще разгрузка или уже лень" - она лет до 35. Потом потихоньку доходит - если дело делается в установленные самим сроки - значит разгрузка. Если нет - уже лень. И на окружающих смотреть перестаешь. А равно задаваться вопросом "где люди денбги берут?" Отчасти потому, что знаешь ответ, и знаешь чем это грозит, а отчасти потому что понимаешь - не стоит оно этих денег. Да и про все остальное тоже. Справедливость? Да нет ее. И не было. И не будет. Ну и славно - делай, что должно и будь что будет. Интеллект? Трубу в ванной одним только интеллектом не поменяешь. А у меня еще и Питер - тут можно нарваться на бомжа, который философских трактатов куда больше твоего прочитал и по памяти дословно цитирует. Ответственность - ну да. Такова жизнь. Главное самому не кусать больше, чем проглотить сможешь. Но до этого до всего надо дожить и набить свои шишки. По возможности не скатившись до зависимостей. От чего угодно.
Хотите предложение для следующей статьи? Семейная жизнь и отношения с детьми типового IT'шника. Тут тоже есть много своеобразных особенностей. Они похожи с рабочими, но некоторые светят сильно ярче. Полагаю той аудитории, которая 25-30 это было бы полезно.
На здоровье. И еще. И это даже не интерпретаторы, а вполне себе компиляторы.
К сожалению далеко не все на них можно реализовать. А что-то можно, но на С проще.
SUNO AI 3.5 - офигенно! Не, безусловно, "пластмассовый мир победил (с)", но результат реально впечатляет. Интересно было бы дать подобное музыкантам и сравнить результаты. Особенно интересно как бы выглядело "Кря" в каком-нить регги, буги-вуги или Death-Metal.
Я верю. В бесконечной вселенной возможно все. И, право слово, было бы даже любопытно посмотреть на подъем 50 кг на пятый этаж (у меня в фитнес зал-то многие на шестой на лифте катаются, куда там еще и груз в половину своей массы сверху).
Безусловно, это лишь мои наблюдения. Особенно он заметно в походах или выполнении погрузо-разгрузочных работ. Да, те кто в границах ИМТ в моменте могут поднять даже на 10-15% больше, чем те кто по верхней границе и чуть выше. Но приемрно час нагрузки для них уже смертельно. Нужен привал с энергетической подпиткой или хотя бы просто перерыв. Взрывное выделение энергии. А те, кто немного выше - наоборот способны работать по несколько часов. Безусловно это не догма, но в своем окружении я не вижу ни одного опровержения.
Что до мешка картошки, то это более-менее хороший тест на выносливость. Нет сомнений, что так или иначе его доставит любой. Вопрос как это сделают, и как после этого себя будут чувствовать. Ноги и спина нагружены в любом случае, какая часть рук - зависит от хвата. Сделать это в один заход не так просто, как кажется. А уж повторить... Но в любом случае очень энергозатратное упражнение. Хуже только разгрузка бутилированной воды. Там вес и количество этажей, как правило меньше, но объемы сильно больше. Просто посмотрите на тех, кто занимается ее доставкой и разгрузкой.
Может быть. Мне, как человеку заставшему код на 80186 без всяких MSDOS и в последствии занятым как раз низкоуровневым для ПК (в основном для Linux), да контроллерами, включая незабвенные 8051 с очень похожим ассемблером, уже начинает казаться что это нечто типа набившего оскомину Cobol'а у импортных финансистов.
Типа есть и есть. По возможности не трогай, чтоб не воняло. А если вдруг что, то немного денег кинем и нам все починят. Потому сюда особо народ не рвется. Навыки нужны несколько специфичные, денег больших нет, спрос и ответственность офигенные, результата работы в идеале не видно вообще. Стоишь ядовитой слюной забрызганный в стиле мы круты, а вы все криворукие, но ничего скоро наша ржа вас всех сожрет и не подавится. Только вот как-то не жрет. Скотина такая. Самим выкручиваться приходится.
Это если есть трекер. И если есть проблема. Мой проект, как правило, при сборке выдает пяток варнингов, все они результат кода типа
И даже если трекер есть, то я добавлю сюда код в трекере. Ошибки и предупреждения при сборке мозолят глаза. И когда их становится критично много с ними приходится или как-то бороться или удалять как неважные.
Безусловно, такой подход требует написания "чистого кода", в котором собственные предупреджения не потеряются на фоне многочисленных предупреждений компилятора (к слову ненавижу VHDL за генерацию простыни предупредений в абсолютно любом проекте - но это и не про программирование как таковое). Впрочем, мне кажется что это просто правила хорошего тона, и говорить о их соблюдении как-то странно. Они или безусловно соблюдаются, или безусловно игнорируются.
Да уж. Прямо детство. Не пионерское, постарше. Но детство. debug.com, правда, не сильно любили. Скорее Turbo Debuger, а потом и более интересные варианты. Буквально следом должен идти перевод Криса Касперски о том, как взломать хиты времен MsDOS.
Надо ли только это хоть кому-то? Уже и в ассемблер для контроллеров мало кто заглядывает, что тут про специфичную археологию времен DOS да еще с "$"-терминированными строками. Хотя, безусловно, там было очень много интересного.
Смотря что брать за критерии оценки. Я видел классные проекты, сделанные единственным реально высококлассным разработчиком. К сожалению, я гораздо чаще видел, мягко говоря, весьма посредственные проекты, сделанные тем, кто таковым себя считал. При этом ценность "встречных плюшек" обычно была не очевидна ни для кого, кроме самого автора.
И не надо меня спрашивать про реальные проекты. Я не имею привычки злопамятно хранить плохие решения и не занимаюсь и не занимался их сопровождением. В лучшем случае доработкой, но обычно переработкой. И, самое главное - помимо проекта надо доставать контекст. Это практически не возможно в рамках комментариев и ровно по тем же причинам отсутствует в вашей статье. Не брать же за реальные примеры описание всяческих конструкций, выполненных дендрофекальным методом на потребу дня.
Плюс всегда есть возможность сказать - ну это же точно делал не мастер. Я же не такой. Круче меня только яйца, и то если очень долго варить. Критичнее надо относиться. И в первую очередь к себе. В частности рекомендация не писать простой код (без крайней на то необходимости) - это явное наплевательское отношение к тем, кто по каким-то причинам будет этот код сопровождать. И, на самом деле, совершенно не важно с какой стороны пятилетки от сдачи кода это понадобится. Включая (но не ограничиваясь) наплевательское отношение к будущему себе. Впрочем, оговорюсь, есть моменты когда сложный код необходим.
А пользоваться реально хорошими решениями сторонних разработчиков - да безусловно. Но только в том случае, если персонально тебе кристально понятно как они работают и какие накладные расходы создают для твоего проекта. Иначе это будет не проект, а монстр-Франкенштейн (ну или лоскутное одеяло, если такая аналогия понятнее). Да, оно будет работать, но жгучего желания делать так же не вызовет. Что, в свою очередь, соответствующим образом охарактеризует автора.
Ну да, если ты Rockstar и единственный разработчик на проекте, то все так. В остальных случаях надо смотреть. Идеи здравые, но... Видели мы и их последствия. Скажем так - очень часто они не подпадают под "тащи к себе лучшее, из увиденного".