Реализации объектно-ориентированного программирования в разных Си-подобных языках, конечно, похожи, и все такие языки, созданные после C++, пытаются сделать ООП более удобно используемым. Сравним в этой статье ООП в D и С++.
D *
Мультипарадигмальный компилируемый язык
Новости
Безопасная работа с памятью в D
Оригинальные статьи вышли с июня 2022-го по январь 2023-го в виде трёх постов на blog.dlang.org под общим заголовком «Безопасность памяти в современном языке системного программирования». Статьи посвящены DIP1000 — набору изменений, призванному существенно улучшить безопасность работы с памятью. Перевод объединяет все три.
Если стремитесь глубже разобраться с использованием @safe
-кода, атрибутов scope
и return scope
и узнать про автовыведение атрибутов функции, эта статья может оказаться полезной.
За рулем с D
Вот что приходит мне на ум, когда я думаю о D: быстрый, выразительный, легкий и... драйвовый? Именно так, я вожу машину вместе с D.
Вот мой почтенный автомобиль Holden VZ Ute. С завода он поставлялся с убогой четырехступенчатой автоматической коробкой передач. За 18 месяцев владения автомобилем я сломал четыре коробки передач. В то время я не мог позволить себе новый автомобиль, поэтому мне пришлось творчески подойти к делу. Я купил железобетонную, дуракоустойчивую шестиступенчатую автоматическую коробку передач от другого автомобиля. Но на этом я уперся в тупик. Чтобы заставить ее работать, мне пришлось собрать собственную печатную плату, систему управления и прошивку для управления соленоидами, гидравликой и сцеплениями внутри коробки передач, обработки команд водителя, принятия решений о переключении передач и взаимодействия с автомобилем, притворяясь четырехступенчатым автоматом.
Самый быстрый компилятор aka compiler-benchmark
От переводчика: все началось с топика на форуме D.
После оценки скорости компиляции D по сравнению с другими языками мне было интересно, существует ли какой-нибудь язык, который компилируется в нативный код почти так же быстро или быстрее, чем D, за исключением C?
Если да, то скорее всего, он должен использовать бэкэнд, отличный от LLVM.
Я думаю, что Jai способен на это, но он еще не вышел в релиз.
Бенчмарки скорости компиляции различных комбинаций языков и компиляторов. Поддерживаемые языки:
Компиляторы в нативный код
Истории
Независимый HttpBench для D, или врут ли тесты TechEmpower?
Простой фреймворк для тестирования HTTP-серверов, вдохновленный Simple Web Benchmark (Прим.пер.Там есть график для многих других языков), но сфокусированный на dlang фреймворках и библиотеках.
Он измеряет достижимый RPS (запросы в секунду) в сценарии простого текстового ответа (plaintext).
Тесты были собраны или изменены из различных мест (в том числе TechEmpower).
Он использует докер-контейнер для построения и размещения сервисов и может работать локально или использовать нагрузочный тестер с удаленного хоста.
В качестве генератора нагрузки используется по умолчанию wrk и запрашивает статистику у коллектора, но hey тоже поддерживается (просто используйте ключ --tool).
Тесты можно запускать и без докера, достаточно лишь установить компиляторы для протестированных языков и генератор загрузки wrk/hey (но протестировано только на linux).
Как я студентам язык D преподавал
Два года назад я начал читать курс “Язык программирования Ди” в самом настоящем университете, провёл в общей сложности 40 лекций, примерно столько же практических занятий даже дважды принял экзамен, один раз удалённо. Как так случилось, кому вообще может быть нужен D, и как ученик превосходит учителя, под катом.
Портируем утилиту командной строки с Go/Rust на D
Исходники на Гитхабе
Видео по клику
Триумфальное возвращение Ломуто
США, Техас, Остин, клуб Continental
Воскресенье, 5 января 1987 г.
— Спасибо за приглашение, мистер Ломуто. Скоро я возвращаюсь в Англию, так что это было очень вовремя.
— Спасибо, что согласились со мной встретиться, мистер… сэр… Чарльз… Энтони Ричард… Хоар. Это большая честь для меня. Я даже не знаю, как к вам обращаться. У вас есть рыцарский титул?
— Зовите меня Тони, и, если вы позволите, я буду называть вас Нико.
На первый взгляд — обычная картина: два человека наслаждаются виски. Однако внимательному наблюдателю открываются интригующие подробности. Прежде всего — напряжение, которое можно было резать ножом.
Одетый в безупречно подогнанный костюм-тройку с нарочитой небрежностью, на какую способен только англичанин, Тони Хоар был таким же воплощением Британии, как и чашка чая. Смиренное выражение лица, с которым он попивал из своего стакана, без всяких слов выражало его мнение в споре между бурбоном и скотчем. Сидевший напротив Нико Ломуто представлял полную ему противоположность: одетый в джинсы программист, мешавший виски с колой (что для Тони было настолько возмутительно, что он сразу решил подчёркнуто это игнорировать — как резкий запах пота или оскорбительную татуировку), в состоянии некого расслабленного трепета перед гигантом информатики, с которым он только что познакомился лично.
— Послушайте, Тони, — сказал Нико после того, как иссякли темы для обычной лёгкой беседы. — По поводу того алгоритма разбиения. Я даже не собирался его публиковать...
— Что? Ах да, алгоритм разбиения, — Тони поднял брови в притворном изумлении, словно забыв, что каждая статья или книга о быстрой сортировке за последние пять лет упоминала их имена вместе. Очевидно, что именно это связывало этих двух людей и было причиной этой встречи, но Тони, как безупречный джентльмен, мог бы часами говорить о погоде, если бы собеседник не упомянул о стоящем в комнате розовом слоне.
Портируем make.c на D
Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.
- D как улучшенный C
- Баги, которые разрушили ваш замок
- Портируем make.c на D
Better C — это способ перенести существующие проекты на языке C на язык D в последовательной манере. Эта статья показывает пошаговый процесс конвертации нетривиального проекта из C в D и частые проблемы, которые при этом возникают.
Хотя фронтенд компилятора D dmd уже сконвертирован в D, это настолько большой проект, что его трудно целиком охватить. Мне был нужен более мелкий и скромный проект, который можно было бы целиком держать в голове, но чтобы он не был умозрительным примером.
Мне пришла на ум старая make-программа, которую я написал для компилятора C Datalight в начале 1980-х. Это реальная имплементация классической программы make, которая постоянно использовалась с начала 80-х. Она была написана на C ещё до его стандартизации, портировалась из одной системы в другую и укладывается всего в 1961 строчку кода, включая комментарии. Она до сих пор регулярно используется.
Баги, которые разрушили ваш замок
Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.
- D как улучшенный C
- Баги, которые разрушили ваш замок
- Портируем make.c на D
Вы устали от багов, которые легко сделать и трудно найти, которые часто не всплывают во время тестирования и уничтожают так тщательно построенный вами замок после того, как код ушёл в производство? Снова и снова они стоят вам много времени и денег. Ах, если бы только вы были лучше как программист, то этого бы не происходило, верно?
А может, дело не в вас? Я покажу вам, что эти ошибки не ваша вина: это вина инструментов, и если только улучшить инструменты, то ваш замок будет в безопасности.
И вам даже не придётся идти ни на какие компромиссы.
D как улучшенный C
Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.
- D как улучшенный C
- Баги, которые разрушили ваш замок
- Портируем make.c на D
Язык D был с самого начала спроектирован так, чтобы легко и напрямую обращаться к C и, в меньшей степени, C++. Благодаря этому в нём доступны бесчисленные C-библиотеки, стандартная библиотека C и конечно же системные API, которые как правило построены на API языка C.
Но C — это не только библиотеки. На C написаны многие большие и неоценимо полезные программы, такие как операционная система Linux и значительная часть программ для неё. И хотя программы на D могут обращаться к библиотекам на C, обратное неверно. Программы на C не могут обращаться к коду на D. Невозможно (или по крайней мере очень сложно) скомпилировать несколько файлов на D и слинковать их в программу на C. Проблема в том, что скомпилированные файлы на D могут обращаться к чему-то, что существует только в рантайме D, а добавлять его в линковку обычно оказывается непрактично (рантайм довольно объёмный).
Также код на языке D не может существовать в программе, если D не контролирует функцию main()
, потому что именно так происходит запуск рантайма D. Поэтому библиотеки на D оказываются недоступны для программ на C, а программы-химеры (смесь C и D) становятся непрактичными. Нельзя взять и «просто попробовать» язык D, добавляя модули на D в существующие модули программы на C.
Так было до тех пор, пока не появился Better C.
Go Your Own Way. Часть вторая. Куча
- Don’t Fear the Reaper
- Life in the Fast Lane
- Go Your Own Way. Часть первая. Стек
- Go Your Own Way. Часть вторая. Куча
Мы продолжаем цикл статей о сборщике мусора в языке D. Этот вторая часть статьи, посвящённой выделению памяти за пределами GC. В первой части говорилось о выделении памяти на стеке. Теперь мы рассмотрим выделение памяти из кучи.
Хотя это только четвёртая публикация в этой серии, это уже третья, в которой я рассказываю о способах избежать использования GC. Не обманитесь: я не пытаюсь отпугнуть программистов от сборщика мусора в языке D. Как раз наоборот. Понимание того, когда и как обходиться без GC, необходимо для эффективного его использования.
Ещё раз проговорю, что для эффективной сборки мусора нужно снижать нагрузку на GC. Как уже говорилось в первой и последующих статьях серии, это не значит, что от него нужно полностью отказываться. Это значит, что нужно быть рассудительным в том, сколько и как часто выделять память через GC. Чем меньше выделений памяти, тем меньше остаётся мест, где может начаться сборка мусора. Чем меньше памяти находится в куче сборщика мусора, тем меньше памяти ему нужно сканировать.
Статический анализ в GCC 10
Я работаю в Red Hat над GCC, GNU Compiler Collection. Для следующего основного релиза GCC, GCC 10, я реализовывал новую опцию -fanalyzer: проход статического анализа для выявления различных проблем во время компиляции, а не во время исполнения.
Я думаю, что лучше выявлять проблемы как можно раньше по мере написания кода, используя компилятор, как часть цикла компиляции-редактирования-отладки, а не использовать статический анализ в качестве дополнительного инструмента «на стороне» (возможно, проприетарного). Поэтому, представляется целесообразным иметь встроенный в компилятор статический анализатор, который видит код в точности такой же, какой видит компилятор — ведь это и есть компилятор.
Ближайшие события
wc на D: 712 символов без единого ветвления
Прим.пер. Я предложил вышеупомянутую статью перевести 0xd34df00d, но он предпочел сделать по мотивам свою «Побеждая C двадцатью строками Haskell: пишем свой wc». И теперь статьи множатся как перепевы «чеканной монетой».
Программа
Состоит из одного файла — 34 строки и 712 символов.
import std.stdio : writefln, File;
import std.algorithm : map, fold, splitter;
import std.range : walkLength;
import std.typecons : Yes;
import std.uni : byCodePoint;
struct Line {
size_t chars;
size_t words;
}
struct Output {
size_t lines;
size_t words;
size_t chars;
}
Output combine(Output a, Line b) pure nothrow {
return Output(a.lines + 1, a.words + b.words, a.chars + b.chars);
}
Line toLine(char[] l) pure {
return Line(l.byCodePoint.walkLength, l.splitter.walkLength);
}
void main(string[] args) {
auto f = File(args[1]);
Output o = f
.byLine(Yes.keepTerminator)
.map!(l => toLine(l))
.fold!(combine)(Output(0, 0, 0));
writefln!"%u %u %u %s"(o.lines, o.words, o.chars, args[1]);
}
Topleaked: инструмент ловли утечек памяти
История, как это часто бывает, началась с того, что упал один из сервисов на сервере. Точнее процесс был убит мониторингом за превышение использования памяти. Запас должен был быть многократным, а значит у нас утечка памяти.
Есть полный дамп памяти с отладочной информацией, есть логи, но воспроизвести не получается. То ли утечка безумно медленная, то ли сценарий зависит от погоды на Марсе. Словом, очередной баг, который не воспроизводится тестами, но встречается в дикой природе. Остаётся единственная реальная зацепка — дамп памяти.
Последние версии компиляторов D
Мой опыт разработки на языке Nim
Привет, Хабр!
Уже довольно давно я пишу свой игровой фреймворк — такой pet project для души. А так как для души нужно выбирать что-то, что нравится (а в данном случае — на чём нравится писать), то выбор мой пал на nim. В этой статье я хочу поговорить именно про nim, про его особенности, плюсы и минусы, а тема геймдева лишь задаёт контекст моего опыта — какие задачи я решал, какие трудности возникли.
Давным-давно, когда трава была зеленее, а небо чище, я встретил nim. Хотя нет, не так. Давным-давно я хотел заниматься разработкой игр, чтобы написать свою Самую Классную Игру — думаю, многие проходили через это. В те времена Unity и Unreal Engine только-только стали появляться на слуху и, вроде как, ещё не были бесплатными. Я не стал их использовать, не столько из-за жадности, сколько из-за желания написать всё самому, создать игровой мир полность с нуля, с самого первого нулевого байта. Да, долго, да, сложно, зато сам процесс приносит удовольствие — а что ещё для счастья надо?
Мое видение будущего D
Я все еще вхожу в свою новую роль в обществе и выясняю, как я хочу действовать и что это вообще такое. Этот процесс происходит не в вакууме, так как Уолтер тоже с нами.
На форумах D меня попросили написать в блоге о моих «мечтах и дальнейших шагах для D», так вот результат. Что бы я хотел, чтобы стало с D в ближайшем будущем:
Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
Для начала, где то в вопросе должен фигурировать и C++. Должен ли он быть заменен вместе с С, или же он один из кандидатов на замещение С, но в любом случае С++ это ключевой элемент уравнения. Это ближайший язык к С и очевидный шаг вперед. Учитывая возраст С++, я в дальнейшем полагаю в этом вопросе что С++ вместе с С является целью для замены.
Владение и заимствование в D
Типичными проблемами являются:
- утечки памяти (не освобождение более не используемой памяти)
- двойное освобождение (высвобождение памяти более одного раза)
- использование после освобождения (использование указателя на память, ранее уже освобождённую)
Задача заключается в том, чтобы отслеживать указатели, ответственные за освобождение памяти (т.е.владеющие памятью), и отличать указатели, которые просто указывают на участок памяти, контролировать где они находятся, и которые из них активны (в области видимости).