Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы:

Стремление С++ стать более "безопасным" языком программирования плохо сочетается с требования к стандарту языка. Ведь любой стандарт должен обеспечивать обратную совместимость со старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++.

А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что:

• Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом.
• Переписать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты),
  ничуть не дешевле, чем переписать этот же код на новом модном языке программирования.

Возможным выходом из данной ситуации является реализация такого синтаксиса безопасного С++, который бы позволил удовлетворить оба этих требования. Причем самый лучший вариант,
вообще не принимать какие либо новые стандарты С++ для изменения лексики, а попробовать использовать уже существующие принятые ранее.

Проблема безопасной разработки на С++ возникла не вчера, и она достигла таких размеров, что рекомендации использовать более надежные языки программирования, принимаются на самом высоком уровне.

Но даже несмотря на наличие подобных рекомендаций, планы прекратить использовать С++ и перейти любой другой безопасный язык программирования, часто не выдерживают обычных финансовых расчетов. Ведь если отказаться от С++, то что придется делать с миллионами или даже миллиардами строк кода, которые были написаны за несколько предыдущих десятилетий?

К сожалению, и сам С++ не особо стремится стать более "безопасным". Точнее, подобное стремление плохо сочетается с требования к стандарту языка, которые принимаются комитетом по стандартизации С++. Ведь любой стандарт должен обеспечивать обратную совместимость со всем старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++.

И в это ситуации правы те, кто выступает за обязательную поддержку обратной совместимости со старым кодом. Но правы и те, кто считает необходимым добавление новых возможностей для безопасной разработки на С++ хотя бы в новых проектах.

Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:

• Текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов языка.
• Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом.
• Переписывать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты), ничуть не дешевле, чем переписать этот же код на новом модном языке программирования.

Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".

Еще одна статья в продолжение темы анализа сходных текстов на С/С++ с помощью Clang. Предыдущие публикации:

• ​Как создать собственное расширение компилятора C++
• Анализ AST и рефакторинг кода в Clang

Это не перевод довольно подробной публикации Emitting Diagnostics in Clang от Peter Goldsborough про различные нюансы диагностических инструментов у Clang, а преимущественно адаптация старого кода под текущую версию компилятора.

И основная идея, которая меня заинтересовала в исходной публикации, это использование инструмента FixIt из набора диагностики clang для внесения исправлений в исходные файлы.

В продолжение темы кастомизации компилятора С++ публикую перевод еще одной интересной статьи от Eli Bendersky AST matchers and Clang refactoring tools.

Инструментарий Clang вызывает большой интерес и внимание к разработке в последние годы. Наконец-то у нас есть удобный, точный, с открытым исходным кодом и хорошо поддерживаемый фреймворк для программного анализа и рефакторинга кода C++ и это я нахожу это очень захватывающим!

Прекрасным результатом этого быстрого темпа разработки является то, что постоянно появляются новые API и инструменты.

Например, некоторое время назад разработчики инструментария Clang выяснили, что людям, выполняющим обходы AST, приходится писать много повторяющегося кода, чтобы найти нужные им узлы AST, поэтому они придумали отличный новый API под названием AST matchers.

Это перевод статьи, которая, к сожалению, у меня не доступна без слова из трех букв. А так как тема довольно интересная, то я решил совместить полезное с полезным и не только самому покопаться с примерами из публикации, но и сделать её перевод на Хабре. Вдруг еще кому данный материал будет интересен?

Создание пользовательского расширения компилятора C++ подразумевает понимание базовых механизмов работы компиляторов, изменение или расширение их функциональности и бесшовную интеграцию этих изменений в существующую инфраструктуру компилятора. Это руководство проведет вас через весь процесс, от понимания основ до внедрения и тестирования вашего пользовательского расширения. Целевая аудитория этого руководства — разработчики, которые уже знакомы с C++ и имеют базовое понимание концепций компилятора.

Как говорится, "нет худа без добра" и результатом пандемии COVID стал массовый перевод сотрудников на удалённую работу. Так же получилось и у меня, и сразу остро стал вопрос об организации комфортного рабочего пространства.

Хорошо, что для работы удалось выделить отдельную комнату, но её дверь выходит в общий коридор. И в результате тихий шум кулеров компьютера часто перекрывается шумом посуды на кухне, звуками телепередач, музыкой и прочими отвлекающими шумами, которые мешают сосредоточиться.

