З'явіўся новы дыялект, у якім вырашаецца галоўная «болька» С і С++
Стартап Trasec прыступіў да распрацоўкі новай мовы праграмавання TrapC, якая ёсць эвалюцыйнай формай С і С++, паведамляе The Register. Ейная галоўная асаблівасць у бяспечнай працы з памяццю, якая закрые хакерам прастор для творчасці.
Аўтары TrapC прапанавалі свой метад абароны ад памылак пры працы з памяццю, выхад па-за межы буфера і спробу працы з ужо вызваленай памяццю. Ідэя палягае ў пераглядзе алгарытмаў працы з паказальнікамі памяці і стварэнні новага механізму перахопу памылак.
Гэты механізм яны прапаноўваюць грунтаваць на так званым «апрацоўшчыку выключэнняў» (trap), што адлюстравана ў назве мовы. Таксама вядзецца праца над кампілятарам для яго, код якога аўтары ў будучыні хочуць зрабіць адкрытым. Па плане гэта мае адбыцца ў наступным годзе, але дакладнай даты пакуль няма.
Усе новыя алгарытмы і механізмы абароны будуць рэалізаваныя непасрэдна ў кампілятары. Яны будуць строга сачыць за межамі выдзеленых буфераў памяці і за тым, што паказальнікі спасылаюцца толькі на звязаныя з імі вобласці памяці. Акрамя гэтага, кампілятар будзе сачыць за ўжываннем тыпаў і «лаяцца» на небяспечнае, паводле яго ацэнкі, іх выкарыстанне.
Распрацоўшчыкі TrapC імкнуцца зрабіць мову прасцейшай за С або С++. У прыватнасці, у ім няма канструктара malloc — выкарыстоўваецца канструктар new. Таксама былі выключаныя выклікі free і delete, а кампілятару сярод іншага даручана адказваць за вызваленне памяці. Такі падыход дадаткова павышае абарону ад уцечак памяці. У TrapC нашмат менш ключавых слоў, чым у С і С++. Так, у ім адсутнічае ключавое слова union, якое ўжываецца для вызначэння аб’яднанняў. Адначасова гэтая мова распрацаваная для сумяшчальнасці з C, паколькі яна выкарыстоўвае той жа двайковы інтэрфейс праграмы.
Ля вытокаў стартапа Trasec, як і мовы TrapC, стаіць былы прафесар камп’ютарных навук і былы сябра шматлікіх камітэтаў па развіцці стандартаў С і С++ Робін Роу. Ён таксама вядомы як суаўтар знакамітага оўпэнсорснага графічнага рэдактара Cinepaint, які выкарыстоўваўся пры стварэнні графікі прыкладна для 20 вядомых фільмаў, у тым ліку «Двайнога фарсажу», «Планеты малпаў», «Чалавека-павука» і ўсіх фільмаў пра Гары Потэра. Акрамя гэтага, Роу распрацоўваў POSIX-бібліятэку libunistd для Windows. У Trasec ён выконвае ролю гендырэктара. Цяпер стартап займаецца пошукам інвестараў і зборам сродкаў.
За праблемы з памяццю С і С++ у апошнія гады адкрыта і ўсё гучней лаюць праграмісты і чыноўнікі. Спецыялісты заклікаюць пазбавіцца ад абедзвюх моў і перайсці на іх бяспечных для памяці канкурэнтаў, а таксама перапісаць усе праекты на іх. Часцей за ўсё ў якасці бяспечнай альтэрнатывы С і С++ згадваецца Rust. Яго ўжо прапанавана выкарыстоўваць для ядра Linux, а Microsoft задумваецца аб перапісванні на ім часткі сваіх прадуктаў. Зрэшты, сярод праграмістаў пакуль яшчэ шмат тых, хто не збіраецца адмаўляцца ад С і С++ на карысць Rust.
В С++ тоже нет "конструктора malloc", если вдруг они не знают. malloc это банально функция из рантайма.
Также были исключены вызовы free и delete
Шта? Ничо что выделенное через new полагается освобождать через delete?
в нём отсутствует ключевое слово union
Уф... Сразу на помоечку, ибо писать что либо системное на таком поделии будет сплошная боль.
В общем как всегда, С++ простудится на похоронах очередного "убивцы С++".
Anonymous
16 лістапада 2024, 02:24
0
Почитал оригинал и там ещё веселее.
Очередной "езыг" созданный теоретиками для теоретиков.
"Решили" уже много лет как не существующую проблему но создали туеву хучу новых.
Также были исключены вызовы free и delete, а компилятору в числе прочего поручено отвечать за высвобождение памяти.
Вообще то delete это перегружаемый оператор, а не вызов. Реализация по умолчанию опирается на free.
Память выделяется не в момент компиляции, в момент выполнения, как компилятор освободит память которая будет выделена и освобождена на совершенно другой технике и в другое время? Наверное так неуклюже назвали сборщик мусора. Тогда зачем нам ещё один язык со сборщиком мусора, чем Java или новомодный Go не подходит?
Такой подход дополнительно повышает защиту от утечек памяти.
Да пофиг всем на утечки. Практически любой С или C++ код имеет утечки ресурсов в том числе памяти, особенно при обработке ошибок и исключительных ситуаций. Но, эти утечки - они в сотни раз меньше чем "неутечки" в языках со сборщиком мусора из-за его отложенного запуска. Кроме того много много современных приложений запускаются и быстро помирают, и ОС за ними всю память освобождает.
Карыстальнік адрэдагаваў каментарый 16 лістапада 2024, 02:56
Согласен с тем, что ещё одни безумцы решили увеличить зоопарк языков.
Но не все приложения работают по принципу один раз запустил и вышел. Сервисные приложения в Linux/Windows. Любые сетевые сервисы при высокой нагрузки никто не будет останавливать. И это ещё не говоря про Embedded, когда это какое-то критическое устройство, в транспорте, медицине. Даже у мобильных ОС можно тоже сделать сервисные приложения, хотя пытаются всякими Deep Sleep подрезать им возможность постоянно висеть.
По мне это хороший тон, когда приложение умеет нормально управлять своими ресурсами. Взять например те же потоки, они должны уметь в нормальное время останавливать свою работу (если конечно это не супер критичная задача, которую им прям кровь с носа надо завершить перед остановкой), чтобы не пришлось принудительно килять. По моим наблюдением раньше с gaceful прерыванием работы было ещё хуже, чем сейчас. А отдать подчищать память ОС, это как вот отдают это на откуп сборщику мусора. Только при долго работающих приложениях ОС не спасёт.
А в c++ нету како-то линтера, что бы проверял все ли выделение памяти освобождается?
Anonymous
18 лістапада 2024, 15:41
1
Если чо, в С++ давно уже вручную память освобождают разве что в глубинах какого нить framework. Всё всегда завёрнуто, с голыми указателями наперевес никто не ходит.
Чтоб в современной С++ проге память потекла - это нонсенс. Не надо пускать сишников писать на плюсах - они пишут С программу с "кусочками фруктов", со всеми болячками С.
Утечки происходят во время исполнения, а не компиляции. Так что есть инструменты типа валгринда или там электрикфенса. Они работают в момент исполнения приложения
Карыстальнік адрэдагаваў каментарый 17 лістапада 2024, 20:49
Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.
А мужики-то не знают...
чего не знают?
Ясно. Очередной неосилятор. Нет этих проблем уже 100 лет в обед. Откройте стандарт.
так С или С++?
В С++ тоже нет "конструктора malloc", если вдруг они не знают. malloc это банально функция из рантайма.
Шта? Ничо что выделенное через new полагается освобождать через delete?
Уф... Сразу на помоечку, ибо писать что либо системное на таком поделии будет сплошная боль.
В общем как всегда, С++ простудится на похоронах очередного "убивцы С++".
Почитал оригинал и там ещё веселее.
Очередной "езыг" созданный теоретиками для теоретиков.
"Решили" уже много лет как не существующую проблему но создали туеву хучу новых.
Можно закапывать.
Вообще то delete это перегружаемый оператор, а не вызов. Реализация по умолчанию опирается на free. Память выделяется не в момент компиляции, в момент выполнения, как компилятор освободит память которая будет выделена и освобождена на совершенно другой технике и в другое время? Наверное так неуклюже назвали сборщик мусора. Тогда зачем нам ещё один язык со сборщиком мусора, чем Java или новомодный Go не подходит?
Да пофиг всем на утечки. Практически любой С или C++ код имеет утечки ресурсов в том числе памяти, особенно при обработке ошибок и исключительных ситуаций. Но, эти утечки - они в сотни раз меньше чем "неутечки" в языках со сборщиком мусора из-за его отложенного запуска. Кроме того много много современных приложений запускаются и быстро помирают, и ОС за ними всю память освобождает.
Карыстальнік адрэдагаваў каментарый 16 лістапада 2024, 02:56
Согласен с тем, что ещё одни безумцы решили увеличить зоопарк языков.
Но не все приложения работают по принципу один раз запустил и вышел. Сервисные приложения в Linux/Windows. Любые сетевые сервисы при высокой нагрузки никто не будет останавливать. И это ещё не говоря про Embedded, когда это какое-то критическое устройство, в транспорте, медицине. Даже у мобильных ОС можно тоже сделать сервисные приложения, хотя пытаются всякими Deep Sleep подрезать им возможность постоянно висеть.
По мне это хороший тон, когда приложение умеет нормально управлять своими ресурсами. Взять например те же потоки, они должны уметь в нормальное время останавливать свою работу (если конечно это не супер критичная задача, которую им прям кровь с носа надо завершить перед остановкой), чтобы не пришлось принудительно килять. По моим наблюдением раньше с gaceful прерыванием работы было ещё хуже, чем сейчас. А отдать подчищать память ОС, это как вот отдают это на откуп сборщику мусора. Только при долго работающих приложениях ОС не спасёт.
Чего только не выдумают люди, лишь бы Rust не учить...
А в c++ нету како-то линтера, что бы проверял все ли выделение памяти освобождается?
Если чо, в С++ давно уже вручную память освобождают разве что в глубинах какого нить framework. Всё всегда завёрнуто, с голыми указателями наперевес никто не ходит.
Чтоб в современной С++ проге память потекла - это нонсенс. Не надо пускать сишников писать на плюсах - они пишут С программу с "кусочками фруктов", со всеми болячками С.
Утечки происходят во время исполнения, а не компиляции. Так что есть инструменты типа валгринда или там электрикфенса. Они работают в момент исполнения приложения
Карыстальнік адрэдагаваў каментарый 17 лістапада 2024, 20:49
Похоже что обратная совместимость с C очень ограничена, старые исходники на этом языке не соберёшь. Не взлетит.
Карыстальнік адрэдагаваў каментарый 17 лістапада 2024, 22:45