Синхронизированы версии компиляторов языка D (dmd, ldc) и gcc: D 2.098 теперь в gcc

В VS Code есть плагины, в принципе, работает.

Когда еще копался с D плагин для VS (не code) Visual D был вполне не плох, он еще живой?

Нечитаемый != непонятный.

Когда еще копался с D плагин для VS (не code) Visual D был вполне не плох, он еще живой?

Кто использует Visual D, говорят что он очень даже неплох. Я то под виндами не сижу, не знаю. вскоуд не фонтан конечно, но работает, включая отладку

А при этом деструкторы будут зваться на выходе из скоупа? Проблема языков с GC в невозможности работать в парадигме RAII

А при этом деструкторы будут зваться на выходе из скоупа? Проблема языков с GC в невозможности работать в парадигме RAII

Смешались в кучу кони, люди (с)

фсб4000 писал о том, что в D можно временно отключить сборщик мусора, чтобы гарантировать отсутствие пауз, а когда пауза допустима можно включить гц и запустить сборку мусора. Это одно.

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

Да, аноним всё правильно расписал.

Для RAII есть структуры. И они не используют GC.

А у классов деструкторы выполнятся в какое-то неопределенное время, когда их GC вызовет.

https://dlang.org/spec/class.html#destructors

The garbage collector calls the destructor function when the object is deleted

https://dlang.org/spec/struct.html#struct-destructor

Struct Destructors are called when an object goes out of scope.

CLion работает медленнее чем vscode + clangd, и значения enum не показывает. Какие вы у него преимущества нашли я хз - под капотом он тоже clangd использует.

P.S. Ещё у CLion с рефакторингом все плохо:

1. Нет интеллектуального изменения сигнатуры функций как в QtCreator, только через убогое окошко или руками.
2. Если есть 2 класса и у каждого есть поле address, а потом в одном из них вы решили добавить условный fallbackAddress и переименовать address в mainAddress, то Clion переименует его в обоих классах, а иногда еще и в системные хидеры залезть попытается.

Так что CLion является лучшей IDE для C++ только во влажных мечтах JetBrains

Проблема языков с GC в невозможности работать в парадигме RAII

Это только в плюсах RAII привязан к управлению памятью. В языках с GC свои RAII, по крайней мере у некоторых.

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

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

Вот бы код посмотреть. Сейчас даже на хайпорасте МКшное программирование только зарождается – мало проектов для примеров.

Короче, это РАЗНЫЕ инструменты

С чего вдруг? Оба языка претендуют на языки общего назначения, т.е. универсальные.

Вот бы код посмотреть. Сейчас даже на хайпорасте МКшное программирование только зарождается – мало проектов для примеров.

Что прямо вообще примеров мало или мало примеров крупных успешных проектов? Потому что просто проектов и для Ди много. Австралиец один софт для АКПП написал, из последнего что помню. Ну и ездит он естественно на этой машине. На дишной вики вот еще нашел - Minimal semihosted ARM Cortex-M Hello_World.

Так что CLion является лучшей IDE для C++ только во влажных мечтах JetBrains

Мне кажется, что JetBrains яркая иллюстрация что на языках с активным, я бы сказал тяжелым, использованием гц отзывчивое приложение очень сложно построить. В D совсем другая модель использования сборщика мусора. Хотя понятно почему людей отпугивает сборщик мусора - они боятся что у них получится такое же тормозное поделие как у JebBrains, несмотря на то, что в JetBrains работают высококлассные спецы.

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

Смешались в кучу кони, люди (с)

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

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

В плюсах тоже при выходе указателя из скоупа деструктор не вызывается

Не аргумент, в ObjC с ARC вызывается, хотя там тоже голые указатели. При этом в шланге для плюсов для ARC всё есть: при статическом анализе кода он способен разглядеть утечки, но в стандарт такое, конечно же, не примут. А жаль - полностью убирает оверхед от шаредпойнтеров в компайл-тайм

