LINUX.ORG.RU

Вышла новая версия языка программирования D (2.091.0 )

 ,


2

7

Изменения в компиляторе:

* Окончательно убран деаллокатор классов
* Возможность сообщать о номерах строк в стиле GNU  
* Добавлена экспериментальная генерация заголовочников C++  из внешних (extern) объявлений C|C++: DMD теперь умеет писать заголовочные файлы C++, содержащие биндинги на объявления в существующих файлах D, помеченных как extern(C) или extern(C++).

Изменения в рантайме:

* Добавлен пропущенный в некоторых местах pthread_attr_destroy .
* Расширенный биндинги в core.sys.windows.security
* Добавлен core.stdcpp.memory.unique_ptr
* Добавлен TFD_TIMER_CANCEL_ON_SET.

Изменения в библиотеке:

* std.bigint теперь @safe
* Замена approxEqual на isClose в std.math.
* Удалён устаревший std.format.Mangle.
* Удалены устаревшие структуры ByLine, ByChunk, ByRecord из std.stdio.
* std.algorithm.sorting.schwartzSort теперь поддерживает и бинарные функции трансформации
* Добавлена curry в std.functional

Изменения в инсталляторе:

* Скрипт инсталляции теперь может исполняться на Windows

Изменения в Dub:

* Добавлена переменная окружения SOURCE_FILES
* У DUB теперь стиль дополнения zsh

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

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

Аллокатор встроенный в класс их не рекомендовали использовать еще когда я начал знакомиться с D

Вы не про перегрузку операторов new/delete случаем? Потому что их давно удалили

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

Не так. Раньше было так: ```D auto obj = new Object; // или GC или аллокатор класса delete obj; // или GC или деаллокатор класса ``` Узнать точно, что конкретно было использовано можно было только проверив код. Теперь этот код означает что однозначно использовался GC.

Вызывать `destroy` уже давно рекомендуется, я давно не видел использования `delete` в дишном коде.

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

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

Вы не про перегрузку операторов new/delete случаем? Потому что их давно удалили

Так насколько я помню это же одно и то же. Методы new/delete у класса и есть аллокатор/деаллокатор класса - документация.

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

так это уже дано выковыряли, я ещё в 2018 пытался перегрузить данные операторы и обломался.

Вообще я в основном использую структуры и все размещаю на стеке.

Было же scope auto obj = new Object (или скоуп был перед new?) для аппликации класса на стеке.

Если бы у структур еще было наследования я бы классы

alias this мне советовали как костыль, но вот ни дефолтного конструктора, ни виртуальных методов это не даёт. Хз зачем в D решили так переусложнить классы и отнять у структур конструктор

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

По поводу @nogc из документации я нашел вот это @nogc functions.

Ну а так это просто атрибут, который запрещает компилятору компилировать код, который использует сборщик мусора. Тут ничего сложного нет. Некоторая сложность есть в использовании шаблонного кода. А в D очень много метапрограммирования, потому что оно простое и поэтому доступно даже новичкам. Так вот, атрибуты шаблонного кода компилятор выводит по конкретному инстанционированию, обычно шаблонный код не содержит атрибуты в явном виде (при необходимости их добавить конечно можно) и понять является ли этот шаблонный код @nogc можно только инстанционированием с конкретными типами/выражениями.

Насчет того, какая часть Phobos еще не поддерживает @nogc - там народ где-то публиковал перечень где сборщик мусора используется явно, но я не подскажу сейчас где это лежит.

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

По поводу шаблонного кода - функция из фобоса может вообще во время компиляции отработать и никакого GC на выходе в этой функции не будет, но собрать с @nogc или -betterC не получится.

SR_team ★★★★ ()
Ответ на: комментарий от SR_team
scope auto obj = new Object;

Да, так и было. auto можно убрать.

scope obj = new Object;

В D auto означает то же что и в С - автоматический выбор памяти, раньше можно было выбирать ближняя/дальняя память или что-то в этом роде, я застал только упоминания об этом. И спецификатор auto в С разрешал компилятору автоматически выбирать какую память использовать. Сейчас уже нет необходимости такого выбора и по факту auto не несет никакой нагрузки, а просто placeholder. Это не указание на вывод типов как в C++, поэтому на плюсах мы пишем:

const auto foo = 1;

а на D достаточно:

const foo = 1;

scope решил задеприкейтить в угоду scoped из фобоса. Но похоже scope останется и его еще доработают. Хотя scoped работает без проблем.

alias this мне советовали как костыль, но вот ни дефолтного конструктора, ни виртуальных методов это не даёт.

alias this довольно удобная штука, но да, полноценной заменой наследования она не является.

Хз зачем в D решили так переусложнить классы и отнять у структур конструктор

Так структуры это value types, а классы reference ones. В этом довольно много логики. Просто многие детали вскрываются после многолетней эксплуатации, тут ничего не поделаешь.

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

функция из фобоса может вообще во время компиляции отработать и никакого GC на выходе в этой функции не будет, но собрать с @nogc или -betterC не получится.

А по какой причине то? Можно пример?

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

структуры это value types

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

SR_team ★★★★ ()
Ответ на: комментарий от yetanother
import std.string;

version (Windows){
	import core.sys.windows.windows;
	extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID){
		return true;
	}
}

