LINUX.ORG.RU

Релиз D 2.076.0

 ,


1

6

Команда разработчиков D с великим удовольствием объявляет о выходе новой стабильной версии DMD: 2.076.0

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

Поддержка static foreach

import std.conv: to;

static foreach(i; 0 .. 10)
{

    // ‘static foreach’ не добавляет вложенной области видимости
    // (так же как и в ‘static if’).
    
    // следующее объявление mixin находится в области видимости модуля
    mixin(`enum x` ~ to!string(i) ~ ` = i;`); // объявляет десять переменных x0, x1, …, x9..., x9
}

import std.range: iota;
// все типы по которым можно итерироваться обычным ‘foreach’
// так же поддерживаются ‘static foreach’
static foreach(i; iota(10))
{
    // используем объявления сгенерированные ранее в 'static foreach'
    pragma(msg, "x", i, ": ", mixin(`x` ~ to!string(i)));
    static assert(mixin(`x` ~ to!string(i)) == i);
}

void main()
{
    import std.conv: text;
    import std.typecons: tuple;
    import std.algorithm: map;
    import std.stdio: writeln;

    // у 'static foreach' есть две формы: объявление и инструкция
    // (так же как у 'static if').
    static foreach(x; iota(3).map!(i => tuple(text("x", i), i)))
    {
        // создает три локальных переменных x0, x1 и x2
        mixin(text(`int `,x[0],` = x[1];`));

        scope(exit) // внутри области видимости 'main'
        {
            writeln(mixin(x[0]));
        }
    }
    
    writeln(x0," ",x1," ",x2); // результат выполнения
}

Улучшения -betterC

Много улучшений было добавлено к новой опции компилятора dmd -betterC, программы скомпилированные с -betterC не будут ссылаться на неиспользуемые части рантайм, asserts реализованы как C <assert.h> вызовы, а phobos (прим. пер. стандартная библиотека) не слинкована по умолчанию.

Хотите знать больше про Better C? Вам сюда.

Добавлена поддержка AVX2

Компилятор теперь может генерировать инструкции AVX2. Поддержка автоматически распознается с помощью -mcpu=native.

Изменения в стандартной библиотеке

std.base64.Base64URLNoPadding позволяет кодирование/декодирование без смещения

import std.base64 : Base64URLNoPadding;

ubyte[] data = [0x83, 0xd7, 0x30, 0x7b, 0xef];
assert(Base64URLNoPadding.encode(data) == "g9cwe-8");
assert(Base64URLNoPadding.decode("g9cwe-8") == data);

std.digest.digest переименовано в std.digest.

std.meta.Stride добавлен, позволяет выбрать подмножество шаблона по размеру шага и отступу

alias attribs = AliasSeq!(short, int, long, ushort, uint, ulong);
static assert(is(Stride!(3, attribs) == AliasSeq!(short, ushort)));
static assert(is(Stride!(3, attribs[1 .. $]) == AliasSeq!(int, uint)));

Был добавлен Config.detached флаг для spawnProcess, он позволяет запускать новые процессы независимо от текущего процесса. Нет нужды ждать их завершения, ведь они никогда не станут зомби процессами! Попытки вызвать std.process.wait или std.process.kill на обособленом процессе бросит исключение.

Теперь можно использовать std.range.chunks с непрямыми диапазонами, но с ограничениями, налагаемыми этими диапазонами.

import std.algorithm.comparison : equal;

int i;

// генератор не сохраняет состояние, так что он не может быть прямым диапазоном
auto inputRange = generate!(() => ++i).take(10);

// мы все еще можем его обработать по частям, но только за один проход
auto chunked = inputRange.chunks(2);

assert(chunked.front.equal([1, 2]));
assert(chunked.front.empty); // итерация по чанку сьедает его
chunked.popFront;
assert(chunked.front.equal([3, 4]));

Теперь std.socket.UnixAddress поддерживает абстрактные адреса. UNIX сокеты обычно идентифицируются по пути. Linux поддерживает непереносимое расширение этой схемы, известное как абстрактный адрес сокета, которое независимо от файловой системы. Начинается абстрактный адрес с нулевого байта.

auto addr = new UnixAddress("\0/tmp/dbus-OtHLWmCLPR");

Добавлена возможность использовать базовый класс когда производится автоматическая реализация интерфейса. Второй шаблон std.typecons.AutoImplement был добавлен, в отличии от существующего он принимает дополнительный параметр. Этот параметр позволяет уточнить класс от которого наследуемся во время автоматической реализация интерфейса.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 11)