///Я выучил японский, перехожу к Хинди, потом Иврит, далее русский.

И? Если в ангельском нет падежов, то вам придётся изучать их, если изучать славянские. В ангельском практически нет приставок и суффиксов, всего 2 окончания, зато 23 времени.

Потому изучать естественный язык, начиная с формальной грамматики бесполезно. Но ЯП – искусственно созданные языки для одной и той же задачи, реализующие одни и те же парадигмы программирования, базовые алгоритмы и типы данных.

P.S. Можно свободно говорить по-русски, даже не подозревая, что в нём 18 падежов. или Падёжов. Нельзя свободно программировать, не зная, что такое ветвление и цикл.

Короче, это РАЗНЫЕ инструменты

С чего вдруг? Оба языка претендуют на языки общего назначения, т.е. универсальные.

Мало ли кто что на что претендует? Мало ли кто претендует на короля ловкости, а по жизни — жирное чудовище?

По факту надо смотреть.

А при этом деструкторы будут зваться на выходе из скоупа? Проблема языков с GC в невозможности работать в парадигме RAII

Про структуры уже ответили, самоочевидный метод.

А вообще. RAII можно реализовать по разному,

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

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

Можно извернуться через static opCall()

Наконец, даже так:

void ДелайЗакрывая (scope void delegate () action) { lockSomething(); scope(exit) unlockSomething(); action(); }

int main () { int i = 42;

ДелайЗакрывая( { i.writeln; } ); }

написать shared_ptr на структуре, который будет вручную убивать лежащий внутри него класс

Вот если я всё правильно понял, и память мне не изменяет, то ты не можешь просто удалить объект. Ты можешь только пометить его как «вот этого в мусор». А только сборщик потом почистит память. Но я могу ошибаться. Если надумаешь пользоваться этим методом, то обязательно обрати внимание на все нюансы удаления объекта.

Это не то, ты using переизобретаешь

Её нельзя будет даже случайно скопировать

А что, в D явным образом копиконструкторы нельзя запретить?

Язык, претендующий на роль системного, но без возможности явного освобождения памяти? Оксимирон какой-то

Ну претендовать-то кто угодно на что угодно может.

Там есть подмножество, работающее без гц.

RAII (yes, it can work without exceptions)

Но и многих возможностей нет:

• Garbage Collection
• TypeInfo and ModuleInfo
• Classes
• Built-in threading (e.g. core.thread)
• Dynamic arrays (though slices of static arrays work) and associative arrays
• Exceptions
• synchronized and core.sync
• Static module constructors or destructors

https://dlang.org/spec/betterc.html

Язык, претендующий на роль системного, но без возможности явного освобождения памяти? Оксимирон какой-то

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

В общем, не порите чушь, господа.

Не нужно путать betterC и nogc. betterC это подмножество языка, которому не требуется библиотека времени выполнения. А nogc это подмножество языка, которое не использует сборщик мусора. Это разные вещи, хотя и пересекаются.

А то у тебя получается, что без гц недоступна Garbage Collection - масло же масляное. В betterC, кстати, можно использовать плюсовые классы - extern(C++) class Foo, эти классы не требуют рантайма. Можно использовать системные потоки. Слайсы работают полностью (не важно статический или динамический массив) за исключением увеличения размера больше чем текущая емкость массива - для этого нужен рантайм.

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

Понял ты 50 на 50 правильно. Ты можешь просто удалить объект, все как в плюсах. Ты можешь деструктор вызвать в любой момент. А вот освобождение памяти зависит от того менеджера памяти, который ты используешь.

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

Прям совсем-совсем полностью статически не получится.

Не нужно путать betterC и nogc.

Понял ты 50 на 50 правильно. Ты можешь просто удалить объект, все как в плюсах.

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

Понял ты 50 на 50 правильно. Ты можешь просто удалить объект, все как в плюсах. Ты можешь деструктор вызвать в любой момент. А вот освобождение памяти зависит от того менеджера памяти, который ты используешь.

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

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

