или что подразумевается по "рантаймом"?

А зачем это делать во время компиляции?

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

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

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

Второе

Второе

что-то как-то смешались в кучу кони, люди.

классы как бы всегда освобождаются в рантайме (разве что функцию в режиме CTFE вызвать)

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

А разве понятно?

Нифига ведь непонятно

классы как бы всегда освобождаются в рантайме (разве что функцию в режиме CTFE вызвать)

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

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

точнее scoped делает класс, но взвращает обертку вокруг него, а не сам класс.

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

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

именно так.

еще структура умеет проксировать обращение к классу

Допустим такой вот код { auto a = new A() a.doWork(); } может ли компилятор уничтожить класс в переменной a при выходе из скоупа?

Допустим такой вот код { auto a = new A() a.doWork(); } может ли компилятор уничтожить класс в переменной a при выходе из скоупа?

Зависит от реализации doWork.

Зависит от реализации doWork.

хуже, это зависит еще и от реализации конструктора класса A

хуже, это зависит еще и от реализации конструктора класса A

С чего бы?

А вот как проверить где был класс создан? Или структура? Просто для меня стек и куча это просто абстракции, и я вынужден или верить документации или просто тыкать пальцем в небо. Ну вот пишу я: int a=1; Есть способ наглядно представить то что в этот момент в Дишном коде происходит. Ну я не знаю там столбец в виде стека и в нем записана единичка. Или там string x = "hello"; и в стеке ссылка, а значение в облаке под названием "куча"

С чего бы?

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

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

А, ну да

А вот как проверить где был класс создан? Или структура? Просто для меня стек и куча это просто абстракции, и я вынужден или верить документации или просто тыкать пальцем в небо. Ну вот пишу я: int a=1; Есть способ наглядно представить то что в этот момент в Дишном коде происходит. Ну я не знаю там столбец в виде стека и в нем записана единичка. Или там string x = "hello"; и в стеке ссылка, а значение в облаке под названием "куча"

боюсь без каких-то диких грязных хаков никак.

А, ну да

Но в целом, то о чем ты говоришь вполне возможно. В одном языке - Rust

Компилятор rust тебе не даст увести ссылку в конструкторе или еще где. Свяжет тебя по рукам и ногам. В итоге идет постоянная борьба с компилятором.

Но в целом, то о чем ты говоришь вполне возможно. В одном языке - Rust

Почему только в одном? Мы же можем определить в компайлтайме, есть ли там сайд-эффекты со ссылкой на класс или нет

Почему только в одном? Мы же можем определить в компайлтайме, есть ли там сайд-эффекты со ссылкой на класс или нет

далеко не всегда, разве что ФП-язык.

реализация может быть вообще в сторонней бинарной либе

но может есть еще подобные языки, я только один знаю - rust

реализация может быть вообще в сторонней бинарной либе

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

в какой-то степени это возможно, но сложно. особенно если учесть, что компилятор можно обмануть всякими cast.

А вот как проверить где был класс создан? Или структура? Просто для меня стек и куча это просто абстракции, и я вынужден или верить документации или просто тыкать пальцем в небо. Ну вот пишу я: int a=1; Есть способ наглядно представить то что в этот момент в Дишном коде происходит. Ну я не знаю там столбец в виде стека и в нем записана единичка. Или там string x = "hello"; и в стеке ссылка, а значение в облаке под названием "куча"

Насчёт наглядно представить. Есть два вариант - посмотреть асм, либо понять, как вообще решают, что где хранится

Насчёт наглядно представить. Есть два вариант - посмотреть асм, либо понять, как вообще решают, что где хранится

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

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

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

Да, приходится, но в целом все просто. Массивы и все что создано через new - это куча. Остальное - стек.

ассоциативные массивы тоже - куча.

Вот я пишу File file = File("my.txt"); Но в то же время по идее могу написать и: File new file = File("my.txt"); Только иного пути как верить докам у меня нет. Евгений, на счет new понял

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

типа там стопка и по ней бегает указатель какой нить

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

Зачем?

Это же сильно зависит от настроек компилятора

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

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