Ответ на: комментарий от RazrFalcon

То есть, подытожим. Выбор языка с прямым контролем памяти связан не с этой самой памятью, а с Qt библиотекой (ее предпочтением)?

wist512
()
Ответ на: комментарий от wist512

Для меня - да.

Rust мне просто нравится. GC/noGC тут не при чём.

RazrFalcon ★★★★★
()
Ответ на: комментарий от ckotinko

это немного сложнее

Вопрос не только в сложности, но и в том насколько это взлетит

NextGenenration ★★
()
Ответ на: комментарий от DarkEld3r

Каким бы замечательным не был язык, если (например) единственная реализация компилятора в половине случаев падает

Пробовал? Или на чём основаны соображения?

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

Я немного криво процитировал, отвечал на вот это:

В том что он не взлетел виноваты именно те кто берут только кресты/си и не хотят брать ничего нового

Суть в том, что к «чему-то новому» есть определённые требования даже если мы готовы вкладываться в допиливание.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

отсюда:

1 февраля 2003 г. Космический шаттл Columbia сгорел при входе в атмосферу на высоте порядка 62 километров над территорией штата Техас. Все семеро астронавтов, находившихся на борту челнока, погибли. Вероятно, что одним из косвенных виновников катастрофы стала программа MS PowerPoint, используемая в NASA для подготовки красивых презентаций.

запятая или дефис в программе на фортране

тут тут integer overflow в программе на Ада

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

а вы тут про исключения в деструкторах и UB 'by design'.

в других примерах, сравнения той же Modula/Oberon-2 и стандартов кодирования (была где-то здесь статья про то, что язык устраняет целый класс ошибок, сравнение с С/C++ code style)

хрупкий, избыточно сложный язык с UB by design — который согласно стандарту можно применить неправильно — должен быть выпилен.

ибо найдётся некто, кто таки применит всё неправильно.

и главное, не было бы других альтернатив — нужно было бы мучаться и жрать кактус С++.

но ведь они есть.

anonymous
()
Ответ на: комментарий от Vudod

Напоминает лозунги Чубайса и Гайдара: когда нужно переводить экономику на конкурентные рельсы, альтернатив шоковой терапии нет. Сталин: когда нужно проводить в стране индустриализацию, альтернатив ГУЛАГу нет.

альтернативы есть, но чубайсики с гайдарчиками в силу врождённого либерализма головного мозга их ниасилили.

например, МПЭ = «метод повышения эффективности» раз два

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

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

за счёт более продуманной системной архитектуры решения.

anonymous
()
Ответ на: комментарий от anonymous

чубайсики с гайдарчиками в силу врождённого либерализма головного мозга

ты действительно думаешь, что эти враги по глупости творили то, что творили?

ckotinko ☆☆☆
()
Ответ на: комментарий от anonymous

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

«вот же ж дураки, разве ж можно нас так с говном мешать?»

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

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

гордыня (я ну уж точно не дурак же!) — это грех.

anonymous
()
Ответ на: комментарий от RazrFalcon

Исключения не библиотечная фича. При чём тут они?

при рантайме.

Или вы про рантайм?

про него, родимого. и его зависимости, явные и неявные.

Так он и у С есть.

но у Си рантайма неявных зависимостей меньше. фактически, это только _atexit, сигналы, обёртка вокруг main для прокидывания argc, arcv, env

в С++ добавляются: реализация исключений. реализация конструкторов/деструкторов. деструктор в исключении, UB во все поля — это багофича С++

реализация VMT. реализация наследования, полиморфизма, инкапсуляции. C++ ABI с манглингом и без рефлексии. virtual, который тупой компилятор не может сам вывести.

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

даже если взять какой-нибуть HLA с нормальной символьной таблицей, позволяющей строить рефлексию и с более-менее полноценным языком времени компиляции, CTFE макросами

-- уже на этом можно строить многое, и погибче, и пофичастее — чем в С++.

ООП и что-то наподобие VMT, кстати, там тоже есть. но при этом — нормальный язык макросов высокого уровня, основанный на рефлексии и СTFE функциях.

стоит напистать простой хелловорд на С++ с cout<<«hello»<<endl, как уже неявно ты прилинковываешь конструктор и деструктор cout, VMT всех таких объектов, реализацию исключений и прочие зависимости — более тяжёлого рантайма, чем в языках, где можно обойтися безъ онаго.