? - Забыл знак.

В теме уже писали, что D активно используется для программирования микроконтроллеров. Ну какой там может быть GC? И опять пошли по второму кругу - язык тормозной, в нём нельзя освобождать память. Кстати есть языки с GC, которые используются, чуть ли не в процессах реального времени, например luajit - но даже там возможно вручную управлять памятью, хотя это обычный динамический язык.

D - лишний повод вспомнить о C.

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

«Изложение большого куска учебного материала занимает одинаковое время вне зависимости от выбранного подхода». Различаться может только вовлечённость учащихся и их понимание материала в зависимости от.

Начинать с абстрактного ассемблера смысла нет. Начинать надо с того ЯП, который уже на 2й половине первой пары позволит учащимся самим написать прогу более сложную, нежели «Прощай, програмитроаание». И позволить пойти в обучении дальше, до ссылок, ассемблера и собственной БД.

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

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

https://run.dlang.io/is/Fvm47Y

import std;

class Foo
{
    this()  { writeln(__PRETTY_FUNCTION__); }
    ~this() { writeln(__PRETTY_FUNCTION__); }
}

// По факту объект создается на стеке
void usingScope()
{
    scope foo = new Foo();
    writeln(cast(void*) foo);
}

// То же самое практически что и выше, но 
// силами стандартной библиотеки, а не 
// средствами языка
void usingScoped()
{
    auto foo = scoped!Foo();
    writeln(cast(void*) foo);
}

// Полностью ручной вариант.
// Здесь мы явно выделяем массив на стеке, достаточный для
// размещения объекта и затем создаем экземпляр класса
// в этом массиве
void usingEmplace()
{
    ubyte[__traits(classInstanceSize, Foo)] chunk;
    auto foo = emplace!Foo(chunk);
    writeln(cast(void*) foo);
    // вручную вызываем деструктор
    destroy(foo);
}

void main()
{
    usingScope;
    writeln("after usingScope");
    usingScoped;
    writeln("after usingScoped");
    usingEmplace;
    writeln("after usingEmplace");
}

Результат выполнения:

Foo onlineapp.Foo.this()
7FFFA5EC3170
void onlineapp.Foo.~this()
after usingScope
Foo onlineapp.Foo.this()
7FFFA5EC3160
void onlineapp.Foo.~this()
after usingScoped
Foo onlineapp.Foo.this()
7FFFA5EC3170
void onlineapp.Foo.~this()
after usingEmplace

т.е. вызывается конструктор, выводится адрес инстанса и вызывается деструктор и все до выхода из соответствующей функции

Но и многих возможностей нет:

Фактически получается что С++ или rust будут и удобнее и выразительнее, при всех их недостатках, чем D в режиме better-c.

Спасибо.

Корректнее сравнивать возможности betterC с extern «C» в плюсах, поскольку по умолчанию без GC доступны абсолютно все возможности языка.

Фактически получается что С++ или rust будут и удобнее и выразительнее, при всех их недостатках, чем D в режиме better-c.

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

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

поскольку по умолчанию без GC доступны абсолютно все возможности языка

Хоть я и перестал плотно интересоваться D еще до того как появились эти возможности, но по моему должны быть доступны далеко не все возможности, ведь даже встроенные в язык массивы и ассоциативные массивы завязаны на GC. Потом замыкания, опять же в отличии от C++ и rust, тоже не будут без GC работать. С классами тоже выходит не очень будет удобно пользоваться, хотя тут скорее всего возможно сделать обертки которые из не только на стеке как показали выше, но и на куче будут выделять. Исключения стандартные тоже без GC не должны работать. Ну и надо смотреть стандартную библиотеку там раньше вообще все было на GC завязано за редкими исключениями.

Ну и с чего это так получается? С того что ты не в курсе и явно Ди не разу даже не смотрел?

