питон заменит во многих областях Си++

вадим, хватит пустых слов.
выскажите лучше свое мнение насчет динамической типизации.

> питон заменит во многих областях Си++

у меня есть
"CINT is a C/C++ interpreter aimed at processing C/C++ scripts"

ЧЕМ Питон лучше? И где области заменения?

Забыл добавить ссылку http://root.cern.ch/root/Cint.html

Re:

И программировать на марках? Чего я недопонимаю в колбасных обрезках :-)

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

Re:

лучше на амфетаминах. про обрезки ничего сказать не могу.

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

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

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

Re:

Так, я пас :-). Здесь, в сибирской глубинке, все больше по натуральным продуктам прикалываются. Рекомендую :-).

А что тут думать, динамическая типизация рулит. Только вот на производительности она отрицательно сказывается, т.к. делает трудноосуществимой оптимизацию в JIT. Собственно говоря, "частичная статическая типизация" давно уже является модной темой во всяких python-ориентированных разработках, взять хотя бы тот же виртуальный по сию пору старкиллер или вполне реальный psyco. Так что, "верной дорогой" и все такое.

Python - хороший язык для тех, кто учится программировать. Но - ни тебе mультиметодов, ни символьных выражений, ни metaprogramming'а, ни нормального REPL. Серьёзные вещи надо писать на Lisp'е, и Python следует рассматривать лишь как шаг "на пути к совершенству" ;-) Lisp незаслуженно задвинули в следствие AI Winter, но сейчас вроде потихоньку вспоминают ;-)

Повторяю вопрос - есть интерпретатор C/C++
http://root.cern.ch/root/Cint.html
http://root.cern.ch

тут тебе и mультиметоды, и символьные выражения, и
metaprogramming, и нормальный REPL

Зачем нужен Python ?

Заранее благодарен за разумный ответ

> Повторяю вопрос - есть интерпретатор C/C++ > http://root.cern.ch/root/Cint.html > http://root.cern.ch

> тут тебе и mультиметоды,

В плюсах? Да ещё не полных? Или Вы overloading с мультиметодами путаете?

> и символьные выражения,

Хде?

> и metaprogramming,

C++ Templates что ли? Или C preprocessor? Не смешите мои тапочки. Да, я порядком работал с C++ BOOST. Сравнивать это убожество с Лисповским defmacro - всё равно что сравнивать детский лесопед с МиГ-29...

> и нормальный REPL

Ни в жисть не поверю.

Читаем
http://www.lisp.org/table/glossary.htm#mop
а также
http://www.lisp.org/mop/concepts.html

>>> тут тебе и mультиметоды,
>В плюсах? Да ещё не полных? Или Вы overloading с мультиметодами путаете?

