Ключевая особенность исключений - проброс их через функции, которые о них даже не подозревают, в отличие от какого-нибудь Result/expected типа. Эта же особенность делает исключения величайшим механизмом прострела ноги, ибо контроля времени компиляции на наличие соответствующих catch блоков нету и быть не может. В хоть сколько-нибудь значимых программах с требованиями к надёжности поэтому исключения категорически нельзя использовать. А таких программ подавляющее большинство, за исключением разве что простейших скриптов не более одного экрана размером.
Каждый раз, пытаясь разобраться в этом алгоритме, понимаю, что это СЛОЖНА и забиваю. В обычных условиях поиск подстроки в строке и так достаточно быстрый, чтобы упражняться в хитромудрых алгоритмах, придуманных в древности седовласыми мудрецами. Мой Grug мозг больше склоняется к простым, но понятным, а в значительном количестве случаев более быстрым решениям.
Самый простой и понятный способ ускорить - сравнивать сразу первые 4-8 символов за раз, храня их в единственной переменной и используя хитрости битовых сдвигов. Это позволяет отфильтровать подавляющее большинство случаев, когда вхождение подстроки не найдено.
Ещё один подход - скользящее окно с XOR символов. Если этот XOR совпадает с таковым для искомой строки - можно проводить более детальное сравнение, которое в отличие от XOR учитывает порядок символов. На практике это тоже позволяет находить подстроку достаточно эффективно, т. к. совпадение XOR при несовпадении строки - достаточно редко. Дополнительно можно комбинировать этот подход с предыдущим.
Вся соль, как я понял, в компиляторе Go, который вставляет информацию о типах, которая во многом схожа с отладочной информацией. С другими языками так бы не прокатило.
Сам недавно экспериментировал с процедурной графикой, вдохновившись отчасти предыдущим постом автора. Вот пара моих работ: https://www.youtube.com/watch?v=i6kyKoq0MWg https://www.youtube.com/watch?v=lwn4BQNNSTA Написано это под Windows с целевым размером 4 килобайта. Ассемблер в таких условиях уже не сильно нужен, поэтому написано на C++.
Теория противовеса плоха ещё и тем, что собственно говоря пирамида для него не нужна. Можно же трос распустить на жилы и каждую из них через какой-нибудь анкер закрепить в скальном основании. Это менее трудоёмкий процесс, чем строительство отдельного противовеса. Нечто схожее делается с подвесными/вантовыми мостами - концы тросов на берегах в земле закрепляют.
Для древних людей пирамида - тоже чисто утилитарное сооружение. Это ведь последнее пристанище фараона, который является натуральным богом. Если он разгневается, может всякое нехорошее случиться, вроде засухи. Вообще, религия штука чисто утилитарна. Рядовой верующий совершает всякие обряды, цель которых - сделать приятное какому-нибудь богу/святому, чтобы тот в ответ тоже что-то хорошее сделал.
Похвалю игры серии Brothers in Arms за историческую достоверность. Откровенного бреда и отсебятины там нету, игровые локации основаны на реальных местах, в игре воссоздана реальная тактика американских парашютистов и даже имена героев соответствуют реальным бойцам, принимавшим участие в описываемых событиях.
Если всё использование сводится к просмотру котиков - то проблем особых нету.
Если мессенджер используется для обмена персональными сообщениями - уже могут быть проблемы, если переписка будет доступна кому-то ещё, чего без сквозного шифрования исключать нельзя. Кому будет приятно осознавать, что переписку с женой (например) могут читать модераторы мессенджера или другие люди с доступом?
Ещё больше проблем, если использовать мессенджер для доступа к (скажем так) неодобряемой информации. А нынче такой неодобряемой информации полно - посты иногентов, информация о трёхбуквенной технологии обхода блокировок и т. д. В настоящем или скором будущем один лишь факт того, что кто-то такую информацию получал, может плохо сказаться.
На счёт покупок проблема аналогичная. Третьи лица могут получить доступ к платёжным данным. А если они защищены, то как минимум могут стать известны купленные товары, что опять же для кого-то может быть проблематично, если товары были вроде бы и законные, но социально-неодобряемые.
А зачем raycast? Это же (мягко говоря) не очень быстрый способ рендеринга. Почему не растеризация? Растеризацией можно рисовать хоть в FullHD и уменьшат разрешение картинки до размеров окна консоли, тем самым добиваясь некоторого сглаживания.
Какая может быть безопасность с мессенджером, требующим ему отдать номер телефона? Не было и нету там никакой безопасности, а обратные утверждения - лишь нечестный маркетинг.
Используйте альтернативы, не требующие никаких персональных данных для регистрации, не хранящие историю переписки на серверах и (естественно) с полным шифрованием.
На самом деле начинание хорошее - не вызывать Ктулху UB из-за неинициализированной int переменной. Но лучше всё-же включить все какие можно предупреждения компилятора и желательно также статического анализатора, чтобы отловить большую часть таких случаев.
Описанная в статье проблема, вообще говоря, заключается не в наличии в системе компилятора полноценного языка программирования, а в самом механизме работы Windows. Там любая пользовательская программа может делать очень многое даже без прав администратора - читать и писать пользовательские файлы, лезть в интернет (ну или не совсем, смотря как Brandmauer настроен), создавать окна, в т. ч. полноэкранные, и даже как показано в данной статье выключать компьютер.
На популярных дистрибутивах GNU/Linux ситуация аналогична, кстати говоря. Без прав root всё ещё много чего можно делать.
По-хорошему это должно быть кардинально пересмотрено - чтобы какой-то непонятный exe имел минимум прав, вроде запрета на чтения пользовательских файлов, создания файлов вообще, выхода в интернет и вообще какого-либо взаимодействия с системой кроме создания не более одного окна. Потребление ресурсов тоже должно быть лимитировано - память/процессорное время. Для нормальных программ (которые устанавливают) в каком-нибудь манифесте должен быть прописан набор разрешений, при чём некоторые из них могут быть принципиально несовместимыми (вроде доступа в интернет и чтения произвольных файлов). В этом нет ничего нового, мобильные ОС уже давно имеют такую систему прав.
К сожалению эти пожелания так и останутся таковыми, ибо ради обратной совместимости в Windows уже ничего не будут менять. Если начать вводить какие-либо новые ограничения, то значительное количество существующих программ сломаются.
А с какой целью полноценный компилятор C# ставится вместе с библиотеками .NET? Просто на всякий случай? Или же сами эти библиотеки нуждаются в этом компиляторе, например, для JIT-компиляции кода?
На самом деле закономерно. Генерация бредовых, ну или отдалённо похожих на правду, но всё равно бредовых текстов не может иметь никакого полезного применения. Все случаи использования подобных больших языковых моделей лежат по ту сторону морали - спам, чёрный SEO, экономия на техподдержке, мошенничество и т. д.
Правильно ли я понимаю, что если идти в анализе дальше, то по сути можно дойти уже до некой виртуальной машины, которая интерпретирует входной код и ищет в процессе ошибки?
Нет ли тут аналогии с антивирусами, которые в процессе анализа вирусов дошли до интерпретации их кода, чтобы оценить его результата?
Я уже более чем 8 лет разрабатываю свой язык программирования. При этом ужасным я бы его не назвал, даже наоборот - я его отточил до весьма приятного в использовании состояния и реализовал язык настолько безопасным, насколько это возможно.
Поначалу правда он действительно красотою и удобством не блистал, но со временем я всё больше его улучшал. Сейчас по ряду аспектов он может уделать многие существующие общеупотребительные языки.
Сортировать члены кортеже - так себе идея. Кому надо, тот изначально отсортирует, а остальным же такая сортировка может создать неожиданности в отладке.
Объясните мне, зачем Youtube пытаются "блокировать" именно таким способом, который достаточно просто обойти? Почему не делают как со многими другими сайтами, которые просто по доменному имени заблокировали. Нет-ли тут какого-то скрытого умысла?
Ключевая особенность исключений - проброс их через функции, которые о них даже не подозревают, в отличие от какого-нибудь Result/expected типа. Эта же особенность делает исключения величайшим механизмом прострела ноги, ибо контроля времени компиляции на наличие соответствующих catch блоков нету и быть не может.
В хоть сколько-нибудь значимых программах с требованиями к надёжности поэтому исключения категорически нельзя использовать. А таких программ подавляющее большинство, за исключением разве что простейших скриптов не более одного экрана размером.
Каждый раз, пытаясь разобраться в этом алгоритме, понимаю, что это СЛОЖНА и забиваю.
В обычных условиях поиск подстроки в строке и так достаточно быстрый, чтобы упражняться в хитромудрых алгоритмах, придуманных в древности седовласыми мудрецами. Мой Grug мозг больше склоняется к простым, но понятным, а в значительном количестве случаев более быстрым решениям.
Самый простой и понятный способ ускорить - сравнивать сразу первые 4-8 символов за раз, храня их в единственной переменной и используя хитрости битовых сдвигов. Это позволяет отфильтровать подавляющее большинство случаев, когда вхождение подстроки не найдено.
Ещё один подход - скользящее окно с XOR символов. Если этот XOR совпадает с таковым для искомой строки - можно проводить более детальное сравнение, которое в отличие от XOR учитывает порядок символов. На практике это тоже позволяет находить подстроку достаточно эффективно, т. к. совпадение XOR при несовпадении строки - достаточно редко. Дополнительно можно комбинировать этот подход с предыдущим.
Вся соль, как я понял, в компиляторе Go, который вставляет информацию о типах, которая во многом схожа с отладочной информацией. С другими языками так бы не прокатило.
Сам недавно экспериментировал с процедурной графикой, вдохновившись отчасти предыдущим постом автора. Вот пара моих работ:
https://www.youtube.com/watch?v=i6kyKoq0MWg
https://www.youtube.com/watch?v=lwn4BQNNSTA
Написано это под Windows с целевым размером 4 килобайта. Ассемблер в таких условиях уже не сильно нужен, поэтому написано на C++.
Теория противовеса плоха ещё и тем, что собственно говоря пирамида для него не нужна. Можно же трос распустить на жилы и каждую из них через какой-нибудь анкер закрепить в скальном основании. Это менее трудоёмкий процесс, чем строительство отдельного противовеса.
Нечто схожее делается с подвесными/вантовыми мостами - концы тросов на берегах в земле закрепляют.
Для древних людей пирамида - тоже чисто утилитарное сооружение. Это ведь последнее пристанище фараона, который является натуральным богом. Если он разгневается, может всякое нехорошее случиться, вроде засухи.
Вообще, религия штука чисто утилитарна. Рядовой верующий совершает всякие обряды, цель которых - сделать приятное какому-нибудь богу/святому, чтобы тот в ответ тоже что-то хорошее сделал.
Интересно, но есть более продвинутые/функциональные модели:
https://www.youtube.com/watch?v=zrUWSfd0Heg
Похвалю игры серии Brothers in Arms за историческую достоверность. Откровенного бреда и отсебятины там нету, игровые локации основаны на реальных местах, в игре воссоздана реальная тактика американских парашютистов и даже имена героев соответствуют реальным бойцам, принимавшим участие в описываемых событиях.
Если всё использование сводится к просмотру котиков - то проблем особых нету.
Если мессенджер используется для обмена персональными сообщениями - уже могут быть проблемы, если переписка будет доступна кому-то ещё, чего без сквозного шифрования исключать нельзя. Кому будет приятно осознавать, что переписку с женой (например) могут читать модераторы мессенджера или другие люди с доступом?
Ещё больше проблем, если использовать мессенджер для доступа к (скажем так) неодобряемой информации. А нынче такой неодобряемой информации полно - посты иногентов, информация о трёхбуквенной технологии обхода блокировок и т. д. В настоящем или скором будущем один лишь факт того, что кто-то такую информацию получал, может плохо сказаться.
На счёт покупок проблема аналогичная. Третьи лица могут получить доступ к платёжным данным. А если они защищены, то как минимум могут стать известны купленные товары, что опять же для кого-то может быть проблематично, если товары были вроде бы и законные, но социально-неодобряемые.
А зачем raycast? Это же (мягко говоря) не очень быстрый способ рендеринга. Почему не растеризация? Растеризацией можно рисовать хоть в FullHD и уменьшат разрешение картинки до размеров окна консоли, тем самым добиваясь некоторого сглаживания.
Какая может быть безопасность с мессенджером, требующим ему отдать номер телефона? Не было и нету там никакой безопасности, а обратные утверждения - лишь нечестный маркетинг.
Используйте альтернативы, не требующие никаких персональных данных для регистрации, не хранящие историю переписки на серверах и (естественно) с полным шифрованием.
На самом деле начинание хорошее - не вызывать
КтулхуUB из-за неинициализированной int переменной. Но лучше всё-же включить все какие можно предупреждения компилятора и желательно также статического анализатора, чтобы отловить большую часть таких случаев.Описанная в статье проблема, вообще говоря, заключается не в наличии в системе компилятора полноценного языка программирования, а в самом механизме работы Windows. Там любая пользовательская программа может делать очень многое даже без прав администратора - читать и писать пользовательские файлы, лезть в интернет (ну или не совсем, смотря как Brandmauer настроен), создавать окна, в т. ч. полноэкранные, и даже как показано в данной статье выключать компьютер.
На популярных дистрибутивах GNU/Linux ситуация аналогична, кстати говоря. Без прав root всё ещё много чего можно делать.
По-хорошему это должно быть кардинально пересмотрено - чтобы какой-то непонятный exe имел минимум прав, вроде запрета на чтения пользовательских файлов, создания файлов вообще, выхода в интернет и вообще какого-либо взаимодействия с системой кроме создания не более одного окна. Потребление ресурсов тоже должно быть лимитировано - память/процессорное время.
Для нормальных программ (которые устанавливают) в каком-нибудь манифесте должен быть прописан набор разрешений, при чём некоторые из них могут быть принципиально несовместимыми (вроде доступа в интернет и чтения произвольных файлов). В этом нет ничего нового, мобильные ОС уже давно имеют такую систему прав.
К сожалению эти пожелания так и останутся таковыми, ибо ради обратной совместимости в Windows уже ничего не будут менять. Если начать вводить какие-либо новые ограничения, то значительное количество существующих программ сломаются.
А с какой целью полноценный компилятор C# ставится вместе с библиотеками .NET? Просто на всякий случай? Или же сами эти библиотеки нуждаются в этом компиляторе, например, для JIT-компиляции кода?
На самом деле закономерно. Генерация бредовых, ну или отдалённо похожих на правду, но всё равно бредовых текстов не может иметь никакого полезного применения. Все случаи использования подобных больших языковых моделей лежат по ту сторону морали - спам, чёрный SEO, экономия на техподдержке, мошенничество и т. д.
Давно уже. У меня в том числе и на Хабре есть публикации по нему.
Компилятор доступен на моём github.
Правильно ли я понимаю, что если идти в анализе дальше, то по сути можно дойти уже до некой виртуальной машины, которая интерпретирует входной код и ищет в процессе ошибки?
Нет ли тут аналогии с антивирусами, которые в процессе анализа вирусов дошли до интерпретации их кода, чтобы оценить его результата?
Я уже более чем 8 лет разрабатываю свой язык программирования. При этом ужасным я бы его не назвал, даже наоборот - я его отточил до весьма приятного в использовании состояния и реализовал язык настолько безопасным, насколько это возможно.
Поначалу правда он действительно красотою и удобством не блистал, но со временем я всё больше его улучшал. Сейчас по ряду аспектов он может уделать многие существующие общеупотребительные языки.
Сортировать члены кортеже - так себе идея. Кому надо, тот изначально отсортирует, а остальным же такая сортировка может создать неожиданности в отладке.
Объясните мне, зачем Youtube пытаются "блокировать" именно таким способом, который достаточно просто обойти? Почему не делают как со многими другими сайтами, которые просто по доменному имени заблокировали. Нет-ли тут какого-то скрытого умысла?