Здравствуйте, z00n, Вы писали:
Z>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. Z>Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты). Я считаю RAII более общей и элегантной техникой.
Здравствуйте, z00n, Вы приводили письмо Абрахамса:
>> More difficult in what way? I believe that all current code with
>> manually managed memory will continue to work in gc C++.
> Only if nobody actually use the GC features. :-)
> In C++ today we write classes that manage non-memory resources by
> freeing them in their destructors, and we can have confidence that if
> people follow "standard C++ coding practices" these resources will be
> freed at particular times. Other programmers aggregate instances of
> these classes into structures and can rely on a particular order of
> destruction, and thus on those resources getting freed. These classes
> often become the implementation details of other classes (think of the
> mutex associated with a threadsafe class instance), and we can allow
> clients to handle such classes without concern over when, or if, the
> underlying resources will be freed.
По этой части я полностью согласен.
Но дальше он пишет куда более интересные, на мой взгляд, вещи:
> In the committee we (at least some of us) could only think of three
> possible purposes for GC in C++. The first and most obvious would be to
> make it a legitimate standard coding practice not to call delete. But
> once you start doing that, the guarantees given by destructors that
> manage other resources no longer apply. Furthermore, the fact that a
> class (indirectly) manages a non-memory resource can no longer be an
> implementation detail. In fact, that "detail" now needs to ripple
> upward through the documentation of all classes that contain such a
> resource manager, so clients will know they can't be safely leaked. So
> far, nobody has been able to come up with a reasonable coding practice
> that avoids this problem. Until we have a workable programming model
> for C++ with GC, I don't want GC in the language.
> The other purposes were 1. making it possible for buggy, leaky programs
> to run longer before running out of memory, and 2. certain kinds of code
> (especially some lock-free algorithms) are very hard to write without
> GC. In my opinion, neither of these possible benefits justifies
> accepting the dangers described in the previous paragraph.
Кратко -- GC нужен, чтобы:
1) можно было писать код без явного delete
2) чтобы legacy программы не так быстро падали от забытых delete (sic!)
3) чтобы можно было реализовать некоторые интересные алгоритмы
Теперь по пунктам.
1) Думаю, все согласятся, что в сколько-нибудь современном плюсовом коде delete (да и вообще любое явное освобождение ресурсов) практически отсутствует. Лично я за последний год не написал ни единого delete, afair. RAII -- крайне мощная вещь при последовательном применении.
Да, я прочитал
> On the other hand, the benefit of being able to skip "delete" is so compelling that I
> think people would assume they can do it.
но я этого не могу понять. Чем плох RAII? Зачем вообще явно писать delete?
2) Поинт понятен, но не интересен.
3) А вот требуется ли для реализации этих алгоритмов глобальный GC? Может, что-то маленькое и локальное + какие-нибудь GC-аннотации сделают дело?
Здравствуйте, pgregory, Вы писали:
P>RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты).
Здравствуйте, Tonal-, Вы писали:
T>Здравствуйте, z00n, Вы писали: Z>>Здравствуйте, Tonal-, Вы писали:
T>>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. T>Если у тебя объект на стеке, то они аналогичны. T>Если объект динамический, то нет.
Объект может быть на другом компьютере — причем здесь это?
Здравствуйте, z00n, Вы писали:
P>>RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты).
Z>Цель у этого привязывания какая?
Сделать более простым, последовательным и error-resistant управление ресурсами в программах.
Здравствуйте, pgregory, Вы писали:
P>Сделать более простым, последовательным и error-resistant управление ресурсами в программах.
Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++. Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают. D вроде как обошел эту проблему, но для С++ все выглядит (на мой взгляд) совершенно безнадежно.
Я знаю что хаскель и развивается быстрее и библиотеки у него богаче, поэтому и удивительно что выхлопа
в виде приложений меньше.
FR>>Вывод по моему явно притянутый.
T>Сделай другой. Проведи исследования.
T>Чего всё я?
Тык ты у нас евангилист тебе и плясать
Я тут когда с питоном носился немало поплясал
T>>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>>полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
T>С "я предполагаю" очень трудно спорить.
T>Ты предполагаешь так почему конкретно?
В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики http://elementy.ru/lib/430319
Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>>>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP). FR>>Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
T>Тебя надо наблюдать со стороны и на протяжении всего проекта. Нескольких проектов.
T>Минутные слабости компенсируются часовыми мощностями.
Это да, но опыт тоже накапливается
T>Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет.
T>А, похоже, пишут, возвращаясь к теме слешдота.
Здравствуйте, z00n, Вы писали:
P>>Сделать более простым, последовательным и error-resistant управление ресурсами в программах. Z>Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++.
Полностью согласен. Но лично я не знаю более простой и мощной техники для этого. Аналоги using-а, как я уже писал, я таковыми не считаю.
Z>Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают.
я уже выражал свою позицию по поводу того, что даст GC плюсам. Не стоит забывать, GC -- не абсолютное добро, и имеет, при всех плюсах, довольно большой список недостатков. Не знаю, насколько это мнение популярно, но в RAII vs. GC я однозначно выберу RAII.
Здравствуйте, z00n, Вы писали:
E>>Беглый просмотр не дал ответа. Z>comp.lang.c++.moderated Z>
Z>Only if nobody actually use the GC features. :-)
Z>In C++ today we write classes that manage non-memory resources by
Z>freeing them in their destructors, and we can have confidence that if
Z>people follow "standard C++ coding practices" these resources will be
Z>freed at particular times. Other programmers aggregate instances of
Z>these classes into structures and can rely on a particular order of
Z>destruction, and thus on those resources getting freed. These classes
Z>often become the implementation details of other classes (think of the
Z>mutex associated with a threadsafe class instance), and we can allow
Z>clients to handle such classes without concern over when, or if, the
Z>underlying resources will be freed.
Z>
Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
T>>>Разработчики языков программирования переходят на Хаскель с *ML. FR>>Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs, FR>>на ML (включая OCaml) таких проектов гораздо больше.
T>Есть такая интересная область, называется теория типов (система типов, исчисление конструкций, теория типов Мартина-Лёфа — всё примерно одинаково). Результаты оттуда попадают в Хаскель (семейства типов, GADT) и дальше расползаются по другим языкам.
T>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
T>Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
Есть такой язык Vala, стартовавший в 2006-м. Пишется, iirc, на C. Или речь идет о каких-то других языках?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, z00n, Вы писали: P>>>Сделать более простым, последовательным и error-resistant управление ресурсами в программах. Z>>Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++. P>Полностью согласен. Но лично я не знаю более простой и мощной техники для этого. Аналоги using-а, как я уже писал, я таковыми не считаю. Z>>Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают. P>Здесь
я уже выражал свою позицию по поводу того, что даст GC плюсам. Не стоит забывать, GC -- не абсолютное добро, и имеет, при всех плюсах, довольно большой список недостатков. Не знаю, насколько это мнение популярно, но в RAII vs. GC я однозначно выберу RAII.
Я, честно говоря, вообще не интересуюсь мнениями и позициями — предпочитаю информацию
Здравствуйте, eao197, Вы писали:
E>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
На мой взгляд, Абрахамс очень понятно пишет о том, что если бы деструкторы не использовали бы для управления ресурсами(RAII) — можно было бы добавить консервативный GC. А так он будет сильно против.
E>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
Может, через час. А если нужно детерминированно?
Здравствуйте, z00n, Вы писали:
E>>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах. Z>На мой взгляд, Абрахамс очень понятно пишет о том, что если бы деструкторы не использовали бы для управления ресурсами(RAII) — можно было бы добавить консервативный GC. А так он будет сильно против.
Консервативный GC идет в топку.
E>>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе. Z>Может, через час. А если нужно детерминированно?
Ситуация ничем не будет отличаться от того, что есть в той же Java.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris... T>>Не на Хаскеле остались системы, стартовавшие до начала 2000-х. E>Есть такой язык Vala, стартовавший в 2006-м. Пишется, iirc, на C. Или речь идет о каких-то других языках?
И требования у тебя выше.
FR>>>Вывод по моему явно притянутый. T>>Сделай другой. Проведи исследования. T>>Чего всё я? FR>Тык ты у нас евангилист тебе и плясать FR>Я тут когда с питоном носился немало поплясал
То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе.
T>>>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>>>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>>>полностью заменить тестирование, также вообще сомневаюсь что это необходимо. T>>С "я предполагаю" очень трудно спорить. T>>Ты предполагаешь так почему конкретно?
FR>В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики FR>http://elementy.ru/lib/430319 FR>
FR>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
Что это означает?
T>>Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет. T>>А, похоже, пишут, возвращаясь к теме слешдота. FR>Значит мало пишут раз наружу совсем не выплывает.
"Совсем" это ты загнул, да.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Так он и моложе. И ситуация другая.
Так он и популярнее.
T>И требования у тебя выше.
Так к лучшему из функциональных языков же
T>То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе.
Притянутый потому что ты никак ни показал что именно из-за меньшей плотности ошибок переходят на Хаскель. Вот мне видится что из-за большей выразительности и большей гибкости языка по сравнению с ML.
FR>>В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики FR>>http://elementy.ru/lib/430319 FR>>
FR>>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>Что это означает?
Это означает что универсальной покрывающей хотя бы большую часть решаемых задач системы типов не построить.
Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы
T>"Совсем" это ты загнул, да.
Здравствуйте, z00n, Вы писали: T>>>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>>>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. T>>Если у тебя объект на стеке, то они аналогичны. T>>Если объект динамический, то нет. Z>Объект может быть на другом компьютере — причем здесь это?
Вообще не в кассу.
RAII — это способ связать время жизни ресурса со временем жизни объекта. Всё.
Отсюда и его применение как scope-based resource management.
Но оно не ограничивается этим.
T>>Так он и моложе. И ситуация другая. FR>Так он и популярнее.
Так каких-то лет пять всего.
T>>И требования у тебя выше. FR>Так к лучшему из функциональных языков же
Так к ещё не развернувшемуся в полную силу.
T>>То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе. FR>Притянутый потому что ты никак ни показал что именно из-за меньшей плотности ошибок переходят на Хаскель. Вот мне видится что из-за большей выразительности и большей гибкости языка по сравнению с ML.
Пример.
Внутреннее представление ghc типизировано. При желании можно включить проверку типов для него после каждого преобразования. Если преобразование неправильное, то проверка типов нам об этом сообщит. Эта фича позволила сэкономить разработчикам ghc много времени.
Итак, строго типизированные представления помогают.
Достаточно стандартным приёмом является и конструирование языка для своих внутренних нужд. Даже если это просто некое внутреннее представление.
Внутреннее представление есть у всех. Степень типизации, правда, разная.
Вот здесь показано, как пользоваться GADT, чтобы компилятор проверил правильность преобразований.
То есть, то, что ghc проверяет в рантайме, простому пользователю ghc доступно во время компиляции, хотя бы и для его нужд поменьше масштабом.
Это вынуждает этим пользоваться.
Это сокращает количество ошибок.
Всякого рода преобразования встречаются и в далёких от ЯП программах. В тех же оптимизаторах файловых систем, ведь файловая система и есть дерево с типами блоков, да ещё и хитро увязанных друг с другом.
FR>>>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>>Что это означает? FR>Это означает что универсальной покрывающей хотя бы большую часть решаемых задач системы типов не построить.
Поэтому нужна система типов, которую мы можем затачивать под наши конкретные цели. Система типов Хаскеля движется в этом направлении.
FR>Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы
Essential complexity по Бруксу.
Такое встречается очень редко.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
E>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
всё очень просто — в C++ объединены освобождение памяти и освобождение ресурсов. и то и другое делается в деструкторе, вызов которого *детерминирован* благодаря явному вызову delete (сарт поинтеры, RAII тоже вызывают дестуруктор детерминированно). языки с GC используют для освобождения ресурсов другие техники, поскольку их разработчики знают, что на момент вызова деструктора полагаться нельзя
соответственно, если добавить GC в С++, то legacy код будет несовместим с ним, поскольку в нём просто отсутствует разделение дестурукторов на освобождение ресурсов и освобождение памяти. т.е. несмотря на GC дестуруркторы всё равно придётся вызывать детерминированно для освобождения ресурсов