export extern (C) const(char*) gameSym(size_t pointer){
	enum file = import("names.txt");
	enum funcs = file.splitLines;
	static foreach(i, func; funcs){
		mixin("enum info_"~i.stringof~"=func.split(\": \");");
		mixin("auto addr_"~i.stringof~"=0x"~mixin("info_"~i.stringof~"[0]")~";");
		static if (i > 0)
			if (pointer <= mixin("addr_"~i.stringof))
				if (pointer >= mixin("addr_"~mixin(i-1).stringof))
					mixin("return info_"~mixin(i-1).stringof~"[1];");
	}
	return "";
}
SR_team ★★★★ ()
Ответ на: комментарий от yetanother

Не очень точно сформулировал вопрос:имел ввиду поддержку аллокаторов, которые выделяют память не через gc. В основном интересует raii подход из c++ через умные указатели.

Про шаблоны спасибо, не знал(только присматриваюсь к языку)

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

Ну я этот кусок кода вообще скомпилировать не могу и с @nogc, и без. Какое содержание хоть у «names.txt»?

Кстати, вместо " \" " удобно использовать " ' ", тогда это:

"=func.split(\": \");"

будет

"=func.split(': ');"
yetanother ()
Ответ на: комментарий от IceRain

имел ввиду поддержку аллокаторов, которые выделяют память не через gc

А, это уже более конкретный вопрос. Тут уже да, аллокаторы фобосом поддерживаются хуже, чем @nogc. Сложного в этом нет ничего, это просто должен кто-то сделать. Пока пошли по пути использования дополнительных пакетов вместо переделки Фобоса. Обычно используют тот же `automem` или `emsi_containers`

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

А вообще там 40к строк

Да несколько строк уже хватит. Вообще у меня этот код компилируется https://run.dlang.io/is/JJL484

Может там еще какой-то код есть?

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

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

Это весь код. 2 месяца назад не компилировался из-за сплитов (компилирую ldc)

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

врядли, import же просто подставляет массив символов, так что должно быть эквивалентно

UPD: Вот с -betterC не собирается:

/dlang/ldc-1.21.0/bin/../import/std/array.d(3223): Error: TypeInfo cannot be used with -betterC
SR_team ★★★★ ()
Последнее исправление: SR_team (всего исправлений: 2)
Ответ на: комментарий от SR_team

Чтобы точно проверить собирается или нет нужен полноценный проект.

Насчет betterC это уже другой вопрос, это уже подмножество языка и там задуманно изначально, что часть фич не работает. Это подмножество было введено для упрощения портирования на другие архитектуры потому что не требует никакого рантайма. Если вы не портируете D на другую архитектуру, то нет особого смысла использовать этот режим, имхо.

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

не требует никакого рантайма

А какой рантайм требует код из 2х функций, обмаанных @nogc, одна из которых пустая, а другая жонглирует константами и полученным числом?

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

А какой рантайм требует код из 2х функций, обмаанных @nogc, одна из которых пустая, а другая жонглирует константами и полученным числом?

Так вот же компилятор говорит: ``` /dlang/ldc-1.21.0/bin/../import/std/array.d(3223): Error: TypeInfo cannot be used with -betterC ```

TypeInfo это рантайм.

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

1.4 жабакод превратился в тыкву, меньше писать на жабе не стали

Семантически и синтаксически со времен java 1.1 ничего не поменялось. Java код в тыкву не превращается, код написанный для java 1.1 будет собираться и работать на java 13. А вот если ты использовал не стандартный classpath а что-то из системное для взаимодействия с JVM, типа классов из sun.misc то там гарантий не было, и такой софт периодически ломается от смена мажерных версий. В стандартном classpath ничего до сих пор не удалили, устаревшие методы пометили deprecated, но обещают начать удалять.

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

Да, и он вроде даже притащит его в бинарник, вот только он нигде не используется.

Верно, и поэтому рантайм помаленьку переписывают на шаблоны, чтобы не тащить то, что не нужно. И это сделает betterC не нужным. Но пока то, что имеем.

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

Глупости, 2 питон превратился в тыкву и что меньше стали писать?

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

DarkEld3r ★★★★★ ()

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

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

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

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

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

D - непростой язык.

Ну вроде как даже старичек С++ запутаннее на порядок. А если взять раст или хаскель с агдой, то впору вешаться. Интересно насколько Д сложнее того же паскаля?

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

В своем творчестве я в Д необходимости не вижу, следовательно и в зиге тоже большого выигрыша для меня нет. Хотя есть сферы где зиг рвет раст как тузик грелку, например в вебасме. Короче если наберем достаточно юзкейсов, можно будет раскрутить комьюнити и взлететь помаленьку. Вон например язык кристалл на первый взгляд тоже не особо поддерживаемый, а реально кодить на нем можно уже давно как, пакетов насобиралось малёхо. Кстати тоже простой для понимания компилируемый язык, чем не альтернатива Д. Некоторые фанатики правда носятся с языком ним, но по мне так кристалл гораздо лучше.

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

Ну вроде как даже старичек С++ запутаннее на порядок. А если взять раст или хаскель с агдой, то впору вешаться. Интересно насколько Д сложнее того же паскаля?

В D шаблоны равномощные шаблонам C++, так что никакой простотой уровня паскаля даже не пахнет. Это сложный язык уровня раста, С++ и хаскеля.

anonymous ()