Извечный философский вопрос: что свободнее: BSD или GPL? =) А вообще, архитектура LLVM - это супер, в плане трансляции язый->IR->машинный код т.е. для нового языка надо написать только транслятор в этот Intermediate representation (взрыв мозга!), а дальше уже есть компиляторы. То же самое для нового процессора, только надо дописать компилятор для IR. Update: Нашёл видео "LLVM IR training at Intel (in Russian)" на вашем канале которое гораздо лучше на все вопросы отвечает чем я мог бы мечтать =)
Если один и тот же BB несколько раз вставить в функцию, последствия будут фееричными. Представь как ты меняешь одну часть функции, а одновременно меняется и другая. С одной и той же функцией в нескольких модулях ещё веселее - ты построил два модуля, соптимизировал один, перешёл к другому, а там функция уже соптизированная. Такое извращение точно не является common practice, и BB и функции здесь ничем не отличаются от инструкций.
А могут ли отключить процессоры или процессор который выполняет какой то код, который нельзя обнаружить? Есть ли аппаратные "закладки" в процессорах, есть ли например у нас в стране компании, которые ищут эти "закладки"? И например ещё вопрос про передачу по сети, тоже ведь в самом шифровании могут быть "закладки", замаскировано под случайный шум могут зашифровать какую-то полезную информацию и как это выяснить и распознать её, занимается ли кто-то этим?
Вы думаете, наверное, что есть железо и оно чем-то принципиально отличается от софта. Но это не так. Нет никакого железа. Это тоже софт, просто на другом языке (Verilog, VHDL, ...). И относится к нему надо так же -- свободный он или нет. Если железо свободное (например RISC V к этому близок), то уверенность, что там ничего такого нет, у вас есть. Если нет, то у вас и уверенности быть не может.
@@tilir спасибо за ответ. Получается, что зная и смотря на процессор со стороны его разработчика можно многое предположить как он устроен, так как скорее всего для его разработки использовался один и тот же софт? Я понимаю, что это примерно одно и тоже, но только если обычную опенсорс программу можно проверить обладая необходимыми компетенциями, то с процессорам даже risc-v все сложнее, как убедится, что он сделан именно по этой архитектуре и производитель ничего не добавил от себя? Хотя я также предполагаю, что особой экономической выгоды и необходимости в этом нет, когда весь вредоносный код итак без проблем можно заложить в обычное ПО, вот даже сейчас пишу сообщение с клавиатуры Гугл и впринципе зачем изобретать сложный велосипед, если итак этой клавиатурой пользуются большинство, но что если все общество эволюционирует до уровня программистов, тогда уже возможно появится и в этом экономический смысл)
@@kychkin_nikolay а как по вашему ищут баги в физдизайне? Если вы знаете логическое описание на уровне RTL, то задача убедиться что железка ему соответствует это просто задача silicon validation. Человечество это умеет. А вот если RTL у вас нет, тогда опаньки.
std::filesystem::directory_iterator - меня такие конструкции в глубине души пугают. Казалось бы, это же просто directory_iterator лежащий в неймспейсе, чего бояться? Я понял, что источник моего страха в том, что неймспейсы не могут быть приватными, то есть невозможно понять, к публичному api ты обращаешься или ко внутреннему. Вроде бы такие вещи должны быть указаны в документации к api, но, обычно в документации просто рассказывают про интерфейс, методом перечисления. А про то, чем пользоваться нельзя - молчат, что логично, внутреннее api "палить" не принято. Вот и думаешь, то чем ты пользуешься, внутренности библиотеки или про эту сущность просто в доке забыли рассказать. Я слышал рассказы про модули и как они спасут мир, но, будем честны, львиная часть кода написана не на них, а жить нужно сейчас
Почему бы на нынешнем этапе не сделать какой то хак типа GoodValue и всем новым классам наследоваться от него, а там уже виртуальный деструктор P.S. проблема на самом деле в виртуальных функциях, они устарели сами
@@tilir Виртуальные функции на самом деле нужны в редких сценариях, но т.к. не было других инструментов в языке, то пользовались ими. Они в большинстве случаев превращают код в очень страшные конструкции из наследований, мемори менеджмента, случайных "срезок" до базы и забытого виртуального деструктора. Говоря по философски - они не отражают в коде реальных намерений программиста. И они потрясающе плохо подходят для ситуаций где нужен полиморфный объект. Постепенно придумали техники type erase, сначала была пробная std::function, с проблемами по части мув онли объектов и прочего, дальше пошёл std::any(почти абсолютно бесполезный в нынешнем виде) и variant, который хоть и хорош, но опять же куча ситуаций где он плох + дикие проблемы с исключениями. Сейчас в стандарт предлагается std::proxy, вам в личку скину проект который я предлагаю для решения этих проблем(тут забанит за ссылку). Вкратце там развитие идеи any, только гораздо более юзабельное и с дополнительными фичами
19:43 - но ведь мы можем дергать callback при realloc'е, если зададим какой-нибудь хитрый аллокатор) правда есть подозрение что это сделает код только хуже
Извечный философский вопрос: что свободнее: BSD или GPL? =) А вообще, архитектура LLVM - это супер, в плане трансляции язый->IR->машинный код т.е. для нового языка надо написать только транслятор в этот Intermediate representation (взрыв мозга!), а дальше уже есть компиляторы. То же самое для нового процессора, только надо дописать компилятор для IR. Update: Нашёл видео "LLVM IR training at Intel (in Russian)" на вашем канале которое гораздо лучше на все вопросы отвечает чем я мог бы мечтать =)
16:03 ошибка на слайде: std::advance возвращает void, а итератор принимает первым аргументов по ссылке
Если один и тот же BB несколько раз вставить в функцию, последствия будут фееричными. Представь как ты меняешь одну часть функции, а одновременно меняется и другая. С одной и той же функцией в нескольких модулях ещё веселее - ты построил два модуля, соптимизировал один, перешёл к другому, а там функция уже соптизированная. Такое извращение точно не является common practice, и BB и функции здесь ничем не отличаются от инструкций.
Да, спасибо, это важное замечание. Я немного заговорился =)
лекция как всегда изумительна. большое спасибо вам за ваши труды
А могут ли отключить процессоры или процессор который выполняет какой то код, который нельзя обнаружить? Есть ли аппаратные "закладки" в процессорах, есть ли например у нас в стране компании, которые ищут эти "закладки"? И например ещё вопрос про передачу по сети, тоже ведь в самом шифровании могут быть "закладки", замаскировано под случайный шум могут зашифровать какую-то полезную информацию и как это выяснить и распознать её, занимается ли кто-то этим?
Вы думаете, наверное, что есть железо и оно чем-то принципиально отличается от софта. Но это не так. Нет никакого железа. Это тоже софт, просто на другом языке (Verilog, VHDL, ...). И относится к нему надо так же -- свободный он или нет. Если железо свободное (например RISC V к этому близок), то уверенность, что там ничего такого нет, у вас есть. Если нет, то у вас и уверенности быть не может.
@@tilir спасибо за ответ. Получается, что зная и смотря на процессор со стороны его разработчика можно многое предположить как он устроен, так как скорее всего для его разработки использовался один и тот же софт? Я понимаю, что это примерно одно и тоже, но только если обычную опенсорс программу можно проверить обладая необходимыми компетенциями, то с процессорам даже risc-v все сложнее, как убедится, что он сделан именно по этой архитектуре и производитель ничего не добавил от себя? Хотя я также предполагаю, что особой экономической выгоды и необходимости в этом нет, когда весь вредоносный код итак без проблем можно заложить в обычное ПО, вот даже сейчас пишу сообщение с клавиатуры Гугл и впринципе зачем изобретать сложный велосипед, если итак этой клавиатурой пользуются большинство, но что если все общество эволюционирует до уровня программистов, тогда уже возможно появится и в этом экономический смысл)
@@kychkin_nikolay а как по вашему ищут баги в физдизайне? Если вы знаете логическое описание на уровне RTL, то задача убедиться что железка ему соответствует это просто задача silicon validation. Человечество это умеет. А вот если RTL у вас нет, тогда опаньки.
std::filesystem::directory_iterator - меня такие конструкции в глубине души пугают.
Казалось бы, это же просто directory_iterator лежащий в неймспейсе, чего бояться? Я понял, что источник моего страха в том, что неймспейсы не могут быть приватными, то есть невозможно понять, к публичному api ты обращаешься или ко внутреннему.
Вроде бы такие вещи должны быть указаны в документации к api, но, обычно в документации просто рассказывают про интерфейс, методом перечисления. А про то, чем пользоваться нельзя - молчат, что логично, внутреннее api "палить" не принято.
Вот и думаешь, то чем ты пользуешься, внутренности библиотеки или про эту сущность просто в доке забыли рассказать.
Я слышал рассказы про модули и как они спасут мир, но, будем честны, львиная часть кода написана не на них, а жить нужно сейчас
Обычно называют говоряще, вроде namespace detail.
@@tilir да, я помню, на лекции вы рассказывали
Почему бы на нынешнем этапе не сделать какой то хак типа GoodValue и всем новым классам наследоваться от него, а там уже виртуальный деструктор
P.S. проблема на самом деле в виртуальных функциях, они устарели сами
Разверните мысль про устаревшие виртуальные функции. Что взамен?
@@tilir Виртуальные функции на самом деле нужны в редких сценариях, но т.к. не было других инструментов в языке, то пользовались ими. Они в большинстве случаев превращают код в очень страшные конструкции из наследований, мемори менеджмента, случайных "срезок" до базы и забытого виртуального деструктора. Говоря по философски - они не отражают в коде реальных намерений программиста. И они потрясающе плохо подходят для ситуаций где нужен полиморфный объект. Постепенно придумали техники type erase, сначала была пробная std::function, с проблемами по части мув онли объектов и прочего, дальше пошёл std::any(почти абсолютно бесполезный в нынешнем виде) и variant, который хоть и хорош, но опять же куча ситуаций где он плох + дикие проблемы с исключениями.
Сейчас в стандарт предлагается std::proxy, вам в личку скину проект который я предлагаю для решения этих проблем(тут забанит за ссылку).
Вкратце там развитие идеи any, только гораздо более юзабельное и с дополнительными фичами
@@niklkelbon3662 можно в Дискорд ссылку кинуть.
@@niklkelbon3662 мне тоже интересно глянуть на проект.
@@pdawniksem на гитхабе ник kelbon название репозитория AnyAny, как же бесит этот ютуб с удалением всего даже отдалённо похожего на ссылку
19:43 - но ведь мы можем дергать callback при realloc'е, если зададим какой-нибудь хитрый аллокатор) правда есть подозрение что это сделает код только хуже
Realloc не различает что он выделяет. К тому же это C API. Вы можете задать обработчик new, но там те же проблемы.