например: rust, nim, да тот же C или dmd -betterC, наконецъ.

anonymous
()
Ответ на: комментарий от anonymous

деструктор в исключении, нетранзитивность константности (в отличие от immutable), убогая рефлексия by design — это имманентные проблемы С++, устранить которые принципиально невозможно.

anonymous
()
Ответ на: комментарий от anonymous

rust рантам не меньше, чем у C++, ибо есть паники, деструкторы, манглинг и прочие прелести.

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

в этом смысле, минимальный рантайм раста и минимальный рантайм С, --betterC — разные.

потому что у раста другая модель памяти (с корутинами) и семантика (с паникой, владением/одалживанием, контролем lifetimes и т.п.).

anonymous
()
Ответ на: комментарий от anonymous

с корутинами

Их там нет.

владением/одалживанием, контролем lifetimes

Это всё делается в статике. На рантам это никак не влияет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

rust рантам не меньше, чем у C++, ибо есть паники, деструкторы, манглинг и прочие прелести.

здесь надо смотреть в сторону каких-то kernel OS на расте с более минималистичным рантаймом, если кто-то сподобился.

но в целом, разные модели памяти => разные зависимости времени выполнения и времени компиляции => рантаймы разные. и компайлтаймы.

anonymous
()
Ответ на: комментарий от anonymous

убогая рефлексия by design — это имманентные проблемы С++, устранить которые принципиально невозможно.

Почему? Вернее, не так - речь об рантайм рефлексии? Просто рефлексия на этапе компиляции вполне возможнa и закроет большинство применений.

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

манглинг

Это часть рантайма, по твоему? Опять же, есть #[no_mangle].

То есть _main раста сразу создаёт доп поток, в котором уже запускается обычный main.

Можешь показать пруф?

Опять же, есть #![no_main].

DarkEld3r ★★★★★
()
Ответ на: комментарий от Vudod

Есть Ада.....компилируемый.....имеющий гораздо более высокую надёжность

Извиняюсь, что так процитировал, но мне интересно чем именно язык Ада более надежный?

ult
()
Ответ на: комментарий от DarkEld3r

Это часть рантайма, по твоему?

Я цитировал анона, который отнёс это к рантайму.

Опять же, есть #[no_mangle].

Который не работает без extern «C»?

Можешь показать пруф?

Пример не найду, смотрел через valgrind.

Опять же, есть #![no_main].

И? По умолчанию поведение такое как я описал.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Который не работает без extern «C»?

С какой стати?

Пример не найду, смотрел через valgrind.

(Сейчас) проверять лень, но звучит очень странно. Для обработки паники «ещё один поток» точно не нужен иначе panic::catch_unwind не работал бы.

И?

И то, что есть «стандартный» способ это отключить.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

С какой стати?

Ок. Типа работает:

#[no_mangle]
pub fn do_stuff<T>(v: T) {}

warning: functions generic over types must be mangled
  --> src/main.rs:14:1
   |
14 | pub fn do_stuff<T>(v: T) {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(no_mangle_generic_items)] on by defaul

(Сейчас) проверять лень, но звучит очень странно.

Возможно я неправильно это трактую, но выглядит это так: https://itmages.ru/image/view/6105495/6f3a2702

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

warning: functions generic over types must be mangled