Начнем с методов (цитата из http://www.lisp.org/mop/concepts.html)
"A method metaobject contains information about a specific method"

все metaobject классы содержатся тут:
http://root.cern.ch/root/html/META_Index.html

"information about a specific method" представлена TMethod классом
http://root.cern.ch/root/html/TMethod.html

Кстати вся ROOT HTML документация сгенерирована автоматически
на основе имеено этой metaobject информации


>> и символьные выражения,
>Хде?

Примером "символьные выражения" является TFormula класс
http://root.cern.ch/root/htmldoc/TFormula.html

Живой пример, как это работает можно попробывать здесь
http://carrot.cern.ch/CarrotExamples/hsimple.root?/2764078/ntuple;1/

Наберите в поле "Expression" что-нибудь типа "sin(px)/px"


>> и metaprogramming,
>C++ Templates что ли? Или C preprocessor? Не смешите мои тапочки. Да, я порядком >работал с C++ BOOST. Сравнивать это убожество с Лисповским defmacro - всё равно >что сравнивать детский лесопед с МиГ-29...

ROOT позволяет динамически подгружать разделяемые библиотеки.
Классы содержашиеся в этих библиотеках автоматически становятя
доступны интерпретатору, чем не defmacro?

>>> и нормальный REPL
>Ни в жисть не поверю.

1. запусти ROOT
2. командную строку
3. и занимайся REPLингом

Могу еще добавить, что в ROOTе есть такое мошьная концептуальная вещь, как
синалы-слоты
http://root.cern.ch/root/HowtoSignalSlot.html

которая, на пример, позволяет динамически (из интепретатора) методы
класса. У нас это называется "class connection"

Жду продолжения беседы

питон гавно, плюсы отстой, круче асма только мои яйца

коррекция:

фраза
"которая, на пример, позволяет динамически (из интепретатора) методы "
читается как
"которая, на пример, позволяет динамически (из интепретатора) перегружать методы "

Добавлю, именно metaobject является ключевым моментом.
Например, это позволяет автомaтически генерить Streamer method
используемый для спасания обьектов в файл(persistency).
При этом можно записывать "Heterogeneous" обьекты с любой
степенью вложенности, как здесь (фаиловая система внутри файла)
http://carrot.cern.ch/CarrotExamples/hsimple.root?/8895343/

В случае с Python мы помимо самого языка и его возможностей имеем в эшелон уже готовых и мощных библиотек, которые как говориться ready to use :) А у Cint есть биндинги к wxWindows, Qt, сетевые библиотеки, шифрование, доступ к базам данных ну и аналог ZODB тоже бы хотелось :)

> Читаем > http://www.lisp.org/table/glossary.htm#mop > а также > http://www.lisp.org/mop/concepts.html

> >>> тут тебе и mультиметоды, > >В плюсах? Да ещё не полных? Или Вы overloading с мультиметодами > путаете?

