Здравствуйте, BulatZiganshin, Вы писали:
P>>thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!
BZ>жаль, что на rsdn нет награды за дезертирство с Поля Брани :))
OMG! Ты что, реально считаешь, что мне было просто нечем ответить, и из-за этого я решил дезертировать?
Включи мозг — гораздо правильнее тогда было бы просто проигнорировать thesz'a — это совершенно типичное для него сообщение. Подумаешь — я, типа, не заметил.
Ну же, давай, напиши «да» — и я найду в себе силы ответить! Не дай угаснуть флейму!
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, z00n, Вы писали:
P>Я понимаю, о чем ты, но, на самом деле, в плюсах слишком много механизмов и слишком мало фич Поясню. В плюсах нет нормальной системы типов. Зато там есть шаблоны, которые по мощи уделывают типы хаскеля на порядок (другое дело, что воспользоваться этой мощью практически бесконечно трудно Там нет сборки мусора, но есть смарт-поинтеры и RAII. И так далее.
Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора. Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально. Потому, что думать нужно рано
P>Плюсы активно проживут еще лет 10, думаю (т.е. еще лет 10 люди будут начинать новые проекты на плюсах). Потом умрут, на смену придет более стройный язык. Потом он умрет. И так далее.
Scheme ровесник С — и еще очень долго не умрет
FR>>>Угу, но примерно одинаково по тем же строкам с питоном или окамлом. T>>Плотность ошибок меньше? FR>У тебя есть доказательства что она меньше в Хаскеле?
Косвенные.
Разработчики языков программирования переходят на Хаскель с *ML.
T>>Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода. FR>Конечно надо, но даже с тестами у него очень хорошая плотность кода. FR>К тому же есть подозрения что для Хаскеля тоже не обойтись без тестов в случай длительно FR>подерживаемого проекта.
Функциональных тестов. Их намного меньше юнит-тестов.
T>>>>Против 2 раз никто не поспорит. FR>>>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>>>впечатляет. T>>10-тикратном разбросе у одного программиста? T>>Позволю себе не поверить. FR>В разы запросто, например у меня.
"10 раз" и "разы" различаются, как бы, раза в три-четыре.
FR>..... T>>Плотность ошибок ещё снизится. FR>Все это конечно хорошо, надо почитать. FR>Но если брать реальный код на сколько процентов он будет короче и насколько надежнее по сравнению FR>с тем же окамлом, опять таки есть подозрения что очень немного, кроме спицифичных вырожденных случаев конечно.
С "есть подозрения" очень трудно спорить.
Давай перечислим участки кода, где это может помочь. Типичные случаи.
Вот где ты видишь применение всего этого дела?
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент. T>>А что ещё повышает? T>>А это — то, что повышает, — ортогонально ЯП, или нет? FR>То что ортогонально ЯП уже дает колебания близкие к порядку.
Что же даёт колебания, близкие к порядку?
FR>Но кроме этого Хаскель не единственный высокоуровневый язык.
Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла.
Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/
С остальными примерно та же картина.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Косвенные.
T>Разработчики языков программирования переходят на Хаскель с *ML.
Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs,
на ML (включая OCaml) таких проектов гораздо больше.
Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
T>Функциональных тестов. Их намного меньше юнит-тестов.
Неважно, важно то что питон и с тестами достаточно выразителен и компактен.
T>>>10-тикратном разбросе у одного программиста? T>>>Позволю себе не поверить. FR>>В разы запросто, например у меня.
T>"10 раз" и "разы" различаются, как бы, раза в три-четыре.
10 как раз крайний случай.
T>С "есть подозрения" очень трудно спорить.
T>Давай перечислим участки кода, где это может помочь. Типичные случаи.
T>Вот где ты видишь применение всего этого дела?
Я нигде не вижу, мельком проглядев статью, это ты должен показать
T>Что же даёт колебания, близкие к порядку?
Индивидуальные различия программистов, правильная или неправильная организация работы,
Ошибки и находки в архитектуре и алгоритмах.
FR>>Но кроме этого Хаскель не единственный высокоуровневый язык.
T>Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла.
T>Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/
И что думаешь посмотрев на сравнение одного языка который я плохо знаю, на другой который я первый раз вижу я буду
впечатлен?
T>С остальными примерно та же картина.
Здравствуйте, z00n, Вы писали:
Z>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали: Z>Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора.
Ты про что?
RAII — это Resource Acquisition Is Initialization (Получение ресурса есть инициализация)
При чём здесь первокласные функции?
Z>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально. Потому, что думать нужно рано
Сможешь разяснить каким боком RAII мешает?
Мне почему-то всегда казалось, что сборке мусора мешают адресная арихметика и касты.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
E>Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов.
Главная проблема — деструкторы и то как их принято использовать в С++.
Страуструп говорит почему это сложно: http://www.devx.com/SpecialReports/Article/38813/0/page/4
Not quite ready for C++0x timetable, but actively pursued
Papers in this category have been in development and reviewed several times over the evolution of C++0x. However, although there is a strong interest the feature has not quite stabilised fast enough to meet the 2009 target deadline. Work will proceed outside the main committee meetings, and will be picked up with a view to an early adoption.
N1833 N1943 N2128 N2129 N2286 N2287 N2310 Transparent Garbage Collection for C++ H. Boehm, M. Spertus
...
T>>Косвенные. T>>Разработчики языков программирования переходят на Хаскель с *ML. FR>Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs, FR>на ML (включая OCaml) таких проектов гораздо больше.
Есть такая интересная область, называется теория типов (система типов, исчисление конструкций, теория типов Мартина-Лёфа — всё примерно одинаково). Результаты оттуда попадают в Хаскель (семейства типов, GADT) и дальше расползаются по другим языкам.
Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
FR>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно.
Поэтому используют Хаскель.
А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было.
T>>Функциональных тестов. Их намного меньше юнит-тестов. FR>Неважно, важно то что питон и с тестами достаточно выразителен и компактен.
Я привёл пример количества тестов для выразительного языка.
"Выразителен и компактен" для разного человека выглядит по-разному. Для меня выразительные три строки и 50 строк тестов к ним никак не выглядят выразительными в целом.
T>>С "есть подозрения" очень трудно спорить. T>>Давай перечислим участки кода, где это может помочь. Типичные случаи. T>>Вот где ты видишь применение всего этого дела? FR>Я нигде не вижу, мельком проглядев статью, это ты должен показать
Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции.
Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону.
Я, например, делал не так давно прототип HDL. Там без типов с размерами никак. Получилось плохо, придётся переписывать, но кое-что понял для себя.
T>>Что же даёт колебания, близкие к порядку? FR>Индивидуальные различия программистов, правильная или неправильная организация работы, FR>Ошибки и находки в архитектуре и алгоритмах.
Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP).
FR>>>Но кроме этого Хаскель не единственный высокоуровневый язык. T>>Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла. T>>Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/ FR>И что думаешь посмотрев на сравнение одного языка который я плохо знаю, на другой который я первый раз вижу я буду FR>впечатлен?
Я повторю. Maude играл на своём поле. За Maude играли сильные в нём люди. За Хаскель играли сильные в Maude люди.
Хаскель выиграл с большим отрывом.
Если тебя это не впечатляет, то что тогда впечатлит?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали: P>В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.
А руками так писать не обязательно. Cps — это просто в некоторых аспектах удобное промежуточное представление кода.
Z>>Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора. T>Ты про что? T>RAII — это Resource Acquisition Is Initialization (Получение ресурса есть инициализация) T>При чём здесь первокласные функции?
bracket :: Monad m => m open -> (open -> m close) -> (open -> m action) -> m (Maybe action)
bracket open close action = do
h <- open
r <- catch (liftM Just (action h)) (return . const Nothing)
close h
return r
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, z00n, Вы писали:
Z>>>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
E>>Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов. Z>Главная проблема — деструкторы и то как их принято использовать в С++. Z>Страуструп говорит почему это сложно: Z>http://www.devx.com/SpecialReports/Article/38813/0/page/4
Беглый просмотр не дал ответа. RAII -- это механизм для временного владения ресурсами, время владения определяется областью видимости RAII переменной (о чем Страуструп говорит "We have RAII (for scoped resource use)"). В том же C# аналогичный эффект достигается с помощью using и IDisposable. В D есть специальные scope-классы, специально предназначенные для реализации RAII.
Другое дело, что GC при сборке мусора не будет звать деструкторы. Что не позволит освобождать ресурсы, время жизни которых превышают область видимости некоторого фрагмента (о чем Страуструп говорит "smart pointers" (for resources that don't have their lifetimes determined by a simple scope)"). Но это уже несколько другая песня. К RAII, имхо, имеющая лишь отдаленное отношение.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pgregory, Вы писали: Z>>Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов). P>Я не различаю «обычные» программы и библиотеки, и не считаю, что они должны как-то по-разному писаться.
А зря. Scheme позволяет писать на разных уровнях абстракции. Низкоуровневые фичи: макросы, континуации — позволяют создавать более высокоуровневые: библиотеки многопоточности, исключений, continuations-based серверы и т.п. Соседство разных уровней абстракции в одном языке свойственно не только scheme. Например, на уже обсуждаемом в ветке haskell можно писать используя только функции (тут кстати тоже разделение — можно исползовать рекурсию в чистом виде, а можно использовать готовые fold, unfold, map и т.п.), можно использовать традиционные абстракции более высокого уровня: монады, стрелки — а можно придумывать и реализовывать свои.
P>Звучит красиво. Но теория и практика совпадают только в теории. Несмотря на концептуальную простоту, схема не получила распространения, и нет предпосылок к тому, что получит.
Ну так это ничего не говорит о достоинствах или недостатках языка. Никто не отрицает, что scheme не является промышленным языком.
T>bracket :: Monad m => m open -> (open -> m close) -> (open -> m action) -> m (Maybe action)
T>bracket open close action = do
T> h <- open
T> r <- catch (liftM Just (action h)) (return . const Nothing)
T> close h
T> return r
T>
Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может.
А то, что ты написал называется "шаблонный метод" по GoF.
Его можно вызывать там, где требуется аналог.
> On 11 Aug., 12:28, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> gast...@hotmail.com wrote:
>> > I agree. Selectable GC (in a library or requiring that classes are
>> > derived from some sort of base class) would be nice extension. The
>> > power of c++ is always that it spans low level and high level
>> > constructs, but the high level constructs could be served better if
>> > programmers weren't required to think about this.
>> I'm not so sure optional gc would work out very well. Suppose you're a
>> library designer - do you design it to work with gc, without gc, or
>> both? Doesn't this make it more difficult for the library designer, not
>> less?
> 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. 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.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Здравствуйте, Рысцов Денис, Вы писали:
РД>Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.
Может я конечно чего не понял но:
public static GroupAdjacent[T](this lst : list[T], fn : T * T -> bool) : list[list[T]]
{
def lst = lst.Fold([[]], (item, acc) =>
{
match (acc)
{
| [] :: tail => [item] :: tail;
| (item2 :: items) :: tail =>
if (fn(item, item2))
(item :: item2 :: items) :: tail;
else
[item] :: (item2 :: items) :: tail;
}
});
lst.RevMap(l => l.Reverse());
}
Main() : void
{
try
{
def l = ['1', '+', '-', '2', '3'];
WriteLine(l);
def l = l.GroupAdjacent((x, y) => char.IsDigit(x) == char.IsDigit(y) );
WriteLine(l);
def l = l.Fold([[]], (l, acc) => $[x :: y | x in l, y in acc]).Map(l => l.Reverse());;
WriteLine(l);
T>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
T>Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
То есть на одном очень узком и очень академичном направлении Хаскель вытеснил ML, по моему явно недостаточно.
FR>>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
T>Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно.
T>Поэтому используют Хаскель.
T>А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было.
Вывод по моему явно притянутый.
T>Я привёл пример количества тестов для выразительного языка.
T>"Выразителен и компактен" для разного человека выглядит по-разному. Для меня выразительные три строки и 50 строк тестов к ним никак не выглядят выразительными в целом.
реально тестов меньше чем кода получается.
T>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции.
T>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону.
Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет
полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
T>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP).
Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
T>Я повторю. Maude играл на своём поле. За Maude играли сильные в нём люди. За Хаскель играли сильные в Maude люди.
T>Хаскель выиграл с большим отрывом.
T>Если тебя это не впечатляет, то что тогда впечатлит?
Меня бы в контексте темы (Хаскель в мейнстриме) впечатлил нормальный большой неакадемический проект на Хаскеле. Еще больше бы впечатлили такие же пусть и небольшие проекты, но чтобы их можно было считать хотя бы десятками.
Здравствуйте, Tonal-, Вы писали:
T>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может.
RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад.
Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
T>>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris... T>>Не на Хаскеле остались системы, стартовавшие до начала 2000-х. FR>То есть на одном очень узком и очень академичном направлении Хаскель вытеснил ML, по моему явно недостаточно.
Сравни плотность изменений.
FR>>>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок. T>>Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно. T>>Поэтому используют Хаскель. T>>А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было. FR>Вывод по моему явно притянутый.
Сделай другой. Проведи исследования.
Чего всё я?
T>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
С "я предполагаю" очень трудно спорить.
Ты предполагаешь так почему конкретно?
T>>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP). FR>Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
Тебя надо наблюдать со стороны и на протяжении всего проекта. Нескольких проектов.
Минутные слабости компенсируются часовыми мощностями.
T>>Если тебя это не впечатляет, то что тогда впечатлит?
FR>Меня бы в контексте темы (Хаскель в мейнстриме) впечатлил нормальный большой неакадемический проект на Хаскеле. Еще больше бы впечатлили такие же пусть и небольшие проекты, но чтобы их можно было считать хотя бы десятками.
Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет.
А, похоже, пишут, возвращаясь к теме слешдота.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, WolfHound, Вы писали:
РД>>Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.
WH>Может я конечно чего не понял но:
Задача для монадического комбинатора sequence, возможно, это имел в виду Рысцов Денис, когда говорил о монадах и описании процесса через комбинаторы.
sequence . groupBy (\x y -> isDigit x == isDigit y)
Из-за наличия готовых комбинаторов общего назначения (sequence) нет необходимости писать специальный код для списка. Из-за ленивости списка нет необходимости просматривать всё дерево. В твоём решении, например, даже если список ленивый, вычисление не будет таким из-за обращения списка.
Ну и, конечно, что именно имел в виду Рысцов Денис, я могу только догадываться
Здравствуйте, z00n, Вы писали: Z>Здравствуйте, Tonal-, Вы писали:
T>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад.
Если у тебя объект на стеке, то они аналогичны.
Если объект динамический, то нет. Z>Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
На счёт хака — это эмоции.
Поясню. В плюсах нет нормальной системы типов. Зато там есть шаблоны, которые по мощи уделывают типы хаскеля на порядок (другое дело, что воспользоваться этой мощью практически бесконечно трудно 