Для этого не нужно такое глубокое понимание.

Ну а как происходит подсчет ссылок простыми словами? Как понимаю все объекты на которых нет ссылок в стеке удаляются?

Тут же про Ref-count в сборщике мусора выше говорили или там есть еще какие-то техники?

Ну а как происходит подсчет ссылок простыми словами? Как понимаю все объекты на которых нет ссылок в стеке удаляются?

В куче

В стеке все просто выпушивается за его границы же

Ну а как происходит подсчет ссылок простыми словами? Как понимаю все объекты на которых нет ссылок в стеке удаляются?

У каждого объекта есть счетчик ссылок. Работа происходит не с самими объектами, а с обертками-структурами. При копировании обертки счетчик увеличивается, при уничтожении - уменьшается. Если счетчик ссылок стал равен нулю, то удаляем и сам объект.

Это ты технику работы сборщика мусора описываешь или есть какая-то другая?

Я описываю технику работы RC.

А какую роль тогда стек играет? Это просто очередь операций получается?

А сборщик мусора - это более общее понятие.

Я описываю технику работы RC.

эта техника может заменить GC?

эта техника может заменить GC?

Да, это можно сказать, одна и з реализаций GC.

В чем плюсы\минусы RC?

Но у нее есть свои изъяны

В чем плюсы\минусы RC?

Плюсы - детерминированность уничтожения объектов. минусы - оверхед и возможные утечки если будут циклические ссылки.

А какую роль тогда стек играет? Это просто очередь операций получается?

Типа того. Вышла переменная из зоны видимости - уничтожилась.

У объектов на стеке время жизни детеминировано. Как только объект снимается со стека, или снимается содержащий его фрейм, он разрушается.

зона видимости не связана со стеком

а что такое "объект снимается со стека, или снимается содержащий его фрейм" если не выход из зоны видимости?

Время жизни объектов на стеке вполне себе связано с областью видимости, хотя, конечно, это разные вещи.

время жизни - да, стек - нет

время жизни объектов на стеке - да.

в общем случае нет

ну разве что в таком общем, что мы за пределы D вылезаем.

стек - это уже за пределами D

ну, мы вроде как обсуждаем стек именно в D.

А так-то да, это детали реализации.

можно вместо стека, хоть облачное хранилище задействоать.

"стек" - это типа то, что не куча :)

Ну а область видимости - больше об именах чем о времени жизни.

да, но оно тесно связано

Как минимум время жизни объекта должно полностью включать в себя зону видимости. Если так можно выразиться.

Мне вот всегда было интересно, стек уничтожается на уровне кода при returne'е или на уровне процессора?

В dip1000 подробно описано про видимость и время жизни

Мы все помрем

Мне вот всегда было интересно, стек уничтожается на уровне кода при returne'е или на уровне процессора?

На уровне процессора только некоторые вещи футболятся системе. Обычно всё разруливается локальным кодом.

стек - это уже за пределами D

кстати в доках D стек упоминается часто и густо. Так что не факт, что за пределами :)

В разных системах стек организовывается по-своему.

но это таки стек

На уровне процессора только некоторые вещи футболятся системе. Обычно всё разруливается локальным кодом.

Т.е. мы до входа в функцию сохраняем указатель на стек самостоятельно, а потом восстанавлимаем? Made by yourself?

да

Понятно. Хотя где он хранит - тот еще вопрос. Надо посмотреть, как в С это сделано

адрес возврата сохраняется на стеке

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

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

Ну еще параметры через стек, вроде

обычно да

В смысле обычно? Первые 6 - через регистры, остальные через стек

В смысле обычно? Первые 6 - через регистры, остальные через стек

Это зависит от реализации

У D вообще есть вменяемый ABI?

Вроде да

В доках есть пункт

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BE_%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D0%B5

ABI

нашел https://dlang.org/spec/abi.html

Что-то не вижу там "Первые 6 - через регистры, остальные через стек"

https://en.wikipedia.org/wiki/Calling_convention - тут ещё веселее

Что-то не вижу там "Первые 6 - через регистры, остальные через стек"

Т.к. это может зависить от платформы, не?