> Начнем с методов (цитата из http://www.lisp.org/mop/concepts.html) > "A method metaobject contains information about a specific method"

> все metaobject классы содержатся тут: > http://root.cern.ch/root/html/META_Index.html

> "information about a specific method" представлена TMethod классом ? > http://root.cern.ch/root/html/TMethod.html

> Кстати вся ROOT HTML документация сгенерирована автоматически > на основе имеено этой metaobject информации

"Бобёр, ты не вкурил". Мультиметоды - это нечто совсем другое. Чем-то очень и очень издали похоже на специализацию темплейтов в плюсах, только в рантайме. Вот, например, никем не используемая попытка добавить их в плюсы - с описанием: http://www.op59.net/accu-2003-multimethods.html Язык на самом деле для таких вещей просто не предназначен, объектная модель плюсов - single dispatch или "передача сообщений".

>>> и символьные выражения, >>Хде?

> Примером "символьные выражения" является TFormula класс > http://root.cern.ch/root/htmldoc/TFormula.html

> Живой пример, как это работает можно попробывать здесь > http://carrot.cern.ch/CarrotExamples/hsimple.root?/2764078/ntuple;1/

> Наберите в поле "Expression" что-нибудь типа "sin(px)/px"

Не, а чтоньть вроде кода в виде символьных выражений? Или `(html (head (title ,document-title)) (body (h2 ,document-title) ,document-contents)) ? cons cells?

>>> и metaprogramming, >>C++ Templates что ли? Или C preprocessor? Не смешите мои тапочки. > Да, я порядком >работал с C++ BOOST. Сравнивать это убожество с >Лисповским defmacro - всё равно >что сравнивать детский лесопед с >МиГ-29...

>ROOT позволяет динамически подгружать разделяемые библиотеки. >Классы содержашиеся в этих библиотеках автоматически становятя >доступны интерпретатору, чем не defmacro?

А могу я в эти плюсы добавить чтоньть вроде, например, with_mutex_lock (my_mutex) { do_something(...); } (подразумевается автоматическая защита от повисания блокировки мьютекса при исключении)?

>>>> и нормальный REPL >>Ни в жисть не поверю.

>1. запусти ROOT >2. командную строку >3. и занимайся REPLингом

А вот я слот (data member/field в терминах убогих языков) в класс добавил, надавил F5 в емаксе (забиндено у меня так), и класс проапдейтился в работающем имейдже Лиспа, вместе со всеми существующими в данный момент instances? А? Или хотя бы то же самое сделать с простой функцией или методом? А как насчёт TRACE, TIME?

>Могу еще добавить, что в ROOTе есть такое мошьная концептуальная >вещь, как синалы-слоты >http://root.cern.ch/root/HowtoSignalSlot.html

> которая, на пример, позволяет динамически (из интепретатора) методы > класса. У нас это называется "class connection"

А в Лиспе, да вроде и в Питоне тоже (равно как и в JavaScript'е ;-) , есть такая концептуальная вещь, как lamdba и closures, и она делает эти самые сигналслоты ненужными в одних случаях, и реализуемыми в две-три строчки кода в других ;-)

поверь мне мой юнный друк, изобретающие очередной скриптовый язык выглядят намного хуже ;)

имхоист злостный? подрастешь - опыт. время вылечит. это вроде как юношеско-максималистическое - "а, твой телефон без камеры и без джабы? выкинь! нах такой телефон!"

CINT/ROOT vs Python

Вот такой флейм мне нравиться ;-)
>"Бобёр, ты не вкурил". Мультиметоды - это нечто совсем другое.

Теперь согласен, не туда посмотрел

>Чем-то очень и очень издали похоже на специализацию темплейтов в плюсах, только >в рантайме.

btw, y нас темплейты в рантайме есть. Более того есть и STL в рантайме.

>Вот, например, никем не используемая попытка добавить их в плюсы - с описанием: >http://www.op59.net/accu-2003-multimethods.html

Это просто детский лепет ...
Повторяю, у нас есть "full RTTI" - мы знaем об обьекте ВСЕ! Вплоть до
комментриев в "class declaration". Не говоря уж о том кто он такой, от
кого наследован ... вплоть до всех его пращуров.

>Язык на самом деле для таких >вещей просто не предназначен, объектная модель >плюсов - single dispatch >или "передача сообщений".

После вышеизложенного, я надеюсь Вы измените свое мнение.

>Не, а чтоньть вроде кода в виде символьных выражений? Или `(html (head
>(title ,document-title)) (body (h2 ,document-title) ,document-contents)) ?
>cons cells?

Честно, не совсем понял .. по-подробнее, plz

>А могу я в эти плюсы добавить чтоньть вроде, например, with_mutex_lock
>(my_mutex) { do_something(...); }

Угу, можно.

>А вот я слот (data member/field в терминах убогих языков) в класс добавил, >надавил F5 в емаксе (забиндено у меня так), и класс проапдейтился в работающем >имейдже Лиспа, вместе со всеми существующими в данный момент instances? А? Или >хотя бы то же самое сделать с простой функцией или методом? А как насчёт TRACE, >TIME?

Может не совсем то:
root [0] .L Tetris.dll
root [1] Tetris t

корректируем class Tetris

root[2]gROOT->Reset()
root [3] .L Tetris.dll <-- новый Tetris
root [4] Tetris t <--- играем в улучшенный Tetris

Signal-Slots:
это - концепция черного ящика со входами и выходами (чип в электронике)
Имеем 2 DLL (Tetris, Aclock) написанные разными людьми
Aclock имеет сигнал "Время_обедать"
Tetris имеет метод (в ROOTe любой метод может быть слотом) "Стоп"

root [0] .L Tetris.dll
root [1] Tetris t
root [2] .L Aclock.dll
root [3] Aclock a
root[4]a->Connect("Время_обедать()", &t, "Стоп()")

когда натанет "время обедать" - игра закончится

CINT - чисто интерпретатор.

Вообще этих биндингов, как грязи ...
http://root.cern.ch/root/ExApplications.html
... и нет проблем добавить еще один.

Только у ROOTа, см. http://root.cern.ch/root/Categories.html
- это не все, включая http://root.bnl.gov/

> доступ к базам данных
есть

Но, вот это http://carrot.cern.ch/~onuchin/RDBC/
я хотел бы добавить в ROOT ASAP.

да, у нас есть еще "свой wxWindows/Qt"
http://root.cern.ch/root/htmldoc/TGuiBuilder.html

(Озабоченно, почти испуганно) Куда метапрограмминг дели?

> А вот я слот (data member/field в терминах убогих языков) в класс добавил, надавил F5 в емаксе (забиндено у меня так), и класс проапдейтился в работающем имейдже Лиспа, вместе со всеми существующими в данный момент instances? А? Или хотя бы то же самое сделать с простой функцией или методом? А как насчёт TRACE, TIME?

Круто, возьми с полки пирожок. Правда, не понимаю, чему тут удивляться.

Кусочек из моей местной xml_enhancements.py
-------------
...
from xml.dom.minidom import Element, Document

from itertools import ifilter

def innerText(obj):
.    if not obj.hasChildNodes():
.        return ''
.    else:
.        return ''.join([child.toxml() for child in obj.childNodes])

Element.innerText = property(fget = innerText,  doc = "A R/O property to retrieve inner content of an element")
...

Ну, и, разумеется, теперь все экземпляры x.d.m.Element имеют соответствующую property.

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

> которая, на пример, позволяет динамически (из интепретатора) методы класса. У нас это называется "class connection" 

Супер. А чем это лучше чем:
----------
def g(arbitrary_callback): return arbitrary_callback()

class A(object):
.    def f(self):
.         print "a.f()"

a = A()
g(a.f)
----------
за исключением более странного синтаксиса? Или я чего-то все же недопонимаю в колбасных обрезках?

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

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

0. "Питон проще".
Интерeсно, что когда Qt начали разрабатывать их QSA, на аналогичный
вопрос был примерно такой же ответ - "C/C++ - это не для л'юзеров,
а для людей with Comuting Sience Degree"

1. Другой часто встречающийся аргумент - CINT не покрывает всего
C/C++ стандарта, поэтому возникают bugs, не по вине л'юзера.
Особенно, проблемы на уровне C-preporcessorных директив #define, и пр.
Ваще, полезно прочитать http://root.cern.ch/root/Cint.phtml?limitations

В этом смысле Питон преставляется, как "bug-free langauge".
btw, гурус, так ли это?

На этот аргумент есть одно хорошее правило - не доверяй CINTу,
всегда пропускай скрипт через компилятор, а лучше всего через
разные компиляторы.

2. почему-то все молчат о ZOPE?

Ну насчет удобства - это вопрос личных предпочтений. Ну а статическая типизация должна быть базовым принципом разработки языка, а не добавляться как некоторая необязательная возможность. Статическая типизация ГАРАНТИРУЕТ, что нетипобезопасный код не будет скомпилирован и тем более частично выполнен.

Если язык "исключительно динамический", то зачем добавлять к нему статичекую типизацию? Не нужно пытаться создать один язык для всех приложений. Python хорошо подходит на роль встраиваемого скриптового языка (здесь динамическая типизация скорее преимущество, чем недостаток), но не годится в качестве языка для написания сложных программных комплексов, со сложными алгоритмами обработки данных (там где наиболее ощутима польза от статической типизации).

это так офф-топик:
http://lcg.web.cern.ch/LCG/jobs/vacancies.htm#AA

Re:

Я не понял, что _еще один_ виджет сет?

Re:

> "почему Питон?".

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

Примерно так же и языки программирования ранжируются.

> 0. "Питон проще".

Он не проще. Он... естественнее, что ли (это в данный момент, и с моей точки зрения). К тому же, язык по природе своей аполлонический и все богатство языка выражается через минимальное количество словоформ (Гвидо в одной из обсуждаемых статеек говорит об этом как "питоновский парсер примитивен"), что, в общем, способствует хорошей понимабельности чужого кода (нормальные писатели перловых модулей, н-р, тоже стараются избегать всяких фирменных перловых вычурностей).

Кстати, питон, в общем, и создавался скорее как академический язык людьми с computer science degree. Другое дело, его сейчас уже можно использовать и для ремесленных поделок неплохого качества (что-то я не наблюдаю большого количества ремесленных поделок на лиспе :-)).

