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

для nogc есть ещё варианты?

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

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

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

странно, в чём хак?

вопрос снят

мин, найду детали

https://p0nce.github.io/d-idioms/#Throwing-despite-@nogc

там внизу примечание

ну и вот еще дискуссия https://forum.dlang.org/thread/occ9kk$24va$1@digitalmars.com?page=6

для nogc есть ещё варианты?

конечно: одна функция для любого типа

насколько помню для ексепшнов обсуждался вопрос использования refcount

насколько помню для ексепшнов обсуждался вопрос использования refcount

да, гибрид GC и RC

То есть на данный момент единственный рабочий вариант написать nogc библиотеку с исключениями - писать в дополнение еще и nothrow :)

Мысли в слух. По идее санкции США могут помочь работодателям обратить внимание на Ди. Java то санкционный продукт P.s. Это я на фоне запрета Oracle в РФ подумал

скорее они помогут думать как юзать нелегально то, что уже юзают

Мысли в слух. По идее санкции США могут помочь работодателям обратить внимание на Ди. Java то санкционный продукт P.s. Это я на фоне запрета Oracle в РФ подумал

чем в этом плане отличается D от Java?

только тем что про D пока никто не знает и сделать его санкционным пока никто не додумался?

Ну Ди ж GPL вроде

а openjdk?

не gpl кстати

Полный аналог?

не gpl кстати

https://dlang.org/articles/faq.html#q5

Полный аналог?

gpl и boost?

нет

boost гораздо лучше

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

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

такой паттерн-матчинг достаточно примитивен

Тут ты зря, паттерн-матчинг в Нахе вполне эквивалентен оному в языках вроде хаскеля и раста. В Нахе сперва превратили enum в алгебраики (как в расте), а потом и вовсе GADT из них сделали. И при этом все выглядит по-прежнему C-style.

https://code.haxe.org/category/functional-programming/enum-gadt.html

Тут ты зря, паттерн-матчинг в Нахе вполне эквивалентен оному в языках вроде хаскеля и раста. В Нахе сперва превратили enum в алгебраики (как в расте), а потом и вовсе GADT из них сделали. И при этом все выглядит по-прежнему C-style.

Возможно. Мне он показался послабее чем в erlang/elixir

В теме https://forum.dlang.org/thread/mvhddaendngqwbmlzdei@forum.dlang.org?page=4 Встретил следующее мнение: "- import ... really, we are 2018 and people are still wasting our time to have standard libraries as imports. Its even more fun when you split, only to need import the array library." Поясните плиз, что тут подразумевается? Делать неявный импорт всего и сразу? Разве это удобно? Подвопрос. Я на самом деле был бы рад, если бы ряд фишек был как в питон, доступен без всяких импортов. К примеру тот же `writeln` и разные методы типа `.array`

Похоже, что так и есть. Хочет импорт стандартной библиотеки по умолчанию. ИМХО, ненужно.

конечно, не нужно

сделал import std.file и бинарик разпух до 4 мб

одни хотят что-бы рантайм вообще не цеплялся, другие - что-бы цеплялась сразу вся std, им лениво написать import...

одни хотят что-бы рантайм вообще не цеплялся, другие - что-бы цеплялась сразу вся std, им лениво написать import...

На стройку пусть идут работать

На стройку пусть идут работать

таких точно на мясокомбинат не пошлют

Блин вы прикиньте

Я вчера вечером пытался написать полностью @nogc код и столкнулся с отвратительным костылем

Оказывается нельзя просто так в nogc коде делать отладочные writeln

а printf не принимает string со спецификаторами

То есть приходится городить дикие костыли просто чтобы распечатать отладочные строки. Использовать streamFormatter какие-то и т.д.

а printf не принимает string со спецификаторами

а почему не принимает-то?

Не помню.. сегодня гляну подробнее

Может я просто чего-то очевидного не заметил.

Но на форуме предлагают все переписать со своими велосипедами.

а почему не принимает-то?

Как минимум требует кастовать к const char*, ну и там далее какие-то проблемы начинаются

https://run.dlang.io/is/LncPzc работает же

