Свой компилятор(С++'о подобный)

[Utkin]

ересь какая-то. ещё раз повторяю: мне не нужна экзотика мне нужен нормальный язык

Ересь не ересь, а радиотелескопы фортовыми программами управляли

[BOBAH13]

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

let
f = File("input.txt")
in
{
// Только здесь можно использовать объект f
} // Здесь файл закроется

Ну да, LISP вчера появился.

(let ((f (file 'input.txt))) ())

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

{
auto f = File("input.txt");
// do something
// close file
} // к объекту нет доступа здесь и он освобожден из памяти

Это кстати С++

[Пепел Феникса]

Это кстати С++

я думаю разница в том что там код in не выполнится если не удалось создать f(то есть открыть файл).

[BOBAH13]

Сообщение от Пепел Феникса

я думаю разница в том что там код in не выполнится если не удалось создать f(то есть открыть файл).

Ну а я могу сказать, что зависит от реализации класса File, он может выкинуть std::exception тогда блок вылетит и код дальше по тексту не будет выполненн. Ну или как std::iostream работает is_open() метод, if поставили да и все в конце блока с if закрыли файл. Конечно идея в новой java и C# лучше -> using (File f = File("input.txt")) {} и все тут. Но по сути просто удаление и авто-закрытие файла.

[Utkin]

Могу предложить восточную философию - критические функции должны иметь недоступные программеру антиподы . new пожалуйста, delete фигу. OpenFile пожалуйста, CloseFile фигу. Вот пусть компилятор и производит все эти анти в конце блока (то есть в операторе } ), где объявлен первый элемент пары. Поначалу необычно, но это не просто сборка мусора, это глобальная подтирка за программером. Уверен все программы автоматически станут намного стабильней. Это как электрон и позитрон, вместе они уравнивают вселенную Вашего процесса .

[pu4koff]

Сообщение от anyx

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

let
    f = File("input.txt")
in
{
    // Только здесь можно использовать объект f
} // Здесь файл закроется

Ничего, что один из вариантов этого самого "нового" рая - "умные" указатели в плюсах?
Перепишите такой же безопасный и изящный код в случае с взаимоуказывающими объектами. И тут начинается веселье в виде слабых ссылок/невладеющих указателей, которые не дай бог неправильно назначить.
Если брать RAII в целом, то это фигня.
- А давайте инициализировать объект в момент его создания, а когда он больше не нужен - освобождать ресурсы?
- А давайте.
Так и повелось. Офигенно, ёмко, научно, полезно. А самое главное - свежо и инновационно. Додуматься фишки объектов, что лежат в стеке, запилить для объектов в куче - это гениально и не каждому дано.

Сообщение от anyx

Тут и никакого ручного управления памятью, и освобождение ресурса в определённое время (в отличие от сборки мусора, где освободится неизвестно когда)

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

Сообщение от anyx

Забыть, как выделяется и освобождается память в языке?! Жесть...

malloc я и не собирался приводить в соответствие с Си, а вот с realloc лоханулся - это да. Слова уже путаю, совсем старый стал.

Сообщение от anyx

Но в С++ нет сборщика мусора. Только ручное управление памятью, только хардкор!

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

[Пепел Феникса]

Не надо никаких директив пихать, а то делфи получится.

в Делфи просто помечается функция так, а в плюсах у нее именно имя должно совпадать с именем класса, и вся разница.

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

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

ты можешь себе представить сборщик мусора в драйвере? в котором любое неверное движение заставляет систему уйти в BSOD.

да могу, сборка по ссылкам вполне все сделает верно, а не будет чтото вызывать когда попало.(когда будет запущен сборщик известно)

И перед закрывающей } вставлять делете для объекта/объектов (если нет его упоминания далее по тексту) непосредственно перед компиляцией.

тут лучше или 100% уничтожение строголокальных обьектов или же уменьшение счетчика ссылок.

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

ну вы мне подкинули одну мысль насчет сборщика, дать все-таки возможность ручного уменьшения счетчика(но не более чем на 1), если вдруг допустим надо освободить обьект раньше конца блока.

[anyx]

Сообщение от Пепел Феникса

известно причем точно известно.

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

Сообщение от BOBAH13

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

По выходу из блока будет вызван деструктор объекта.

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

Сообщение от BOBAH13

Ну а я могу сказать, что зависит от реализации класса File, он может выкинуть std::exception тогда блок вылетит и код дальше по тексту не будет выполненн. Ну или как std::iostream работает is_open() метод, if поставили да и все в конце блока с if закрыли файл. Конечно идея в новой java и C# лучше -> using (File f = File("input.txt")) {} и все тут. Но по сути просто удаление и авто-закрытие файла.

И где отсылка к моим предыдущим сообщениям по RAII? Вот кто-нибудь прочитает и из-за синтаксических различий не поймёт, что речь всё о том же

Сообщение от Utkin

Могу предложить восточную философию - критические функции должны иметь недоступные программеру антиподы . new пожалуйста, delete фигу. OpenFile пожалуйста, CloseFile фигу. Вот пусть компилятор и производит все эти анти в конце блока (то есть в операторе } ), где объявлен первый элемент пары. Поначалу необычно, но это не просто сборка мусора, это глобальная подтирка за программером. Уверен все программы автоматически станут намного стабильней. Это как электрон и позитрон, вместе они уравнивают вселенную Вашего процесса .

И это тоже RAII! Господа, вы пол-страницы обсуждаете одно и то же, думая, что говорите о разных вещах!

Сообщение от pu4koff

Ничего, что один из вариантов этого самого "нового" рая - "умные" указатели в плюсах?
Перепишите такой же безопасный и изящный код в случае с взаимоуказывающими объектами. И тут начинается веселье в виде слабых ссылок/невладеющих указателей, которые не дай бог неправильно назначить.
Если брать RAII в целом, то это фигня

1. "Плюсы" и "безопасность" - вещи несовместимые.
2. Я не говорю, что RAII - это всё, я говорю, что это хорошее дополнение к сборке мусора, позволяющее закрыть файл/сокет/любой другой ресурс в определённый момент, а не фиг знает когда, как при сборке мусора.

[Пепел Феникса]

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

а вы знаете сборку мусора только по таймеру?
сборка мусора через ведение счетчика ссылок, ссылка уменьшается едва переменная выйдет за блок(или будет заполнена другим значением), едва счетчик будет == 0, как тут же будет уничтожен объект.

кстати

он может выкинуть std::exception тогда блок вылетит и код дальше по тексту не будет выполненн.

и тогда вылетит вся функция а не блок.
либо же писать try-catch блок.

и кстати еще, сборка мусора(не используемой памяти) и уничтожение объектов тоже не обязано быть одним и тем же.

[Utkin]

И это тоже RAII! Господа, вы пол-страницы обсуждаете одно и то же, думая, что говорите о разных вещах!

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