> 1. Другой часто встречающийся аргумент - CINT не покрывает всего C/C++ стандарта, поэтому возникают bugs, не по вине л'юзера.

Ой, это ваши личные половые трудности, с C++ стандартом :-). Вообще, в C++ стандарте есть такие моменты, которых лучше бы не было. Я даже некоторое время назад помнил страницу в последнем страуструповском издании (на русском, ну, толстая такая, в мягкой пегой обложке), что-то там с темплейтами связанное, от которой возникает вопрос "ну почему??", и ответ на этот вопрос получить было довольно сложно.

Насколько CINT способствует адекватному выражению собственных мыслей в сравнении с питоном или там, н-р, перлом? А хрен его знает, я что, писал на нем? ;-)

> "bug-free langauge"

Не, ну имплементация cpython, в общем, довольно предсказуема :-). Или про то, получаются ли на нем bug-free программы? Дак это от писателя зависит, и от того, что и как он делает, разве нет? :-)

> 2. почему-то все молчат о ZOPE?

zope. Zope. ZOPE. Так достаточно? ;-) Или чего-то другого услышать хотелось? ;-)

Re:

> Статическая типизация ГАРАНТИРУЕТ, что нетипобезопасный код не будет скомпилирован и тем более частично выполнен.

А какое-нибудь средство от вообще любых ошибок существует? ;-)