К сожалению, рабочая комната очень маленькая, и при закрытой двери там можно просидеть всего 10-15 минут, после чего комнату приходится проветривать из-за слишком спертого воздуха. А для этого нужно или больше открывать окно (а это обязательный сквозняк) или дверь в коридор, где слышно практически все и всех :-(

К счастью, данную проблему удалось решить с помощью установки кондиционера с притоком свежего воздуха. Причем некоторые нюансы выбора кондиционера оказались настолько важными, что я был очень неприятно удивлен тем фактом, что при выборе и покупке модели мне про них продавец ничего не рассказал. Более того, некоторые особенности наоборот попытался скрыть или выставить как не важные.

Данная статья — это своего рода подсказка тем, кто еще находится в процессе выбора модели кондиционера, чтобы не упустить некоторых очень важных деталей, т.к. впоследствии поменять уже установленную сплит-систему очень непросто.

Ведь как нельзя лучше про это сказал Генри Форд, что "разочарование от низкого качества длится дольше, чем радость от низкой цены".

Фундаментальной (по моему мнению) проблемой множества языков программирования является неявное использование ссылок (ссылочных переменных).

И проблема не в том, что с помощью ссылок изменяются какие-то общие данные, а в том, что часто это делается неявным образом, из-за чего программист должен всегда помнить об особенностях таких переменных.

Еще одной проблемой (или следствие предыдущей) является многопоточное и/или асинхронное выполнение программы, когда к одной и той же области данных может быть получен доступ из разных потоков приложения, что в купе с неявным доступом по ссылкам еще больше усугубляет ситуацию.

А как бы хотелось отдать эти проблемы на откуп компилятору! Чтобы компьютер сам автоматически проверял корректность доступа по ссылкам, в том числе и из разных потоков и чтобы все это делалось во время компиляции приложения без накладных расходов в рантайме!

И если такое будет возможно, тогда постепенно уйдет в прошлое целая эпоха сборщиков мусора с их неожиданными зависаниями программ в произвольные моменты времени и разными мудреными алгоритмами поиска мертвых указателей и циклических ссылок!

При написании этой статьи сперва мне хотелось описать какие нибудь параллели с ИТ, а потом с умным видом сделать вывод, но потом я решил, что фотографий котиков в статье будет вполне достаточно. Ну а для тех, кому статью читать не хочется, а фотографии кошачьих не интересуют, держите итоговый вывод.

Иногда можно голову сломать над решением какой либо пустячной проблемы, но потом наступает озарение, что впору удивлять, как это настолько простое и очевидное решение не пришло тебе в голову с самого начала.

Но обо всем по порядку под катом (с картинками)

Недавно прочитал новость, что Mail.ru отменила бесплатные вечные 100 ГБ для первых пользователей «Облако Mail.ru»

В конце октября 2024 года компания Mail (принадлежит VK) предупредила клиентов, что отменяет бесплатные вечные 100 ГБ для первых пользователей «Облако Mail.ru» спустя 11 лет старта проекта.

К сожалению, это не единственное нововведение от бывшего бесплатного почтового сервиса, который постепенно начинает коммерциализировать свою клиентскую базу, что совсем не удивительно, если введен законодательный запрет на использование иностранных почтовиков, а твою почту рекламируют на самих Госуслугах как замену бесплатной, но к сожалению запрещенной gmail.com.

Но это предыстория, а сама история вот:

Уже давно обратил внимание, что при отправке любого письма на Mail.ru показывается плашка "Письмо отправлено. Вы можете отменить отправку ..." со счетчиком оставшихся секунд до отмены, но я никогда на это не реагировал, всегда нажимая крестик для закрытия окна.

Но однажды, к своему сожалению, решил ради интереса посмотреть, что же будет, если нажать на кнопку "отменить отправку".

И как оказалось ничего хорошего!

После перехода на удаленку у меня в полный рост встала проблема с прокрастинацией задач. Все как по написаному:

И чтобы решить эту проблему раз и навсегда, купил себе простенький таймер, чтобы максимально легким способом (без всяких смартфонов), можно было устанавливать временные периоды для работы и перерывов.

Сразу хочу написать, что это решение, что называется "зашло", и даже сейчас я пишу статью под контролем таймера. Но сама статья не о самоорганизации работы, а об устройстве для этого (непосредственно самом таймере). Точнее о том, как я его дорабатывал под собственные нужды в надежде, что вдруг кому-то пригодится мой опыт.

Recently, there has been a lot of talk about the success of artificial intelligence (AI), although this usually means another achievement in the field of generative neural networks.

And few people, speaking about AI, try to explain what they themselves understand by the term “artificial intelligence.” After all, it’s one thing to write about “AI problems,” and quite another to endow an ordinary computer algorithm with at least the rudiments of intelligence.

After all, the etymology of the established phrase “artificial intelligence” is not unambiguous and can take on different meanings depending on what meaning the author is trying to put into it.

Последнее время кто только не говорит про успехи искусственного интеллекта (ИИ), часто подразумевая под этим очередное достижение в области генеративных нейросетей. И как обычно, одни делают деньги на хайпе, другие жаждут появления Сары Коннор настоящего сильного ИИ (который в будущем захватит мир), а кто-то просто в очередной раз насилует журналиста.

И очень мало тех, кто при упоминании ИИ пытается пояснить, а что он сам понимает под термином "искусственный интеллект". Ведь одно дело писать про "область задач из разряда ИИ", и совсем другое, наделять обычный компьютерный алгоритм хотя бы зачатками разума.

Давно хотел написать, что сама этимология устоявшегося словосочетания "искусственный интеллект" не однозначна и может принимать разные значения из контекста, так как обозначает понятие, которое может отличаться от того, которое в него пытается вложить автор. И чтобы понять, что же в словосочетании "искусственный интеллект" не так, давайте разложим его на составляющие:

Как-то меня зацепила статья Зачем вам нужен профсоюз? в которой от лица работников ИТ-отрасли стран СНГ пропагандируется организованная форма саботажа воздействия на работодателя, как единственный способ решения проблем между работниками и собственниками бизнеса.

Зацепила в первую очередь тем, что я успел побывать на каждой из сторон подобного противостояния и неоднократно приходилось вмешиваться и разруливать различные проблемы. Причем "разруливать", это не только объяснить сотруднику в чем он был не прав, но и показать руководству, что так делать не стоит и давайте попробуем вот-так, чуть по другому.

И ни одном случае ни разу не было ситуации, когда забастовка помогла бы в разрешении кризисной ситуации. Потому что забастовка, это "Ultima ratio", последний довод, и он хорош только в виде аргумента, до использования которого дело не дойдет. Но если уж дошло, то можно со 100% уверенностью готовить заявление на увольнение, потому что у работодателя достаточно способов не нарушая закон избавиться от подобных неадекватных сотрудников.

Последнее время только ленивый не пишет о великом прорыве человечества в области разработки искусственного интеллекта под общим названием "большая языковая модель" (LLM, large language model). И хотя у них остается еще много возможностей для совершенствования, но за последние несколько лет подобные приложения стали действительно востребованными. Большие языковые модели привлекают своей сверхъестественной способностью резюмировать текст, понимать естественный язык и создавать контент (и судя качеству некоторых статей, в том числе и тут на Хабре).

Правда подобные инструменты иногда сбоят и выдают некорректную информацию т.е. "галлюцинируют", которую выдают за правду. Генераторы изображений могут нарисовать лошадей с пятью ногами или кисть руки с семью пальцами. Однако подобные "фантазии" не всегда плохо. Например, когда творчество ценится выше точности, генерация не существующего контента, но похожего на правду, может оказаться полезной.

Томас Валадес (Thomas Valadez) воспользовался этим творческим потенциалом, чтобы создать интересное устройство под названием «Storybook». Его проект с открытым исходным кодом превращает Raspberry Pi в рассказчика на базе искусственного интеллекта, способного создавать иллюстрированные сказки. Это устройство использует LLM и генератор изображений для создания одной страницы книги из никогда не существовавшего сборника рассказов и выводит их на E-Ink дисплей.

I always pay attention to assessing the complexity of programming in a particular language. Programming is indeed not an easy task and this is perceived as a fact and usually does not require any confirmation.

But the concept of “complexity” is akin to the term “heap”. For some, five coconuts is not so much, but for someone who ate one and “didn’t want any more,” this means that even one coconut will be too much for him.

The same goes for the complexity of programs. It seems that the constant increase in the complexity of programs is obvious to everyone and is observed in all areas of application of IT technologies, and programming languages themselves become more and more complex as they develop, but assessing “complexity” using numerical metrics is a problem. obviously a thankless task, but also “You can’t manage what you can’t measure...”

Typically, talk of “complexity” only implies value judgments without any numerical evaluation. And since I am personally interested in the issue of the complexity of programming languages, I decided to calculate the complexity of implementing the gcc compiler on some conditional “parrots”. What if we could see some patterns of difficulty changing over time?

Brainfuck — это один из эзотерических языков программирования, который имеет всего восемь команд, каждая из которых записывается одним символом.

А Bodyfuck — это жестовый интерпретатор Brainfuck, который позволяет писать код программы, используя различные движения тела без использования клавиатуры.

Смотрите, не перепутайте! :-)

