а как оно, без GC живет там, где нужно выделить память?

Выделяет

а освобождает как? или оно смотрит есть ли GC и если что, освобождает руками?

это сферический вопрос в вакууме?

если да, то как-то выделяет и как-то освобождает)

Освобождает

Задайте нормально вопрос

а освобождает как? или оно смотрит есть ли GC и если что, освобождает руками?

В конечном итоге это обертки над malloc/free в тот момент когда это нужно, а не бросание на волю GC

Как пример https://dlang.org/phobos/std_container_array.html

Как пример https://dlang.org/phobos/std_container_array.html

спасибо

Ну пока придумали просто ее переписывать без GC по миллиметру )

это какая либа? просто я таких находил уже не одну (без GC, типа стандартные или реализующие часть только)

имеется в виду стандартная phobos2

а как оно, без GC живет там, где нужно выделить память?

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

имеется в виду стандартная phobos2

ну и она вроде пока не расскалывается на GC и noGC, так ведь?

пока держится

Всмысле не раскалывается? Оно же может прекрасно сосуществовать вместе

тов. @I_vlxy_I сетовал на то что 2 стандартные либы это плохо

видимо я что-то не так понял

подняли кипишь раньше времени)

Но можно было бы написать субстандартную либу, которая была бы реализована на betterC, а стандартную либу переписать уже поверх нее )

А как в betterC с замыканиями? Без них все приятные плюшки std.algorithm превращаются в тыкву.

Если б научить компилятор использовать theAllocator из std.experimental.allocators по умолчанию, можно было бы почти весь фобос спокойно использовать и с GC и без него, просто в в рантайме выбирая аллокатор.

int function(int) fp = a => a+1; int function(int) fp1 = (a) { return a+1; };Сейчас попробовал вот такое писать - компилится и работает нормально.

Так что похоже что все хорошо

Еще надо понять работают ли слайсы и ренджи, если да то будет вообще супер.

В этих примерах нет замыкания

На внешние переменные?

ну да

чтоб из скопа локальные переменные использовались

мне кажется можно просто function заменить на delegate и узнать

Попробовал первый пример из https://dlang.org/spec/function.html#closures

Выдает такое:

source/main.d(38,10): Error: cannot implicitly convert expression & foo of type int function() nothrow @nogc @safe to extern (C) int function() dmd failed with exit code 1.

Там первый пример про function pointers, это тоже не то.

Ну там есть замыкание на статическую a

Статическую же

Если его можно в function сунуть, это не настоящее замыкание.

См разницу delegate / function

Короче даже оно не компилится как есть.

Щас попробовал. Когда замыкание нужно выделить в куче, betterC уже не может, но когда компилятор видит, что можно использовать scope delegate, не выделять доп. память, то все работает: https://dpaste.dzfl.pl/5fe32d0f2135

Хм да, вынесение из под extern(C) области делает жизнь чуть лучше )

Щас попробовал. Когда замыкание нужно выделить в куче, betterC уже не может, но когда компилятор видит, что можно использовать scope delegate, не выделять доп. память, то все работает: https://dpaste.dzfl.pl/5fe32d0f2135

Бля, зачем я это перед сном читаю..?

Бля, зачем я это перед сном читаю..?

Ты что D не любишь? ?

гастроскопия онлайн.

Хм да, вынесение из под extern(C) области делает жизнь чуть лучше )

extern был взят из примера про betterC.

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

а, неудивительно

А вот кому коммерческого десктопного софта на D & dlangui? https://agilecommander.com/

рынок десктопного софта умер же.

Щас попробовал. Когда замыкание нужно выделить в куче, betterC уже не может, но когда компилятор видит, что можно использовать scope delegate, не выделять доп. память, то все работает: https://dpaste.dzfl.pl/5fe32d0f2135

это известная фишка, не всякое замыкание требует аллокации.

рынок десктопного софта умер же.

программировать на мобиле/игровой консоли?

хотя если речь идет именно о рынке

программировать на мобиле/игровой консоли?

ну, рынок склонился к тому, что бОльшая часть гуйцов нонче это веб-морда так или иначе. html+js+css, всё такое. даже если это например программерский оффлайн редактор/IDE. мобильные приложения тяготяют к тому же.

в этом смысле оно потихоньку помирают, но еще далеко от смерти

игры например цветут и пахнут

игры да, игры это профессиональный высокопроизводительный софт (да еще и уникальный своей одноразовостью).

а вот всякая мелочь десктопная нативная успешно убивается связкой js+html+css

а вот всякая мелочь десктопная нативная успешно убивается связкой js+html+css

хз, вот сижу в своем KDE и использую кучу гуевого софта.

Мне доводилось переписывать чужой проект с вебморды в нативный клиент на том же dlangui.

например если допустим какой-нибудь таймтрекер писать - ну явно же трекать то же время нужно на нескольких устройствах, значит что? значит пишем демона под все устройства, который без гуя, но трекает и пушит данные куда-то в сервис, а морду уже делаем на js+html+css.

Qt это нонче такое себе native, там же тоже нонче модно qml + qtscript

тем не менее оно не веб, но тенденция перетекания в вебу есть, не спорю.

ну, vscode тоже как бы не веб. несмотря на html+css+js ?

формально не веб.

но нативный программер уже не нужен. ни для vscode ни для qml

ну а сублима, например, и неформально не веб

ERROR: S client not available

тем не менее оно не веб, но тенденция перетекания в вебу есть, не спорю.

Да щас какой-нибудь хрен из фейсбука напишет статью "why you should never ever use html+js for application development" и тенденция понесется обратно :) Как оно часто и бывает.

но нативный программер уже не нужен. ни для vscode ни для qml

а нативный это какой?

ну а сублима, например, и неформально не веб

а саблайм потихоньку сдулся относительно vscode например и прочих атом-конкурентов.

полно софта без html+js+css

полно. но тенденция такова, что это в основном легаси.

а саблайм потихоньку сдулся относительно vscode например и прочих атом-конкурентов.

это неправда, vscode ужасающий тормоз

тот же скайп нонче это html+js+css

а был нативным везде

У меня видеософт десктопный на D, там вебня не годится никак.

это неправда, vscode ужасающий тормоз

смотря что с ним делать. если как IDE для того же Go - то, по факту, большинство предпочитают его, а не саблайм, или goland.

это неправда, vscode ужасающий тормоз

запускается долго, а работает сносно, по-моему

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

я хз когда и где он был делфи. там где я его юзал делфи не было никогда ?

виндовый скайп много лет на дельфе был

я давно виндового скайпа не видел

полно. но тенденция такова, что это в основном легаси.

офисные приложения, работа с графикой тоже легаси?

а много новых офисных приложений? они, кажется, все легаси. новое обычно делается вебнёй.

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

точно

Если webasm взлетит то опять все будут на низком уровне кодить, просто чуть с другими интерфейсами и сисколами

Впрочем я думаю даже если он не взлетит то взлетит что-то аналогичное ему

все по кругу

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

Вон Вулкан идет на замену ОпенГЛ

он еще 40 лет может идти на замену :)

всякие новомодные CAD не собираются ренлерится в html

он еще 40 лет может идти на замену :)

почему?

неудобный шибко. и инерция разработчиков

впрочем, могу ошибаться

судя по всему ошибаешься,

дофига кто поддержку сделал

на маке нету