> Если язык "исключительно динамический", то зачем добавлять к нему статичекую типизацию?

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

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

Ну, я не буду, конечно, говорить "нудащаз", поскольку все написанные при моем участии "программные комплексы" на питоне вряд ли могут называться "сложными", но, натурально, не так страшен черт. Что касается "статической типизации для алгоритмов", то есть psyco.

Что же касается контроля за коррекностью кода, то, натурально, юнит-тесты, и, опционально, контроль интерфейсов в стиле Твистеда (хотя тамошние гуру и скептически относятся к идее interface checker'ов)

Re:

> Что касается "статической типизации для алгоритмов", то есть psyco.

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

хе-хе, знатная буча поднялась после этих двух статей:
http://www.pythonware.com/daily/

Есть ещё Lua (www.lua.org) и он лучше подходит на роль встраиваемого скриптового языка. Не зря же его используют в играх... Простой, понятный и элегантно-концептуальный! :)

Re:

> Я не понял, что _еще один_ виджет сет?

ugu

Re:

>>К тому же, язык по природе своей аполлонический...
А какой язык у нас тогда дионисийский? (Испуганно озираясь и шепотом) - уж не перл ли?

CINT vs Python

Спасибо всем кто отвечал на "Зачем Питон?"

забыл, "С Рождествон Христовым!"

"... наверно, точно напьюсь ... " (ДДТ)

Re:

> Для производительности, в основном.

Вот с производительностью и возникают проблемы при добавлении статической
типизации (по ГВР) в случае:

# foo :: int -> int -> int
def foo(a : int, b : int): 
    return a + b

# bar :: any -> any -> any
def bar(a, b):
   foo(a, b)

Предлагается для обеспечения нормальной производительности ввести вывод типов.
Если продолжить этот вывод, то ВСЕМ функциям должен быть приписан некоторый
тип. Если тип параметра не объявлен, то считается any (см. статью ГВР). Вывод типов
по ГВР должен обеспечить проверку (динамиескую) типов как можно раньше. Вместо
этого можно было бы приписать bar тип int -> int -> int. Получив таким образом 
МАКСИМАЛЬНО точные типы можно исключить динамическую проверку типов.

> Плюс, к тому, там, где это уместно, это неплохое подспорье для программиста. 
Согласен.

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