Лет 10 или уже больше назад, я как раз с D носился как сейчас с растом носятся, вместе с eao197 за него с шарпистами и немерлистами бились, ну и некоторое количество пусть небольших утилит на нем было конечно написано.

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

Да раст сейчас во многом интереснее, там кроме отсутствия GC еще много неплохих вещей и null safety которого нет ни в одном хоть сколько ни-будь популярном императивном языке и типизация и элементы функциональщины и макросы на уровне токенов, а с библиотеками и на уровне ast.
Ну и C++ сейчас тоже очень подтянулся, раньше он (до выхода C++11) практически во всем уступал D, сейчас же, особенно после C++17 так уже сказать нельзя, и выразительность потихоньку улучшается, с концептами и шаблоны уже можно писать почти также выразительно как и на D.
D же к сожалению так и застрял фактически на одном месте.

как по заказу, сегодня анонс новых привязок к Qt: https://github.com/tim-dlang/dqt

Шикарно!

Да раст сейчас во многом интереснее, там кроме отсутствия GC еще много неплохих

Ну и C++ сейчас тоже очень подтянулся, раньше он (до выхода C++11) практически во всем уступал D, сейчас же, особенно после C++17 так уже сказать нельзя, и

Мне кажется, тут небольшая путаница. Что Раст, что C++, не позволяют быстро выражать свои мысли, не отвлекаясь на технические тонкости.

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

Нет, конечно. На C++ можно (и нужно) писать «технически точно». Да, конечно, минимальный оверхед и так далее, но часто, особенно на этапе обучения, когда начинают плясать от алгоритмов, а не байтиков, текст на C++ часто превращается в заклинание, которое студент заучивает наизусть, не очень понимая смысл «всех закорючек». И только потом, по мере накопления опыта… Это порочный путь. Или начинать «с самого низу» (на что нет времени), или изначально брать другой инструмент.

Я очень далёк от мысли, что D может и должен заменять C++ и D и продолжаю утверждать, что это разные инструменты. D заточен на быструю и достаточно надёжную разработку, для C++ и Раста это просто недоступно.

Блин, народ, время написания среднего размера программы на D примерно такое-же, что и на Питоне!

D же к сожалению так и застрял фактически на одном месте.

Ой ли? По-моему, народ наоборот, слишком увлёкся внесением изменений в язык, в ущерб практичной применимости.

Это не то, ты using переизобретаешь

Ну, не совсем. И функцию выполняет.

А что, в D явным образом копиконструкторы нельзя запретить?

Почему? Можно. А можно и неявным :)

«Изложение большого куска учебного материала занимает одинаковое время вне зависимости от выбранного подхода».

Изложение — да, если без практического освоения. Как только начинается практическая работа — шиш. Есть время осваивать концепции, есть время погрязать в мелочах :)

Начинать надо с того ЯП, который уже на 2й половине первой пары позволит учащимся >самим написать прогу более сложную, нежели «Прощай, програмитроаание». И >позволить пойти в обучении дальше,

Ну так о том и речь.

После этого можно изучать практические языки, ставшие востребованными на рынке. В >том числе студентом самостоятельно.

А вот это уже, сам.

Фактически получается что С++ или rust будут и удобнее и выразительнее, при всех их недостатках, чем D в режиме better-c.

Скорее, точнее. C++ будет точнее (в «отражении мысли на байтики») и без ограничений.

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

А есть ли смысл делать глобальный вывод применимости инструмента по удобству в его побочном режиме?

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

Питонист через пол часа с этого D сбежит потому что библиотек нет.

Огромное количество нативных библиотек и нативный же вызов библиотек на C++

Это не правда. Практически ничего менять не придется. Для питонистов есть специальный раздел: https://wiki.dlang.org/Programming_in_D_for_Python_Programmers И сделана возможность писать на D прямо из IPython блокнотов.

Язык, который включен в набор компиляторов gcc, по определению не может не иметь библиотек и широкой поддержки сообщества.

Блин, я запутался: gcd и gdc - это разные вещи?