Не, мне надо именно тип string

Распечатать переменную

ну ясное дело, что сишный printf ничего не знает о дишных стрингах

В общем боль

Ну почему так эффективно расставлены грабли в этом языке ...

не в языке, а в стандартной библиотеке)

интересно, может ли шаблонная функция распознать вызвана ли она в контексте @nogc или нет?

распознать-то можно через __traits(compiles, "new int[1]")

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

бяда

Ну можно просто всегда считать что nogc, и тогда в gc коде это все равно будет работать

распознать-то можно через __traits(compiles, "new int[1]")

нет, не работает, всегда ture возвращает: https://run.dlang.io/is/w9Rude

Ну можно просто всегда считать что nogc, и тогда в gc коде это все равно будет работать

некоторые фокусы невозможны в nogc

Какие например?

Я бы переписал writeln на nogc ) Если бы мог осилить

Какие например?

из @nogc нельзя вернуть string

точнее можно, но небезопасно

А ну по идее операции со стрингами аллоцируют, да

Если это не слайс

Но ведь если все переписать на ручной malloc/free, то это будет медленнее работать в теории?

почему это?

https://stackoverflow.com/questions/2079151/minimizing-the-amount-of-malloc-calls-improves-performance я читаю всякие рассуждения, и вот в случае с GC память будет сначала выделяться непрерывными кусками, а потом когда придет время собирать мусор, то весь этот большой блок можно будет освободить одним вызовом. Я так рассуждаю.

дык можно пул замутить

Или хотя бы GC как-то может оптимизировать это дело в общем случае.

дык можно пул замутить

Да, но это все усложняет. В конце концов так постепенно дорабатывая управление памятью, не придем ли мы к GC снова?

да нет, я когда на плюсах писал, использовал пулы, если функция постоянно аллоцирует и освобождает объекты

Да, но это все усложняет. В конце концов так постепенно дорабатывая управление памятью, не придем ли мы к GC снова?

Ну RC - это уже некий вариант GC

Сам по себе GC - отличная шука, ничего не имею против. Главное чтобы он работал без проблем

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

на дешных экспериментальных аллокаторах пул замутить как нефиг делать

крутой inline assembler в D надо сказать)

по крайней мере проброс переменных мне очень нравится

Покажи пример

void main(string[] args) { int a = 2; int b = 3; asm { mov EAX, a[EBP]; mov EBX, b[EBP]; add EAX, EBX; mov a, EAX; } writeln(a); }

Ничего не понимаю, но выглядит круто)

Ничего не понимаю, но выглядит круто)

EBP - указатель на стек, a[EBP] - получается значение a, аналогично для b. В регистры EAX и EBX засылают значения a и b, складывают и cохраняют результат в a.

EBP - указатель на стек, a[EBP] - получается значение a, аналогично для b. В регистры EAX и EBX засылают значения a и b, складывают и cохраняют результат в a.

А тебе это для чего?

Просто попробовать?

Или есть какая-то задаче, где реально нужен асемблер?

это не мне, это ты попросил пример использования инлайн ассемблера, тебе его и прислали )

для чего может быть нужно? например если ты знаешь что в какой-то часто вызывающейся ф-ции компилятор генерит неудачнй код - вставляешь ассемблерный кусок и вперед

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

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

Круто

Ясно

Я от этого далёк, как до Марса)))

Асм в наше время - не актуально. Попробуйте приплюснутый код с суперскалярными интринсиками странслировать. Желательно для LDC.

ASM - плохо, по крайней мере x86, LLVM еще куда не шло, но тоже плохо. ASM хорош для установления хука на метод активации в программе, но D для таких задач избыточен

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

Да я вот хочу попробовать сделать свой context switching, да чтоб на betterc работал

EBP - указатель на стек, a[EBP] - получается значение a, аналогично для b. В регистры EAX и EBX засылают значения a и b, складывают и cохраняют результат в a.

а почему когда читаем из a и b, то пишем a[EBP] и b[EBP], а когда в конце сохраняем результат, то пишем просто a, а не a[EBP]?

Не знаю, не разработчик