Memory-Safety on TrustLang

Управление памятью и совместный доступ

Mon, 01 Jan 0001 00:00:00 +0000

Ни один способ управления памятью не является лучшим или универсальным: в разных условиях выигрывают разные подходы:

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

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

Безопасность ПО

Mon, 01 Jan 0001 00:00:00 +0000

Ахиллесова пята C++ и будущая р̶е эволюция

Fri, 10 Apr 2026 00:00:00 +0000

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.

Но чтобы оставаться честным перед читателями, решил опубликовать и статью-контраргумент с описанием обратной стороны медали, то есть почему C++ всё равно будет рано или поздно заменён, а заодно попробовать разобрать, каким будет новый язык программирования, который неминуемо придёт на смену C++.

Экономика безопасности кода или почему Rust не нужен

Sat, 04 Apr 2026 00:00:00 +0000

Прочитал статью Параллелизм с общим состоянием в Rust и обратил внимание, что её общий смысл можно выразить известной фразой: “делай как нужно, а как не нужно, делать не нужно”. Другими словами, это точно такой же совет, какой можно дать разработчику любого другого языка программирования, например С++.

И решил не продолжать дискуссию в комментариях, а выразить мнение в виде краткой статьи с описанием фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должно способствовать) массовому переходу с C/C++ на «безопасные» альтернативы. Так как из-за особенностей распределения затрат у разработчика ПО отсутствует экономическая мотивация к полному устранению ошибок, и как следствие - к переходу на использование «безопасных» языков программирования.

Безопасность С++ и буридановы мыши в ИТ

Thu, 02 Apr 2026 00:00:00 +0000

В ИТ есть странная форма «информационной инерции»: когда фраза однажды удачно легла на реальность, стала цитатой, превратилась в маркер «своего» - и дальше продолжила жить сама по себе. Реальность уехала, практики сменились, инструменты стали другими, экономика разработки перевернулась, а штамп формулировки остался. И особенно охотно её повторяют те, кому нужно писать быстро и убедительно, но нет времени (или компетенции) разбирать в технических деталях.

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

Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++

Wed, 07 Jan 2026 00:00:00 +0000

7 января в 14:53 2026

Fetching Title#4teb

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

Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.

Возможное решение проблемы ссылок в языках программирования

Tue, 23 Apr 2024 00:00:00 +0000

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

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