Спасибо за статью! На самом деле ситуация крайне интересная, и очень хорошо перекликается с вопросом об ответственности за решения, принятые на основе "экспертных" рекомендаций от ИИ (буквально вчера обсуждали с коллегой).
И хотя мы обсуждали это в контексте разработки ПО, оправдания клиента, мол, "это не я дурак, это ии плохой", в некотором роде подтверждают мой тезис о том, что "вопрошающая" сторона будет пытаться всеми силами снимать с себя любую ответвенность за ошибки (хотя в налоговой уже такое не пройдём).
В глобальном плане, уже становится страшновато от того, что будущем, возможно, придётся работать с руководителями которые всю свою мыслительную деятельность будут делегировать чату. Но это я драмматизирую.
Всё же, наверное, автор имел ввиду не открытый мир как таковой, а открытую структуру самих уровней с очень большой, даже по сегодняшним меркам, вариативностью. Там буквально написано: "Тогда многих поразил один только дизайн открытых уровней", и лично для меня - это прямо в точку.
Я помню у меня был момент, когда при первом прохождении я полез в прохожение (в журнале ЛКИ), что бы перепроверить какие-то моменты, и примерно долистав до нужного места - я вообще не понял о чём идёт речь, потому что моё прохождение пошло по одному месту по совешенно другому пути. Или вот более конкретный пример (под спойлером, потому что там довольно важный сюжетный момент):
Скрытый текст
В моменте, когда на квартиру нашего братишки Пола налетают правительственные агенты, и он говорит нам бежать - мне даже в голову не пришло, что можно остаться. И это имеет очень сильное влияние на дальнейшее развитие событий.
И вот чисто в этом плане, MD, при своей, в целом, камерности, мне кажется ближе к оригиналу. HR - хорош, но вместо "свободного" геймплея первой части, она, в рамках уровня, как будто толкает игрока на вполне определённые "пути". Но это чисто моё субъективное. В любом случае очень жаль, что серия заглохла.
Но да, с подобным я, непосредственно, сталкивался на практике, когда на каком-то маленьком АRMе (к сожалению уже точно не помню, что конкретно там был за чип) каст байтового указателя, с адресом не кратным размеру слова, к указателю большего типа, с поледущим чтением из последнего, приводил к тому, что результат читался не из исходного адреса, а из ближайшего кратного. Иными словами:
uint8_t b[8] = { 0x01, 0x00, ... }; // допустим, b указывает на 0x00000000
uint8_t* pb = b + 1; // pb указывает на 0x00000001
uint32_t* pu = (uint32_t*)pb; // pu всё ещё указывает на 0x00000001
uint32_t u = *pu; // ожидаем, что u == 0, но u == 1
Конкретно тот код изначально затачиваля под 32-битную Винду и MSVC, и корретно работал после портирования на десктопный Linux/GCC. А вот при портировании на этот АRМ, понадобилось проверять выравнивания исходных адресов (в местах, где мы не знаем этого изначально), и при необходимости, как Вы и сказали - кастить через буфер.
Поэтому да, всегда надо понимать что и к чему кастится, и особенно, если меньший тип к большему. В обратную сторону - чуть сложнее, но тоже можно нарваться на неприятности (если, конечно, делать это не специально).
Как отметил комментатор выше - в С++ это UB без исключений, но реализовано и работает в самых распространённых компиляторах.
В С - по идее могут быть приколы, если написать так:
union {
uint16_t u16;
uint8_t u8;
} u;
u.u8 = 1;
return u.u16 == 1; // байты u16 не влезающие в u8 - не определены
Но даже в этом случае - они называют это "unspecified", а не "undefined", а это, насколько я понимаю, немного разные вещи.
Ну и справедливости ради, до вашего комментария, о том что тут в принципе где-то может UB до я и знать не знал :) Получается, что из этого вопрос можно вытянуть ещё больше, чем я думал.
Как сказал мой первый руководитель: "всё ваше программирование - это, в конце концов, всего лишь перекладывание данных из одной области памяти в другую" :)
Ну в целом со всем согласен, разве что бинарный поиск (и ему подобные) может быть уместен чисто как защита от дурака - тут не столько про алгоритмы, сколько проверить что человек вообще видел язык по которому собеседуется (хотя на сеньорском уровне это, вроде как, должно подразумеваться со старта).
Из вопросов такого плана у меня есть один очень хороший, по моему мнению, пример. Мне его впервые задали на техсобесе на сишника в московский Samsung, и хоть в Samsung я в итоге не пошёл (а пошёл в SK hynix), этот вопрос мне хорошо запомнился и я сам не раз его использовал.
Звучит примерно так: написать функцию/макрос, которая в рантайме проверяет порядок байт (endianness) на машине на которой этот код выполняется. Под спойлером (на случай если кто-то захочет проверить себя) - пара возможных решений (верхнее дал я сам):
Почему я считаю это вопрос хорошим? Потому что по ответу, вмещающемуся буквально в 3-4 строчки (или даже в одну), можно вполне себе адекватно оценить насколько кандидат понимает что-то в С. И дело здесь не в решении конкретной проблемы, "практичность" которой можно оспорить (хотя лично мне оно не раз пригождалось), а в понимании как оно вообще всё устроено в этой жизни.
Ну это уже больше выживач, чем РПГ :) но в целом да, так тоже работает. Опять же, авторы могут не давать прямых указаний, как крафтить условные гвозди, а дать лишь туманные намеки в тексте упражнения. Что, собственно, и происходит.
Занимаюсь самостоятельно чуть меньше года. По сути, в математику пришёл из прикладной криптографии. Изначально хотел въехать в мат.часть эллиптической криптографии, как минимум на уровень понимания актуальных публикаций по теме. Но начав читать попавшуюся литературу — жёстко разбился об порог вхождения. Постепенно начал спускаться к основам, сначала в конечные поля — не пошло, потом в абстрактную алгебру — та же история. В итоге пришёл в теорию чисел, и провёл там чуть больше полугода (в процессе даже снял и залил несколько роликов на ютубчик). На данный момент уже вернулся к абстрактной алгебре, где дела пошли гораздо лучше, чем в прошлый раз.
Чисто по своему опыту, в условиях вот такого самостоятельного освоения, очень многое (если не всё) зависит от правильно подобранной литературы, и как вы заметили в комментарии ниже — с этим есть некоторые проблемы. Мне с этим в принципе повезло, я достаточно быстро нашёл для себя идеальные варианты.
Ещё одна проблема — в необходимости решения упражнений. И это именно необходимость, а не опция. В большом количестве учебной литературы, упражнения — это примерно 30% хронометража (если не все 50), но, при этом, через упражнение подаётся примерно 80% контента книги. (исключительно по моим ощущениям, на объективность не претендую).
То есть если представить, что текст глав — это основной сюжет, а упражнения — это сайд квесты в условной РПГ, то основной сюжет здесь можно не напрягаясь пробежать за неделю, а в сайдах провести долгие месяцы. Идя по мейн квесту, авторы аккуратно ведут нас за руку, показывая лишь основы геймплея, а вся глубина и замысел раскрывается уже при прохождении побочек. И точно так же как в играх, это могут быть рутинные однообразные задания в стиле принеси-подай-убей, а могут быть полноценные истории, не уступающие по размаху основному сюжету, и это, в том числе, отличает хорошие книги от не очень хороших.
Но это я уже немного увлёкся аналогиями. А вообще с упражнениями у меня была проблема следующая — я долго не мог привыкнуть к тому что, на чтение главы уходит минут 10-15, а на решение упражнений к этой главе 2-3 дня (в среднем, тут, конечно, ещё зависит от наличия свободного времени). Но со временем втянулся, и упражнения стали казаться чем-то само собой разумеющимся, а процесс решения стал некой формой медитации. Тем более, что в моём случае упражнения были действительно интересными.
Ещё из интересных откровений — занятия математикой делают из меня лучшего программиста, чем, собственно, само программирование, на которое я начал смотреть уже немного под другим углом, но это уже другая история.
Согласен, мнение есть мнение. Но, повторюсь, что в моём понимании «настоящий» здесь едва ли имеет отношение к профессии. Интересно было бы услышать разъяснение автора по этому поводу :)
Там нет причинно-следственной связи в духе «я — настоящий программист, потому чтопрограммирую на разных языках».
Там есть отдельное заявление о том что «автор — настоящий», без указания профессии. То есть здесь автор даже не называет себя настоящим программистом, он называет себя настоящим, то есть живым/полезным.
А в следующем предложении автор описывает себя в сравнении с героем оригинальной статьи, просто обозначая свою профессию, и, так как она совпадает, инструменты с которыми ему приходилось работать. Просто констатация фактов, не более.
Всё это к тому, что обе статьи в принципе не про настоящих/ненастоящих программистов. Здесь "настоящий" приравнивается к "приносящий пользу обществу", и ни один из авторов не привязывает это к профессионализму.
Сертификация заключается в проверке соблюдения изготовителем требований к производству, наличия у него в штате нужного количества соответствующих специалистов, соответствия технической документации ГОСТам, а продукта — технической документации и т.д.
Вообще, по опыту, зависит от того что и на что сертифицируют. Если речь идёт о средствах хранения данных особой важности и/или криптографической защиты информации, то анализ исходного кода и устройства аппаратной части очень даже входит в программу сертификации.
А насколько этот анализ хорош, уже зависит от конкретного сертификатора, в частности, от принятой методики. Я встречался как с теми кто делает это чисто формально и с теми кто достаточно дотошно вычитывает тексты.
так тут же про геймдев вроде как..
Спасибо за статью! На самом деле ситуация крайне интересная, и очень хорошо перекликается с вопросом об ответственности за решения, принятые на основе "экспертных" рекомендаций от ИИ (буквально вчера обсуждали с коллегой).
И хотя мы обсуждали это в контексте разработки ПО, оправдания клиента, мол, "это не я дурак, это ии плохой", в некотором роде подтверждают мой тезис о том, что "вопрошающая" сторона будет пытаться всеми силами снимать с себя любую ответвенность за ошибки (хотя в налоговой уже такое не пройдём).
В глобальном плане, уже становится страшновато от того, что будущем, возможно, придётся работать с руководителями которые всю свою мыслительную деятельность будут делегировать чату. Но это я драмматизирую.
Всё же, наверное, автор имел ввиду не открытый мир как таковой, а открытую структуру самих уровней с очень большой, даже по сегодняшним меркам, вариативностью. Там буквально написано: "Тогда многих поразил один только дизайн открытых уровней", и лично для меня - это прямо в точку.
Я помню у меня был момент, когда при первом прохождении я полез в прохожение (в журнале ЛКИ), что бы перепроверить какие-то моменты, и примерно долистав до нужного места - я вообще не понял о чём идёт речь, потому что моё прохождение пошло
по одному меступо совешенно другому пути. Или вот более конкретный пример (под спойлером, потому что там довольно важный сюжетный момент):Скрытый текст
В моменте, когда на квартиру нашего братишки Пола налетают правительственные агенты, и он говорит нам бежать - мне даже в голову не пришло, что можно остаться. И это имеет очень сильное влияние на дальнейшее развитие событий.
И вот чисто в этом плане, MD, при своей, в целом, камерности, мне кажется ближе к оригиналу. HR - хорош, но вместо "свободного" геймплея первой части, она, в рамках уровня, как будто толкает игрока на вполне определённые "пути". Но это чисто моё субъективное. В любом случае очень жаль, что серия заглохла.
Почти - не считается :)
Но да, с подобным я, непосредственно, сталкивался на практике, когда на каком-то маленьком АRMе (к сожалению уже точно не помню, что конкретно там был за чип) каст байтового указателя, с адресом не кратным размеру слова, к указателю большего типа, с поледущим чтением из последнего, приводил к тому, что результат читался не из исходного адреса, а из ближайшего кратного. Иными словами:
Конкретно тот код изначально затачиваля под 32-битную Винду и MSVC, и корретно работал после портирования на десктопный Linux/GCC. А вот при портировании на этот АRМ, понадобилось проверять выравнивания исходных адресов (в местах, где мы не знаем этого изначально), и при необходимости, как Вы и сказали - кастить через буфер.
Поэтому да, всегда надо понимать что и к чему кастится, и особенно, если меньший тип к большему. В обратную сторону - чуть сложнее, но тоже можно нарваться на неприятности (если, конечно, делать это не специально).
Как отметил комментатор выше - в С++ это UB без исключений, но реализовано и работает в самых распространённых компиляторах.
В С - по идее могут быть приколы, если написать так:
Но даже в этом случае - они называют это "unspecified", а не "undefined", а это, насколько я понимаю, немного разные вещи.
Ну и справедливости ради, до вашего комментария, о том что тут в принципе где-то может UB до я и знать не знал :) Получается, что из этого вопрос можно вытянуть ещё больше, чем я думал.
Как сказал мой первый руководитель: "всё ваше программирование - это, в конце концов, всего лишь перекладывание данных из одной области памяти в другую" :)
Ну в целом со всем согласен, разве что бинарный поиск (и ему подобные) может быть уместен чисто как защита от дурака - тут не столько про алгоритмы, сколько проверить что человек вообще видел язык по которому собеседуется (хотя на сеньорском уровне это, вроде как, должно подразумеваться со старта).
Из вопросов такого плана у меня есть один очень хороший, по моему мнению, пример. Мне его впервые задали на техсобесе на сишника в московский Samsung, и хоть в Samsung я в итоге не пошёл (а пошёл в SK hynix), этот вопрос мне хорошо запомнился и я сам не раз его использовал.
Звучит примерно так: написать функцию/макрос, которая в рантайме проверяет порядок байт (endianness) на машине на которой этот код выполняется. Под спойлером (на случай если кто-то захочет проверить себя) - пара возможных решений (верхнее дал я сам):
Скрытый текст
Почему я считаю это вопрос хорошим? Потому что по ответу, вмещающемуся буквально в 3-4 строчки (или даже в одну), можно вполне себе адекватно оценить насколько кандидат понимает что-то в С. И дело здесь не в решении конкретной проблемы, "практичность" которой можно оспорить (хотя лично мне оно не раз пригождалось), а в понимании как оно вообще всё устроено
в этой жизни.StrongSwan VPN - https://docs.strongswan.org/docs/5.9/devs/objectOrientedC.html, там ещё сильнее заморочились в плане синтаксического сахара на макросах. При этом общую идею авторы взяли из xine. Вполне живая и рабочая схема на самом деле.
Жизнь - движение)
В тему внешних дедлайнов вспомнились Лайвлибовские книгомарафоны (на месяц) и книжные вызовы (на год).
Маккензи Дэвис ("Остановись и гори") прям вижу.
Маккензи Дэвис
Тащемта автор сказал об этом в самом начале статьи. Но я бы предположил, что автор описал самого себя.
Чисто по своему опыту, в условиях вот такого самостоятельного освоения, очень многое (если не всё) зависит от правильно подобранной литературы, и как вы заметили в комментарии ниже — с этим есть некоторые проблемы. Мне с этим в принципе повезло, я достаточно быстро нашёл для себя идеальные варианты.
Ещё одна проблема — в необходимости решения упражнений. И это именно необходимость, а не опция. В большом количестве учебной литературы, упражнения — это примерно 30% хронометража (если не все 50), но, при этом, через упражнение подаётся примерно 80% контента книги. (исключительно по моим ощущениям, на объективность не претендую).
То есть если представить, что текст глав — это основной сюжет, а упражнения — это сайд квесты в условной РПГ, то основной сюжет здесь можно не напрягаясь пробежать за неделю, а в сайдах провести долгие месяцы. Идя по мейн квесту, авторы аккуратно ведут нас за руку, показывая лишь основы геймплея, а вся глубина и замысел раскрывается уже при прохождении побочек. И точно так же как в играх, это могут быть рутинные однообразные задания в стиле принеси-подай-убей, а могут быть полноценные истории, не уступающие по размаху основному сюжету, и это, в том числе, отличает хорошие книги от не очень хороших.
Но это я уже немного увлёкся аналогиями. А вообще с упражнениями у меня была проблема следующая — я долго не мог привыкнуть к тому что, на чтение главы уходит минут 10-15, а на решение упражнений к этой главе 2-3 дня (в среднем, тут, конечно, ещё зависит от наличия свободного времени). Но со временем втянулся, и упражнения стали казаться чем-то само собой разумеющимся, а процесс решения стал некой формой медитации. Тем более, что в моём случае упражнения были действительно интересными.
Ещё из интересных откровений — занятия математикой делают из меня лучшего программиста, чем, собственно, само программирование, на которое я начал смотреть уже немного под другим углом, но это уже другая история.
В SICP этому посвящена третья глава (1979 год, на секундочку).
Там есть отдельное заявление о том что «автор — настоящий», без указания профессии. То есть здесь автор даже не называет себя настоящим программистом, он называет себя настоящим, то есть живым/полезным.
А в следующем предложении автор описывает себя в сравнении с героем оригинальной статьи, просто обозначая свою профессию, и, так как она совпадает, инструменты с которыми ему приходилось работать. Просто констатация фактов, не более.
Всё это к тому, что обе статьи в принципе не про настоящих/ненастоящих программистов. Здесь "настоящий" приравнивается к "приносящий пользу обществу", и ни один из авторов не привязывает это к профессионализму.
Вообще, по опыту, зависит от того что и на что сертифицируют. Если речь идёт о средствах хранения данных особой важности и/или криптографической защиты информации, то анализ исходного кода и устройства аппаратной части очень даже входит в программу сертификации.
А насколько этот анализ хорош, уже зависит от конкретного сертификатора, в частности, от принятой методики. Я встречался как с теми кто делает это чисто формально и с теми кто достаточно дотошно вычитывает тексты.