Вот именно то, что perl не меняется десятилетиями и при этом есть везде - и подкупает.
Да, изначальный синтаксис придумывали люди с более высоким IQ, чем у нынешних поколений - потому что это была эпоха, когда программист не мог назвать себя программистом, если не умел хоть немного писать в машинных кодах.
Но ведь не обязательно держать в голове все умолчания и сокращения, можно писать подробно.
И тут возникает вопрос: если ловить это исключение на самом высоком уровне (или позволить программе грохнуться) - контекст, объясняющий ЗАЧЕМ этот файл пытались открыть - будет потерян.
Мы его хотели создать? Прочитать? Что это вообще за файл, почему - возможно, не надо этот файл создавать, чтобы программа работала нормально - возможно, его имя указано неверно в конфигурации.
А если ловить на уровень выше - то получается точно то же самое, как обрабатывать возвращаемое значение.
В общем и целом: идея исключений была: "пишем код, не заморачиваясь обработкой ошибок по месту - которая резко снижает читаемость/понимаемость кода - и обрабатываем все ошибки уже после алгоритма, в блоке catch" - а по факту получилось, что выигрыша (для читабельности/удобства) - нет, если мы хотим более-менее вменяемые сообщения о ошибках.
Концепция исключений, как таковых - она изначально (когда её придумывали, наверно, уже лет 30 назад) казалась удобной и разумной - но на практике оказалась неудобной и неразумной, не считая одного или двух случаев.
Основная проблема с идеологией try/catch - она состоит в том, что к тому времени, как мы исключение обрабатываем - мы полностью потеряли контекст, в котором оно возникло.
Примеры с одним-двумя выражениями в блоке try() - они на самом деле бессмысленные, так как технически ничем не лучше "давайте обработаем ошибку прямо тут".
А когда у вас в блоке кода 3-5 мест, где может быть выброшено исключение одного и того же типа (например, мы открываем на чтение два файла, и третий - на запись, и каждый из них может не существовать или быть недоступен) - нам надо или принудительно сохранять контекст, или мы этот контекст потеряем.
Так что я в своё коде пришёл единственному разумному подходу: не генерируют исключений, формирую сообщение о ошибке и возвращаю "неудача".
Для С++ это выглядит как:
bool some_func(... , std::string & a_err);
В других языках - можно возвращать пару (реальный результат и сообщение о ошибке).
В моём коде прямо при выполнении каждого действий или проверке - в случае неудачи, формируется сообщение о ошибке, включающее весь нужный контекст. Потому что именно там этот контекст и есть.
Код уровнем выше может дополнить сообщение о ошибке. Например, функция проверки контрольной суммы файла может вернуть "файла нет/нет записи контрольной суммы/сумма неверна" - а уровнем выше, добавить - почему именно в этом файле должна быть контрольная сумма.
Чтобы пользователь не задавал мне идиотских вопросов "почему твоя программа валится с исключением, которое мне ничего не говорит?"
Да, можно кидать исключение со сформированным сообщением о ошибке - но это:
а) ничем не проще, чем сделать return false
b) если в коде несколько вызовов, чтобы добавить к ним контекст - придётся каждый окружать блоком try/catch. Это чисто физуально будет больше кода, чем просто:
if (! some_func(...,a_err))
{
a_error = "Additional context, failed: " + a_err;
return false;
}
Аж на две скобки меньше
======================
А когда использование исключений реально полезно? А в тех же (редких) случаях, когда раньше в языке С использовали longjump.
Лично я вижу только два применения
а) легитимно, в модульных тестах - вместо фатального завершения при срабатывании halt() или verify() (макросы, активно используемые в защитном программировании, штатно выдающие сообщение на консоль и завершающие с помощью abort()) - кинуть исключение и перехватить его в тесте. Удобно тестировать наличие/срабатывание проверок защитного программирования.
б) хак. Современные линуксы позволяют выполнять throw из сингальных хандлеров (хотя и не гарантируют). Можно выйти из зациклившегося алгоритма по SIGALARM.
Компилятор не удалял массив. Он сохранял его в исполняемом файле в компактном виде, в виде алгоритма, который генерировал его в оперативной памяти при старте программы.
Компилятор может не только код отомтимизировать, но и память.
Я в своё время сражался с llvm, пытаясь убедить его оставить в экзешнике крупный массив байт (в готовый экзешник в этот массив записывалась дополнительная информация).
gcc в такой ситуации достаточно было массив инициализировать, хотя бы не полностью - а llvm отследил варианты предсказуемой инициализации массива (например, константой отличной от нуля) и массив из экзешника выпиливал. Создавал динамически, на этапе инициализации.
Пришлось инициализировать массив сложной последовательностью, так чтобы компилятор не догадался, как её можно сгенерировать.
Вообще-то это ничего не значит. Ядро Линукс тоже на С написано. Что, из-за этого С++ не пользоваться?
Под современные микроконтроллеры спокойно можно писать на С++, т.к. clang и gcc пофиг, что преобразовывать в машинный код.
И да, при желании - с использованием урезанной стандартной библиотеки (без ввода/вывода), т.е. запросто можете пользоваться std::map и std::string. Если это удобно разработчику.
Да, надо иметь в виду, что использование динамической памяти на микроконтроллере - может привести к неожиданным результатам, но при грамотном использовании - более чем полезно.
А использовать проверенную десятилетиями связку flex+bison было слишком страшно?
Это ведь идеальная задача для парсера и грамматики.
Учитывая, что судя по вашему описанию - ваша утилита будет глючить на
комментариях, содержащих фигурные скобки
строковых литералах, содержащих фигурные скобки
символьных литералах, содержащих фигурные скобки
В общем, советую переделать по-взрослому.
Кстати, если немного подумаете - то сможете не просто проверочную утилиту реализовать, а реализовать утилиту, которая автоматом будет вставлять эти комментарии.
Ну да. Причём по его комментарию - ничего там особенного нет.
Фактически Столлмен возражал против того, что секс с 17-летней девкой, которая этим занимается профессионально (что тоже нарушает закон, и Столлмен это не отрицал) - описывали в терминах, создающих впечатление о изнасиловании несовершеннолетней лет так 12. Или 5.
Основная проблема с программированием в настоящее время - это то, что процентов 90, а может быть - 95 программистов занимаются полной хренью, которая по большому счёту нафиг никому не нужна и будет выкинута и забыта через полгода после окончания работы.
Миллионный раз делают те же самые окошки. Только полупрозрачные и с закруглёнными углами. Или формочки. Или тупую "бизнес-логику". Или очередной супердинамический сайт на модном фреймворке. Или очередную версию "офисного пакета".
В общем и целом - 90% усилий уходит в абсолютное НИ-КУ-ДА.
Не потому, что программисты такие глупыи или злонамеренные.
А потому, что современный бизнес, ориентированный на прибыль - требует именно этого.
Частично это - желание менеджеров найти оправдание существованию своих отделов. Ведь если вся работа сделана и осталась только поддержка и исправление редких багов - финансирование придётся сократить.
Частично - желание программистов, занимающихся тупой хренью типа впихивания контекстной рекламы - использовать какой-нибудь модный подход или новый язык. Или самим сделать новый фреймворк. Или перейти на новый фреймворк. Или переделать всё на микросервисы, при этом каждый - на своём языке.
Если так подумать - существенная часть умственного ресурса цивилизации сливается в унитаз. На разработку очередного "тапающего хомяка", например.
В общем, что и ожидалось. Вы можете сделать систему ИИ, которая демонстрирует сложное и вроде бы разумное поведение - но не можете реально оценить, не будет ли в этом поведении странных неожиданных сбоев.
Тут одно из двух: или простые, полностью понятные человеку алгоритмы - или вот так.
Извините конечно, но библиотеку работы с памятью, устойчивой к фрагментации, я видел лет так 20 назад. Точнее, доки к ней.
Кратко: при выделении небольших блоков памяти, они выделяются как часть ранее выделенной странице. Т.е. страница, хранящая блоки до 8 байт длиной, до 16 байт, до 32, до 64, до 128 и так далее. И этот подход отлично работает.
Неужели эта проблема до сих пор актуальна хотя где-то?
Глубина стека - всего 16 элементов? Тут же в рекурсии в любой момент времени уменьшается или n, или m - значит, в любой момент времени глубина стека не более n+m.
Такая задача может по времени обламываться, т.к. без кэширования результатов "дерево" получается очень широкое.
Конкретно для этой задаче - не проще сделать мэп с [m,n] -> value, и если в мэпе уже есть значение - возвращать его, а если нет - вызываться рекурсивно?
Грозоразрядник. Если к вашему дому подведена воздушная/наземная проводка, где-то (обычно в коробке снаружи) устанавливается грозоразрядник.
Наведённое (молнией) высокое напряжение в проводе или (для проводов с экраном) в экране, нужно разрядить на землю. При этом, разумеется, слышен щелчок разряда - который физически происходит куда ближе к вам, и вы его слышите почти одновременно с ударом молнии.
Я пару раз дежурил на ж.д. станциях в помещении дежурного по станции, где грозоразрядник (по-моему, на антенну поездной радиосвязи) был установлен в помещении внутри. Разряд внутри помещения и молния снаружи были почти синхронны, по крайней мере я разницы не заметил.
Вот именно то, что perl не меняется десятилетиями и при этом есть везде - и подкупает.
Да, изначальный синтаксис придумывали люди с более высоким IQ, чем у нынешних поколений - потому что это была эпоха, когда программист не мог назвать себя программистом, если не умел хоть немного писать в машинных кодах.
Но ведь не обязательно держать в голове все умолчания и сокращения, можно писать подробно.
Не беспокойтесь, проблема уже решена автоматически.
Большую часть контента в сети уже генерируют боты.
Соответственно, как бы не исхитрялись владельцы ИИ - обучаться им будет нечем, так как обучение на сгенерированном контенте приводит к маразму ИИ.
Разумеется, может! ИИ может делать обзорные статьи и выжимки.
Читать только их должен будет тоже ИИ, впрочем как и писать эти самые исходные статьи и выжимки.
Тогда круг успешно замкнётся, и человечество наконец-то сможет перестать заниматься ерундой.
И тут возникает вопрос: если ловить это исключение на самом высоком уровне (или позволить программе грохнуться) - контекст, объясняющий ЗАЧЕМ этот файл пытались открыть - будет потерян.
Мы его хотели создать? Прочитать? Что это вообще за файл, почему - возможно, не надо этот файл создавать, чтобы программа работала нормально - возможно, его имя указано неверно в конфигурации.
А если ловить на уровень выше - то получается точно то же самое, как обрабатывать возвращаемое значение.
В общем и целом: идея исключений была: "пишем код, не заморачиваясь обработкой ошибок по месту - которая резко снижает читаемость/понимаемость кода - и обрабатываем все ошибки уже после алгоритма, в блоке catch" - а по факту получилось, что выигрыша (для читабельности/удобства) - нет, если мы хотим более-менее вменяемые сообщения о ошибках.
Концепция исключений, как таковых - она изначально (когда её придумывали, наверно, уже лет 30 назад) казалась удобной и разумной - но на практике оказалась неудобной и неразумной, не считая одного или двух случаев.
Основная проблема с идеологией try/catch - она состоит в том, что к тому времени, как мы исключение обрабатываем - мы полностью потеряли контекст, в котором оно возникло.
Примеры с одним-двумя выражениями в блоке try() - они на самом деле бессмысленные, так как технически ничем не лучше "давайте обработаем ошибку прямо тут".
А когда у вас в блоке кода 3-5 мест, где может быть выброшено исключение одного и того же типа (например, мы открываем на чтение два файла, и третий - на запись, и каждый из них может не существовать или быть недоступен) - нам надо или принудительно сохранять контекст, или мы этот контекст потеряем.
Так что я в своё коде пришёл единственному разумному подходу: не генерируют исключений, формирую сообщение о ошибке и возвращаю "неудача".
Для С++ это выглядит как:
bool some_func(... , std::string & a_err);
В других языках - можно возвращать пару (реальный результат и сообщение о ошибке).
В моём коде прямо при выполнении каждого действий или проверке - в случае неудачи, формируется сообщение о ошибке, включающее весь нужный контекст. Потому что именно там этот контекст и есть.
Код уровнем выше может дополнить сообщение о ошибке. Например, функция проверки контрольной суммы файла может вернуть "файла нет/нет записи контрольной суммы/сумма неверна" - а уровнем выше, добавить - почему именно в этом файле должна быть контрольная сумма.
Чтобы пользователь не задавал мне идиотских вопросов "почему твоя программа валится с исключением, которое мне ничего не говорит?"
Да, можно кидать исключение со сформированным сообщением о ошибке - но это:
а) ничем не проще, чем сделать return false
b) если в коде несколько вызовов, чтобы добавить к ним контекст - придётся каждый окружать блоком try/catch. Это чисто физуально будет больше кода, чем просто:
if (! some_func(...,a_err))
{
a_error = "Additional context, failed: " + a_err;
return false;
}
Аж на две скобки меньше
======================
А когда использование исключений реально полезно? А в тех же (редких) случаях, когда раньше в языке С использовали longjump.
Лично я вижу только два применения
а) легитимно, в модульных тестах - вместо фатального завершения при срабатывании halt() или verify() (макросы, активно используемые в защитном программировании, штатно выдающие сообщение на консоль и завершающие с помощью abort()) - кинуть исключение и перехватить его в тесте. Удобно тестировать наличие/срабатывание проверок защитного программирования.
б) хак. Современные линуксы позволяют выполнять throw из сингальных хандлеров (хотя и не гарантируют). Можно выйти из зациклившегося алгоритма по SIGALARM.
Компилятор не удалял массив. Он сохранял его в исполняемом файле в компактном виде, в виде алгоритма, который генерировал его в оперативной памяти при старте программы.
Компилятор может не только код отомтимизировать, но и память.
Я в своё время сражался с llvm, пытаясь убедить его оставить в экзешнике крупный массив байт (в готовый экзешник в этот массив записывалась дополнительная информация).
gcc в такой ситуации достаточно было массив инициализировать, хотя бы не полностью - а llvm отследил варианты предсказуемой инициализации массива (например, константой отличной от нуля) и массив из экзешника выпиливал. Создавал динамически, на этапе инициализации.
Пришлось инициализировать массив сложной последовательностью, так чтобы компилятор не догадался, как её можно сгенерировать.
Вообще-то это ничего не значит. Ядро Линукс тоже на С написано.
Что, из-за этого С++ не пользоваться?
Под современные микроконтроллеры спокойно можно писать на С++, т.к. clang и gcc пофиг, что преобразовывать в машинный код.
И да, при желании - с использованием урезанной стандартной библиотеки (без ввода/вывода), т.е. запросто можете пользоваться std::map и std::string. Если это удобно разработчику.
Да, надо иметь в виду, что использование динамической памяти на микроконтроллере - может привести к неожиданным результатам, но при грамотном использовании - более чем полезно.
А использовать проверенную десятилетиями связку flex+bison было слишком страшно?
Это ведь идеальная задача для парсера и грамматики.
Учитывая, что судя по вашему описанию - ваша утилита будет глючить на
комментариях, содержащих фигурные скобки
строковых литералах, содержащих фигурные скобки
символьных литералах, содержащих фигурные скобки
В общем, советую переделать по-взрослому.
Кстати, если немного подумаете - то сможете не просто проверочную утилиту реализовать, а реализовать утилиту, которая автоматом будет вставлять эти комментарии.
Ну да. Причём по его комментарию - ничего там особенного нет.
Фактически Столлмен возражал против того, что секс с 17-летней девкой, которая этим занимается профессионально (что тоже нарушает закон, и Столлмен это не отрицал) - описывали в терминах, создающих впечатление о изнасиловании несовершеннолетней лет так 12. Или 5.
Зачем использовать эту технологию для уже выведенного в космос аппарата?
Реактор, который далее используется для питания ионных движков - эффективнее на два порядка.
Основная проблема с программированием в настоящее время - это то, что процентов 90, а может быть - 95 программистов занимаются полной хренью, которая по большому счёту нафиг никому не нужна и будет выкинута и забыта через полгода после окончания работы.
Миллионный раз делают те же самые окошки. Только полупрозрачные и с закруглёнными углами. Или формочки. Или тупую "бизнес-логику". Или очередной супердинамический сайт на модном фреймворке. Или очередную версию "офисного пакета".
В общем и целом - 90% усилий уходит в абсолютное НИ-КУ-ДА.
Не потому, что программисты такие глупыи или злонамеренные.
А потому, что современный бизнес, ориентированный на прибыль - требует именно этого.
Частично это - желание менеджеров найти оправдание существованию своих отделов. Ведь если вся работа сделана и осталась только поддержка и исправление редких багов - финансирование придётся сократить.
Частично - желание программистов, занимающихся тупой хренью типа впихивания контекстной рекламы - использовать какой-нибудь модный подход или новый язык. Или самим сделать новый фреймворк. Или перейти на новый фреймворк. Или переделать всё на микросервисы, при этом каждый - на своём языке.
Если так подумать - существенная часть умственного ресурса цивилизации сливается в унитаз. На разработку очередного "тапающего хомяка", например.
В общем, что и ожидалось. Вы можете сделать систему ИИ, которая демонстрирует сложное и вроде бы разумное поведение - но не можете реально оценить, не будет ли в этом поведении странных неожиданных сбоев.
Тут одно из двух: или простые, полностью понятные человеку алгоритмы - или вот так.
Извините конечно, но библиотеку работы с памятью, устойчивой к фрагментации, я видел лет так 20 назад. Точнее, доки к ней.
Кратко: при выделении небольших блоков памяти, они выделяются как часть ранее выделенной странице. Т.е. страница, хранящая блоки до 8 байт длиной, до 16 байт, до 32, до 64, до 128 и так далее. И этот подход отлично работает.
Неужели эта проблема до сих пор актуальна хотя где-то?
Скорее всего у немцев тоже были проблемы сделать абсолютно взаимозаменяемые магазины. Это реально непростая задача.
А чем исходно было обоснованно требование о запрете сверления в стволе отверстия для газоотвода?
Ведь для этого должен был быть какой-то повод, обоснование, причина.
Глубина стека - всего 16 элементов? Тут же в рекурсии в любой момент времени уменьшается или n, или m - значит, в любой момент времени глубина стека не более n+m.
Такая задача может по времени обламываться, т.к. без кэширования результатов "дерево" получается очень широкое.
Конкретно для этой задаче - не проще сделать мэп с [m,n] -> value, и если в мэпе уже есть значение - возвращать его, а если нет - вызываться рекурсивно?
В вашем примере кандидат реально ответил на вопрос с очень высокой точностью навскидку.
Это означает, что у него хорошо развит здравый смысл.
Грозоразрядник. Если к вашему дому подведена воздушная/наземная проводка, где-то (обычно в коробке снаружи) устанавливается грозоразрядник.
Наведённое (молнией) высокое напряжение в проводе или (для проводов с экраном) в экране, нужно разрядить на землю. При этом, разумеется, слышен щелчок разряда - который физически происходит куда ближе к вам, и вы его слышите почти одновременно с ударом молнии.
Я пару раз дежурил на ж.д. станциях в помещении дежурного по станции, где грозоразрядник (по-моему, на антенну поездной радиосвязи) был установлен в помещении внутри. Разряд внутри помещения и молния снаружи были почти синхронны, по крайней мере я разницы не заметил.