Practically all programming languages are built either on the principle of similarity (to make like this one, only with its own blackjack) or to realize some new concept (modularity, purity of functional calculations, etc.). Or both at the same time.

But in any case, the creator of a new programming language doesn't take his ideas randomly out of thin air. They are still based on his previous experience, obsession with the new concept and other initial settings and constraints.

Is there a minimal set of lexemes, operators, or syntactic constructs that can be used to construct an arbitrary grammar for a modern general-purpose programming language?

Every programmer is familiar with the concept of "reference." This term usually refers to a small object whose main task is to provide access to another object physically located elsewhere. Because of this, references are convenient to use, they are easily copied, and they make it very easy to access the object to which the reference points, allowing access to the same data from different parts of the program.

Unfortunately, manual memory management, or more precisely, manual memory control, is the most common cause of various errors and vulnerabilities in software. All attempts at automatic memory management through various managers are hampered by the need to control the creation and deletion of objects, as well as periodically run garbage collection, which negatively affects application performance.

However, references in one form or another are supported in all programming languages, although the term often implies not completely equivalent terms. For example, the word "reference" can be understood as a reference as an address in memory (as in C++) and a reference as a pointer to an object (as in Python or Java).

Although there are programming languages that try to solve these problems through the concept of "ownership" (Rust, Argentum, or NewLang). The possible solution to these and other existing problems with references will be discussed further.