ЗЫ: контроль интерфейсов: зачем он нужен при статической проверке типов? юнит-тесты - это из другой области (т.к. типобезопасность не гарантирует правильности программы) они в любом случае нжны.

Re:

Э-э-э, фтопку?

Не то, чтобы я был противником нового и ретроградом, но и с имеющимися головняка предостаточно ;-)

Re:

"Ты знал, ты знал" :-)

А еще есть различные вариации на тему C и, как мне показалось, ruby. В общем, ничего страшного, вопрос в том, опять-таки, в прокладке между стулом и клавиатурой :-).

Re:

> Вот с производительностью и возникают проблемы при добавлении статической типизации (по ГВР) в случае:

Ну, это проблемы GvR, натурально. Судя по "описанию для простых парней" принципов работы psyco, по идеологии Pyrex и тому, что удается выудить из презентаций на тему starkiller, статическая типизация, будучи примененной к месту рулит. psyco обещает до 100x производительности на сложных алгоритмах.

> Получив таким образом МАКСИМАЛЬНО точные типы можно исключить динамическую проверку типов.

Жить программистам станет сильно сложнее. И пресловутый полиморфизм сильно пострадает. Собственно GvR там и пишет, что очень не хотелось бы связывать "родственными отношениями", скажем, int и float, а "строгая типизация везде и всегда" этим грозит.

> ЗЫ: контроль интерфейсов: зачем он нужен при статической проверке типов? юнит-тесты - это из другой области...

Поставим вопрос по-другому: зачем нужная строгая типизация _программисту_ (а контроль за логическими ошибками - это всё-таки, в основном, его забота, механический мужик только указать на них может), если известно, что с объектом выполняются только то операции, которые допустимы для данного объекта? По-моему, незачем. А контроль за тем, что операции соответствуют заявленным - это как раз и есть контроль за интерфейсом, причем _частичным_ (ну, то есть проверяется не вообще весь интерфейс, а только некоторое его подмножество, требующееся в некотором куске кода). А вот эта задача уже сейчас решается имеющимися в питоне средствами (глядеть в твистед, чтобы понять, о чем я).

Хотя, на самом деле, меня на #twisted убеждали, что и этого не нужно. Достаточно, чтобы объект проходил все свои юнит-тесты. Они там экстремалы :-), хотя, вообще говоря, и это точка зрения вполне разумна :-)

Lua (пятый, во всяком случае), увы, не язык _программирования_. То есть, не самостоятельный язык. Когда вся обработка ошибок отдана вызывающему C-коду - это грустно. На самом деле, я был огорчен, когда прочитал полностью его описание.

> Lua (пятый, во всяком случае), увы, не язык _программирования_. То есть, не самостоятельный язык. Когда вся обработка ошибок отдана вызывающему C-коду - это грустно. На самом деле, я был огорчен, когда прочитал полностью его описание.

Наверное, не понравилась своеобразная обработка исключений (pcall)? А мне не нравятся исключения python'а. Предпочитаю явно проверять результат функции (и в lua, обычно, возврат nil - ошибка).

Почему не самостоятельный язык? Модули на C и скрипты на lua - не вижу отличий от python'а.

> Предпочитаю явно проверять результат функции (и в lua, обычно, возврат nil - ошибка).

Ну, о вкусах, конечно, не спорят.Я предпочитаю проверять ошибки там, где я могу с этими ошибками что-либо сделать. К тому же, возникают всякие вопросы относительно "вкусностей" - разных типов ошибок, доступности стэктрейсов и т.п. Хотя и питон, вероятно, не слишком далеко ушел от "плюсоподобной" обработки ошибок. Наиболее гибкая система, пожалуй, в перле, сочетающая подход как "исключений С++", так и REXX'оподобных CONDITION'ов. Ну, разумеется, c поправкой на эклектичность перла и его синтаксиса ;-)

C++ - дико убогий язычок. Писать на нем что-то высокоуровневое будет только безграмотный дурачок вроде тебя.