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 ()

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

Дорогой anon (извини, я тоже anon...)

Если все определять маркетигом, то всем путь известно куда...

А вот Perl - очень крутой язык! Даже Python не смог его вытеснить. А «количеством вакансий» мощь языка не измеряется. Все это маркетинг. На который НЕОБХОДИМО ПЛЮНУТЬ и заниматься свом делом. Если это ВАШЕ дело, а не выброс тролля...

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

И да С - это по локоть в железе, и работает везде.

Допустим, программа вызывает метод write и отправляет мегабайт данных через сокет. То, что программа написана на Си, магическим образом ускоряет интернет? Или одна проверка на границы массива в Расте сделает программу чудовищно тормознутой?

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

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

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

Ну вот я писал не только на Паскале, Питоне и Фортране, но и на Д и Окамле. Например, на Окамле я сделал спектральный анализ и построил рисуночки для: вот этой статьи. На Д я тоже написал программки для пары статей, где нужна была скорость неоптимизированного кода, алгоритм был нестандартный (самописный) и при этом нужно было лопатить много строк, чтобы лазить по директориям для автоматизации усреднения результатаов. Писать работу со строками на Фортране --- адская боль, а на Д считывание и запись текстовых файлов с цифорками делаются быстро и удобно.

Хотя согласен, что Питон чаще всего проще и удобнее.

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

Ну вот я писал не только на Паскале, Питоне и Фортране, но и на Д и Окамле.

Интересно, а опыта в C++ вообще не было?

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

ученые до сих пор на фортране пишут. У нас по крайней мере.

Скорее наоборот, в Европе и США он более распространен чем в РФ. И часто выбор в пользу фортрана более чем разумный, так как это позволяет сразу заняться решением поставленной задачи, а не писать собственные велосипеды вместо кучи готовых и хорошо оттестированных библиотек и программ.

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

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

Ну это совсем примитиваня задача же.

RazrFalcon ★★★★★ ()
Ответ на: насколько мне известно от siropchik

У него нету тридцатилетнего легаси, ака наследие сишки, что уже хорошо. Но D и тут умудрился зафейлить с D1/D2.

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

ты ошибься с контекстом, я нигде там не говорил, что это все на Go, речь была про языки с «gc» в инфраструктуре/сети

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

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

Vudod ★★★★★ ()
Ответ на: насколько мне известно от siropchik

Это зависит от компилятора. Референсный dmd выдаёт сильно неоптимальный код. Если сравнивать gcc, gdc, g++ и gfortran, они дадут сравнимые результаты на задачах, где есть интенсивные арифметические операции над действительнозначными массивами.

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

Во всех приведённых языках управление памятью автоматическое средствами языка или компилятора.

В том числе и в Паскеле, и в Фортране?

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

Да, там все локальные массивы, в том числе динамические, автоматически уничтожаются при завершении процедуры или функции. Это в Фортране даже втащили в стандарт, то ли 2003, то ли 2008 (хотя уже раньше было сделано в основных компиляторах). Во Фрипаскале это свойство компилятора. Там и деструктор тоже автоматически вызывается.

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

Да, там все локальные массивы, в том числе динамические, автоматически уничтожаются при завершении процедуры или функции

Ну это как бэ и в С++ так же. на этом все RAII строится

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

Чем это отличается от std::vector<T> в C++ (доступного, кстати говоря, с 1998-го года)?

Собственно, что непонятно: в C++ инструменты для создания своих матриц/векторов и средств для работы с ними, были доступны из коробки, с 1985-го года. Чем все желающие давным давно и пользовались (даже мы в начале 90-х будучи студентами это делали). Компиляторы оптимизирующие на любой вкус и кошелек. Библиотек и инструментария полно. Казалось бы, бери и пользуйся. Но нет. Нужно подождать D, да еще и чтобы в D экзотические средства работы с матрицами в язык завезли. А все из-за чего? Из-за того, что пару раз в чужой код заглянули и синтаксис с буковками не понравились?

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

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

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

Так я не у вас спрашиваю. Вряд ли вы более 15 лет вычислительными задачами занимаетесь. Если вообще с этим имели когда-нибудь дело.

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

Сейчас в плюсах целая гонка менеджеров зависимостей. И если CMake реально станет де-факто стандартом для системы сборки, то у Conan-а есть шанс стать де-факто стандартом в качестве менеджера зависимостей.

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

Я только за. Но cmake я не перевариваю. Да и объективно он ужасен. Ну и куча либ cmake так и не использует. Может что-то поменяется, но когда...

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

Linux must die! Это знаю я, знаешь ты, знают все адекватные люди.

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

В момент когда ты написал вызов несуществующего метода класса. Во время компиляции будет проверено верен ли написанный в этом шаблоне mixin

За счёт какой магии этот метод вызывается во время компиляции?

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

Во всех приведённых языках управление памятью автоматическое средствами языка или компилятора. Синтаксис более человеческий. Есть нормальные модули.

Тогда может заинтересовать Rust. Там нет явных деструкторов, нет free. Объекты освобождаются автоматически, но при этом нет и сборщика мусора. Такая вот интересная картина.

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

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

А потом получается такое чудо, где добавление 1 параметра компилятору полностью меняет базовые возможности языка и между вариантами общего как между C и javascript.

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

Как нет явных деструкторов? Всё как в цпп, члены класса деструктятся автоматически, а если надо больше - trait Drop.

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

Молодец! Хвалю. Знал, что кто-нибудь прицепиться к неточной фразе.

Как этот товарищ заметил, немного не так написал. Более правильный вариант: «обычно нет необходимости писать явные delete и free»

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

В «современном цпп» с коллекциями и unique_ptr/shared_ptr тоже не сильно поощряется рукоблудие с памятью.

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

Хз про кого, «по делам их судите их». Я вижу результат: это типичное поделие студента, «как в Цпп, только добавим вон то и то, а ещё вот это, а если GC не нужен, то можно отключить, а вот теперь ещё -betterC, который ещё кое что поотключает».

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

Я имел в виду unsafe, но я точно не знаю, как с ним обстоят дела, потому что использовал совсем миллипусенький unsafe. Но думаю, что в unsafe иногда может понадобиться освобождать память явно.

В Си++, конечно, есть. Ты же не думаешь, что все, пишущие на Си++, так разом перешли на RAII и умные указатели. На Си++ пишут от начинающих школьников и студентов до хардкорных профи. Все они пишут очень по-разному

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

Ты же не думаешь, что все, пишущие на Си++, так разом перешли на RAII и умные указатели.

Мне казалось, всё перешли ещё в 90-х.

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

man мультипарадигмальность

man Химера

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

Учитывая что у D есть D1/D2/gc/nogc/betterc/dmd/ldc/gdc, то есть шанс, что его ждёт та же участь. Правда пользователей у него раз в тысячу меньше, чем у C++.

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

Писать работу со строками на Фортране --- адская боль, а на Д считывание и запись текстовых файлов с цифорками делаются быстро и удобно.

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

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

Правда пользователей у него раз в тысячу меньше, чем у C++

тысячу? думаю ты сильно преуменьшил, а участь не ждет, надо что бы больше людей использовали ;)

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

поэтому вот в каждой компании свой C++ ?

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

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.