Любому программисту знакомо понятие "ссылка". Под этим термином обычно понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, физически расположенному в другом месте. Из-за этого ссылки удобно использовать, они легко копируются, и с их помощью очень просто получить доступ к объекту, на который эта ссылка ссылается и можно получить доступ к одним и тем же данным из разных мест программы.

К сожалению ссылки, точнее ручное управление памятью, является наиболее частой причиной возникновения различных ошибок и уязвимостей в программном обеспечении. А все попытки автоматического управления памятью с помощью различных менеджеров упираются в необходимость контролировать создание и удаление объектов, а также периодически запускать сборщик мусора, что отнюдь не положительно сказывается на производительности приложений.

Тем не менее, ссылки в той или иной форме поддерживаются во всех языках программирования, хотя под этим термином часто подразумеваются не полностью эквивалентные термины. Например, под словом "ссылка" можно понимать ссылку как адрес в памяти (как в С++) и ссылку, как указатель на объект (как в Python или Java).

Хотя встречаются языки программирования, которые пытаются решать данные проблемы за счет концепции "владения" (Rust, Аргентум или NewLang). О возможном решении этих и других имеющихся проблем со ссылками далее и пойдет речь.

У меня уже более пяти лет пылится старый монитор ASUS VH323T. Это довольно старая модель с диагональю 23" и довольно неплохой матрицей (на КДПВ не он), но все дело портит очень плохая подсветка. Мало того, что у нее очень низкая яркость (всего 300 кд/м2), так еще лампы подсветки со временем очень сильно потускнели до противного желтого цвета, в результате чего монитор был заменен на более современный, чтобы не ломать глаза.

Тем не менее, монитор вполне рабочий, и противное земноводное не разрешает его просто взять и выбросить на помойку, тогда как продать монитор новому владельцу не позволяет уже совесть.

Когда-то встречал на просторах интернета пару статей, в которых описывалось, что можно заменить в мониторе старые лампы подсветки на новые. И после того, как в очередной раз запнулся за коробку со старым монитором, решил попробовать заменить его подсветку на светодиодную. Ведь после этого его можно будет либо честно продать, либо просто выкинуть. В любом случае, избавлюсь от старого хлама :-)

Кому интересны рабочие нюансы и рассказ о не совсем очевидных проблемах, прошу под кат с фотками котиков этапов работ, конечного результата и финальных выводов.