Ну а как оно могло бы работать в этом случае? (:

Возможно я неправильно это трактую, но выглядит это так: https://itmages.ru/image/view/6105495/6f3a2702

Посмотрел вот тут и вижу использование Thread::new о котором в доке написано следующее:

Used only internally to construct a thread object without spawning

Так что, насколько я понимаю, новый поток всё-таки не создаётся.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Ну а как оно могло бы работать в этом случае? (:

Ну так я и говорю, что no_mangle работает только для частных случаев.

Посмотрел вот тут

То что нужно. Может и не создаёт поток, но это именно что рантайм. Которого в том же C/C++ не будет. Как минимум в C++ мы сразу попадаем в main.

RazrFalcon ★★★★★
()

[специально захожу в тред про <любой язык погроммирования>, чтобы почитать про rust]

geek ★★★
()
Ответ на: комментарий от RazrFalcon

Ну так я и говорю, что no_mangle работает только для частных случаев.

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

Может и не создаёт поток

Совершенно точно не создаёт.

Как минимум в C++ мы сразу попадаем в main.

Ха-ха.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

С дженериками это всё равно не работало бы, так что тут никакой трагедии нет.

При чём тут трагедии? Я не говорил что это плохо.

Ха-ха.

Не нужно придираться к словам. Как минимум на лине, прога на C++, выполняет намного меньше телодвижений перед входом в main, чем rust.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Как минимум на лине, прога на C++, выполняет намного меньше телодвижений перед входом в main, чем rust.

Можно поспорить. В расте, как мне кажется, в целом меньше глобальных объектов, которые как раз перед main инициализировать надо.

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

А какие глобальные объекты у нас есть в C++?

cout, например. Но я говорил о том, что в средней плюсовой программе с большей вероятностью будут глобальные объекты.

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

А я говорил про main.

Ну так инициализировать глобальные объекты надо до main, а речь ведь и шла о коде, который выполняется до входа в main.

Да и почему в rust'е не быть глобальным объектам?

Как только требуется что-то нетривиальное - начинаются «ограничения языка». Начиная с «calls in statics are limited to struct and enum constructors».

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

Так я, вроде, открытым текстом говорил: в С++ «телодвижений до main» происходит, как минимум, не меньше.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

убогая рефлексия by design — это имманентные проблемы С++, устранить которые принципиально невозможно.

Почему? Вернее, не так - речь об рантайм рефлексии? Просто рефлексия на этапе компиляции вполне возможнa и закроет большинство применений.

есть интроспекция времени выполнения и интерцессия времени компиляции. соответственно, и рефлексия разная. интерцессия в С++ убога, ибо отсутствует тайпинфо. и либо его приходится делать руками (пример: ООСУБД GOODS, карты сообщений в MFC, Boost), тот же Qt с рефлексией, или расширять рантайм (пример: C++ Builder, кстати, в Delphi/Object Pascal рефлексия менее убогая ибо есть методы класса, класс это тип и по нему возможна рефлексия)

Просто рефлексия на этапе компиляции вполне возможнa

теоретически. практически всем лень писать обвёртки. опять же, вопрос в том, как работает рефлексия уровня компиляции и уровня выполнения. в идеале, это один и тот же язык, и компилятор доступен как библиотека. потому что нет нечётких, неявных мест.

и закроет большинство применений.

но не все. вообще, делать два языка времени выполнения, а не один прозрачный и что-то типа std.compiler — неправильно для макросов и прозрачности их написания.

в идеале, что-то типа nim/rust/D «с минималистичным рантаймом»:

1. GC отстреливаемый или заменяемый заглушкой.

2. GC написан не на С, а на самом языке. и является библиотекой или модулем, от которого можно отказаться. например, как некоторые реализации Modula-2 или Oberon-2, где реализации пулов, аллокатора, GC можно было перекрыть своими или отказаться вообще.

3. фичи подмножеств языка райнтайм и компайлтайм в каком-то смысле, «ортогонализированы»: минимум зависимостей от фич подъязыка рантайма в подъязыке - компайлтайма.

ну например, в том смысле, что в D если отстрелить Gc, перестают работать строки, тайпинфо, и многие вещи. и есть библиотека tanya, например, которая явно написана как @nogc, и выделяет память вручную. в духе контейнеров в Delphi, или того же Ultimate++ с RAII в С++.

в этом смысле, лисп написанный на лиспе рулит вообще всё. ну или тот же nim с AST макросами.

4. остальные фичи реализованы опционально, как модули или библиотеки языка. и написаны на себе самом. то есть, их в принципе можно отстрелить.

типа корутин или GC на само себе, или макросов, или мемори пула vs. GC.

5. модель памяти. когда читал её 3-4 года назад про раст (ещё когда корутины были), понравилась тем, что была продумана для конкурентности и асинхронности.

anonymous
()
Ответ на: комментарий от DarkEld3r

В расте, как мне кажется, в целом меньше глобальных объектов, которые как раз перед main инициализировать надо.

5. модель памяти. когда читал её 3-4 года назад про раст (ещё когда корутины были), понравилась тем, что была продумана для конкурентности и асинхронности.

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

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

anonymous
()
Ответ на: комментарий от anonymous

но такой вот ситуации как в С++ когда бросаешь исключение в деструкторе и в двадцатом треде лайвлоки (эпический тред на лоре от лавсана с ручным вызовом деструктора) — в принципе не должно быть

В расте точно также паника при дропе объекта оборвет процесс. Потому как нет правильного поведения - надо либо забить на вторую панику, либо упасть.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.