Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
ANS>Влад, абстракция без простоты это фигня какая то.
А теперь ты путаешь "простоту использования" и "простоту реализации" Это вообще вещи обычно обратно зависимые.
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
Не надо вырывать строки из контекста, а то действительно ерунда выходит. Там шла речь примерно о таком:
От подхода А отказались в пользу подхода B (приводились примеры 2-х конкретных реализаций подхода B: языки С и D), в конечном счете все-равно выбрали именно подход B, используя конкретную его реализацию в языке E. Ну вот показалось им, что использовать реализацию подхода B с помощью E лучше для условий их задачи, чем с помощью C и D
Я лишь добавил пару комментов к их выбору... Что у тебя не складывается, по прежнему не понятно.
Здравствуйте, Cyberax, Вы писали:
C>mihoshi wrote:
>> C>Студенты плевались сильно и качество их программ было на очень низком >> C>уровне (они их писал в паскалевском стиле). Несколько раз было >> прикольно >> C>- ко мне по аське обращались с просьбами сделать практические задания, >> C>которые я же и помогал сочинять. >> Это нормальная реакция при использовании нового инструмента.
C>Ну так спросили о мнении людей о С++, которые с ним знакомы всего пару C>месяцев. Потом спросили мнение людей о Лиспе — я ответил.
>> Достоинствами человек пользоваться не умеет, а любые отличия от >> привычного видит как недостаток. Если не учить правильно обращаться с >> инструментом и не требовать этого от учеников, то толку от этого не будет.
C>Да, но некоторым студентам понравилось такое извращение, как Refal C>(крестики-нолики на Refal'е — это сильно). Лисп не понравился никому — а C>это тоже показатель.
Не знаю — когда нам LISP переподавали — мне он сразу понравился.
Вот когда я с паскаля на с++ перелазил — плющило меня конкретно.
А сейчас С++ — мой второй язык после русского.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
V>Не надо вырывать строки из контекста, а то действительно ерунда выходит. Там шла речь примерно о таком: V>От подхода А отказались в пользу подхода B (приводились примеры 2-х конкретных реализаций подхода B: языки С и D), в конечном счете все-равно выбрали именно подход B, используя конкретную его реализацию в языке E. Ну вот показалось им, что использовать реализацию подхода B с помощью E лучше для условий их задачи, чем с помощью C и D
Извини, но мне кажется ты слишком сильно додумываешь написанное другими. По этому и получается, что ты рассуждашь о вещах которых нет в природе. Вот и с моими словами тоже самое. Ты споришь не с ними, а сам с собой. Я в общем-то не против. Но я вряд ли буду тебе полезен.
V>Я лишь добавил пару комментов к их выбору...
А они тебя просили?
V>Что у тебя не складывается, по прежнему не понятно.
У меня? Ты сейчас с кем и о чем разговаривашь?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>Главная идея такая, что дальнейшее развитие самых популярных языков (С++, C#, Java) в конце концов сделает из них Лисп
Не. С++ не сдастся. Его очень хорошо оберегают от всякой заразы. В принципе правильно. Шаблоны есть? Есть! Больше ничего не нужно.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Я же тебе говорю, что умение нормально программировать вообще в C++ оказывается недостаточно, поскольку есть масса мелких технических заморочек, которые постоянно нужно принимать во внимание.
А я тебе говорю, что ты пыташся изобразить С++-ников как некую элиту. А на самом деле это не так. Нормально программировать нужно уметь для любого языка и любого проенкта. А вот хреновый программист действительно на С++ способен наплодить больше бед (по сравнению с типобезопасными языками).
E> И вот тут ты мне объясняешь, что "нормальное программирование" + знание этих мелких деталей и есть "нормальное программирование на C++".
Без знания особенностей инструмена нормального прогаммирования не выйдет. ПК впервые пытаясь написать код на C# мочил еще те перлы. А он у нас в верху топа.
E> Так ведь я об этом сразу сказал. И сразу сказал, что специалистов, которые "нормально программируют на C++" мало, и искать их, в нашей провинции, нужно днем с огнем. Или самим воспитывать из того, что есть.
Еще рез. В С++ просто страшнее последствия. Ловить баги за ламерами тяжелее. А проблемы от ламера будут везде.
E>Опять повторю, про элитарность (в смысле того, что C++ программист круче всех и выше всех остальных на две, да нет, на три головы) я не говорил. Я говорил про недостаточное количество толковых C++ программистов.
Это и есть признание С++ элитарным. Толковых программистов не хватает в принципе. И С++ тут не причем.
E>Боюсь, что если человек счел себя достаточно граммотным в C++, чтобы опубликовать статью с подобными ляпами, то здесь есть всего две дороги: либо сесть за изучение классиков типа Страуструпа, Александреску и Саттера, либо перейти на язык с GC. Думаю, что второй вариант гораздо проще.
Боюсь, что ты принципиально не понимашь ситуации. На этом воруме есть человек 5 С++-программистов которые понимают всю опасность С++ и осознают необходимость использовать только небольшой сабсэт этого языка затыкая его баги "умными" обертками. Остальные же ради экономии времени или еще ради чего нибудь спокойно плюют на это. При этом им ничего не мешает себя считать круче паравоза и даже с пренебрижением смотреть на остальных. Посмотри в мой профайл и поверь мне на слово. Я постоянно сталкиваюсь с подобным. Просто в последнее время С++-а стало заметно меньше. А так...
E>Да вот, пытались делать все свои проекты на нашем SObjectizer-е. В общем случае получалось средненько. И по объективным, и по субъективным причинам. Но переучить явщиков как раз не получилось. Поэтому теперь явщики программируют на Яве, а C++-ники на C++.
Я, к сожалению, снова в офлайне и по ссылка кликать мне тяжело. Нелья ли на пальцах обяснить область разрботки. Ну, там автоматизация бизнеса, создания инструментов для 3D-моделирования...
E>Это было бы смешно, если бы не было так грусно. Обычно бывает так: я приблизительно оцениваю, что на решение задачи требуется неделя. Поскольку у меня есть склонность слишком оптимистично занижать сроки, я делаю поправку и декларирую две недели. Обычно, в лучшем случае, решение приносят через месяц.
Коэффициент не верный. Даво известно, что слова программиста о сроках нужно уможать на 4. Но причем тут С++ и т.п.?
E>Не какое-то, а вполне конкретное. В C++, в отличии от Java или Ruby, на которых мне довелось попрограммировать, очень много внимания нужно уделять мелким техническим деталям (которые, при их игнорировании становятся большими занозами в заднице). И специалистов, которые считают нормальным такое внимание к этим деталям действительно становятся все меньше и меньше. Чему лично я вижу два объяснения.
Я как бы согласен с тем, что программируя на С++ ты большую часть времени расходуешь не продуктивно. Но это еще не значит, что хороший программист не сможет научиться это делать. Плеваться будет, но научится.
Я могу привести в пример себя. Кодируя на С++ я как бы спровлялся с этими проблемами. И даже не пробуя альтернативу свыкся с этим и не особо крехтел. Но попробовав эту самую алтернативу и вернувшись обратно к С++ я начал плеваться так же как твои явщики.
Кстати, школа С++ не прошла даром. Контроль ресурсов на using-е у меня уже в крови. Но я знаю кучу людей пришедших не с С++ которые точно так же отлично контролируют ресурсы using-ом. Так что...
E>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше.
Альтернативы были есть и будут. То же дельфи появилось более 10 лет назад. Ява, кстати, в следующем году тоже червонец отметит.
E>Во-вторых, сейчас C++ уже не мейнстрим.
Я плякаль. Что не скажешь лиш бы почувствовать себя элитой.
E> Это слишком сложный язык. На его изучение нужно тратить слишком много времени. А тратить много времени сейчас не любят. Начинающему специалисту гораздо проще освоить Java, C#, VB, Python и найти оплачиваемую работу согласно своему уровню подготовки не тратя лишнее время на такую сложную штуку, как C++.
Понимаеш ли. Твои слова про сложность С++ — это не правда. Как язык C# значительно сложнее. Он обладает куда большим объемом кострукций не говоря уже о их применении.
Сам С++ относительно простой язык. Сложно же в нем обходить грабли. Вот тут действительно нужно выроботать привычку использовать только безопасные паттерны. Ну, и сложно следить за теми самыми мелочами. Однако сложность использования и сложность продукта не коррелирую между собой. К примеру, телевизор очень не простой продукт, то использовать его может трех-летний ребенок.
E>Я у себя такого не замечал. А если ты между моих строк видишь какие-то намеки на элитарность, то ничего поделать не могу. "У нас свобода сновидений".
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
Переведи это на русский. И посторайся избавить этот перводо от слов вроде "кривым".
ANS> и как его реализовать на C#1.
Реализовать интерфейс?
ANS>Влад, абстракция без простоты это фигня какая то.
Здравствуйте, pvgoran, Вы писали:
P>1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
Абстрагироваться от реализации можно и на ассемблере. Но реализация будет сложнее.
P>2. Т.е. тот же ООП как инструмент абстракции излишен?
Почему? Во многих облостях он более удобен. Причем удобне для тех кто реализует абстракцию. Но если опять таки не говорить сложности реализации, то процедур для абстрагирования достаточно.
P>3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
Брать перегрузку операторов, да еще и изменение их семантического смысла, в даном случае, не стоит. К абстракции это отношения не имеет. Это всего лишь изменение синтаксиса языка. Причем основанное на безолаберном отношении языка к безопасности кода. Вывод же данных в поток или на консоль астрагирован в любом языке. Просто обычно это делается банальной процедурой.
P>Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
Воможно и LL(k). Сути дела это не менят.
P>Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
Теме не кажется, что использование внутренних классов парсера несколько странно?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Долго думал, что лучше -- просто поставить минус и не отвечать, или же дать пространный ответ с возражениями по каждому из твоих утверждений. В результате вот что получилось.
Нельзя уметь нормально программировать на любом языке и для любой задачи. Нейронные сети на ПЛИСах, SQL запросы к БД, принятие решений на Прологе, поддержка стека протоколов GSM на ассемблере какой-нибудь SIM карточки, лексический и синтаксический анализ на Java, большие распределенные математические вычисления на Fortran-е, разрешение блокировок и оптимизация доступа к страницам БД на C/C++. Много ли найдется программистов, которые смогут научится нормально решать все эти задачи? А им это вообще нужно?
Рейтинги RSDN или чьи-либо профайлы для меня совершенно не являются показателем практической полезности программиста. Просто потому, что на практике один трудолюбивый середнячек с минимальным необходимым набором знаний спокойно делает супер-эрудитов/философов/экспертов/пр. -- он работает.
Процент толковых программистов в любой технологии действительно является константной величиной. Вероятно, описываемой законом 20/80. Проблема в том, что в количественном выражении 20% от ста тысяч будет гораздо меньше, чем 20% от миллиона. А когда ищещь спеца на работу важны как раз не абстрактные проценты, а те реальные единицы, которых нужно найти. Имхо, для C++ количественное выражение этих 20% в последнее время неуклонно снижается.
Недостаточное количество != элитарности. Я помню восьмидесятые годы и такие дефициты, как колбаса или туалетная бумага. Можно ли было считать туалетную бумагу или московскую колбасу элитой среди прочих товаров? Можно ли вообще оценить, более ли элитарна туалетная бумага, чем колбаса. Или же все наоборот. Имхо, элита может существовать в рамках какой-то одной категории. Например, среди C++ программистов точно есть своя элита. Так же, как в C#, Java или Lisp-е. Но я никогда не утверждал, что С++ программисты -- это элита по сравнению со всеми остальными программистами. Я лишь говорил где-то, что после C++ нет проблем перейти на Java или C# (я среди своих знакомых это видел, да и ты сам про это говоришь). А вот обратных примеров я не видел, но и не утверждаю, что это невозможно. Если, по твоему мнению, подобные мои высказывания являются пропагандированием элитарности C++ -- ну пусть так и будет, аминь. В конце-концов, лично я нуждаюсь в том, чтобы вокруг было больше С++. И если это кого-то подвигнет на изучение C++, то я говорю: "Уважаемые читатели форумов RSDN, изучайте C++, программируйте на C++ -- дайте себе шанс стать программистской элитой!".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
VD>Абстрагироваться от реализации можно и на ассемблере. Но реализация будет сложнее.
Сложнее будет не только реализация, но и использование.
P>>2. Т.е. тот же ООП как инструмент абстракции излишен?
VD>Почему? Во многих облостях он более удобен. Причем удобне для тех кто реализует абстракцию. Но если опять таки не говорить сложности реализации, то процедур для абстрагирования достаточно.
Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
P>>3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
VD>Брать перегрузку операторов, да еще и изменение их семантического смысла, в даном случае, не стоит. К абстракции это отношения не имеет. Это всего лишь изменение синтаксиса языка.
Ну, все-таки не изменение, а скорее уточнение синтаксиса. Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
VD>Причем основанное на безолаберном отношении языка к безопасности кода.
Это почему??
VD> Вывод же данных в поток или на консоль астрагирован в любом языке. Просто обычно это делается банальной процедурой.
Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
P>>Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
VD>Воможно и LL(k). Сути дела это не менят.
А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
P>>Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
VD>Теме не кажется, что использование внутренних классов парсера несколько странно?
Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
Здравствуйте, VladD2, Вы писали:
ANS>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
VD>Переведи это на русский.
Какое именно слово тебе не понятно?
VD>И посторайся избавить этот перводо от слов вроде "кривым".
А вот в этом предложении есть непонятные мне слова.
ANS>> и как его реализовать на C#1.
VD>Реализовать интерфейс?
Поподробнее, пожалуйста.
ANS>>Влад, абстракция без простоты это фигня какая то.
VD>На это тебе очень хорошо ответил mihoshi
AndrewVK wrote:
> C>Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так > C>как очень часто NPE просто скрывает баги в коде. > Это зависит какой хендлинг. Если он после себя оставляет следы, > например ввиде записей в логе, то ничего не скрывается. А за пустой > catch в 99% случаев надо расстреливать на месте.
Ты видел мегабайтные логи исключений, которые выбрасывает JBoss? Могу
показать. Разобраться в них не очень просто — простой assert в самом
месте ошибки намного больше помог бы.
AndrewVK wrote:
> C>Ты видел мегабайтные логи исключений, которые выбрасывает JBoss? > Не видел. Хотя сам JBoss видел. Никакими мегабайтами там и не пахнет.
Могу прислать. Такие логи получаются, когда выбрасывается исключение с
вложенностью уровней в 30-40 и распечатывается потом на каждом уровне.
Здравствуйте, Cyberax, Вы писали:
C>Могу прислать. Такие логи получаются, когда выбрасывается исключение с C>вложенностью уровней в 30-40 и распечатывается потом на каждом уровне.
Во-первых все равно на мегабайт не потянет, а во-вторых то, что на каждом уровне распечатывается одна и та же информация это проблемы JBoss, а не исключений.
Здравствуйте, VladD2, Вы писали:
VD>Извини, но мне кажется ты слишком сильно додумываешь написанное другими.
Да нет, ты просто потерял нить разговора и уже давно. Вся ветка была о "клевом подходе" к разработке веба на LISP в эпоху CGI.
VD>По этому и получается, что ты рассуждашь о вещах которых нет в природе. Вот и с моими словами тоже самое. Ты споришь не с ними, а сам с собой. Я в общем-то не против. Но я вряд ли буду тебе полезен.
blah-blah-blah...
для тебя С++ — как красная тряпка для быка, удивляться его использованию в реальных проектах ты способен (намерен?) бесконечно.
V>>Я лишь добавил пару комментов к их выбору...
VD>А они тебя просили?
А тебя?
V>>Что у тебя не складывается, по прежнему не понятно.
VD>У меня? Ты сейчас с кем и о чем разговаривашь?
Ты привел с потолка взятый аргумент, насчет длины цикла, который я и оспорил. Занятно уже то, что твой же аргумент никак не относился к твоей же логике.
Ты бы определился, что не так? То, что не взяли Java, несмотря на фичи, или PHP несмотря на удобство разработки? О важности продолжительности цикла разработки для них в настоящий момент никто, кроме тебя не говорил (это было важно в эпоху CGI и отсутствия каких-либо RAD-ср-в разработки под веб). Речь там шла о всяких фичах, которые вполне достижимы на С++.
Возвращаясь к теме, очевидно, что просто требования у них устаканились, и величина цикла разработки стала конечной, какая бы она не была, потому и речь о ней уже не шла. Три месяца там или пять — какая для Google сейчас разница, если при текущем количестве их пользователей технические характеристики программного продукта начинают играть весьма заметную роль?
-----------
Ну, а насчет манеры ведения беседы — присоединяюсь к многочисленным просьбам в твой адрес выражаться по существу. Я отвечал на вполне конкретные твои слова. Посты, типа "Ты о чем? Ты кому? Кто тебя просил? Сходи туда..." лучше не писать вовсе, ИМХО.
AndrewVK wrote:
> C>Могу прислать. Такие логи получаются, когда выбрасывается исключение с > C>вложенностью уровней в 30-40 и распечатывается потом на каждом уровне. > Во-первых все равно на мегабайт не потянет
Ну ладно, с мегабайтом я погорячился. Но вот килобайт на 100 — запросто.
> а во-вторых то, что на каждом уровне распечатывается одна и та же > информация это проблемы JBoss, а не исключений.
В том-то и дело, что иногда где-то в цепочке исключение магическим
образом преобразуется в другой тип из-за наведенных ошибок. И такое не
сразу можно заметить.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
VD>>Переведи это на русский.
ANS>Какое именно слово тебе не понятно?
Выделенно жирным.
VD>>И посторайся избавить этот перводо от слов вроде "кривым".
ANS>А вот в этом предложении есть непонятные мне слова.
Не включай дурака.
ANS>>> и как его реализовать на C#1.
VD>>Реализовать интерфейс?
ANS>Поподробнее, пожалуйста.
Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
ANS>>>Влад, абстракция без простоты это фигня какая то.
VD>>На это тебе очень хорошо ответил mihoshi
Точнее не захотел. Ты постоянно путашь понятия. Абстракцию с внешней формой. Простоту абстракции и сложность реализаци скрываемой за абстракцией. У меня складывается ощущение, что ты делашь это намеренно. Если это не так, то просто обратись к словарям. Ну, а если так, то давно пора завязывать этот разговор. Все равно путного ничего не выйдет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, pvgoran, Вы писали:
P>Сложнее будет не только реализация, но и использование.
Ровно настолько насколько делать вызовы методов на ассемблере нежели на языке высокого уровня.
P>Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
Не нужно привлекать сюда заморочки КОМ-а. На С можно писать и так:
do_it(object);
Это конечно не винец творения, но более чем приемлемо.
P>Ну, все-таки не изменение, а скорее уточнение синтаксиса.
Нет, это именно изменение. Только конечно не синтаксиса, а семантики. Но это уже не важно.
P> Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
Нда. Ну, и чем:
stdхзч << i;
абстрактнее чем:
print(i);
VD>>Причем основанное на безолаберном отношении языка к безопасности кода.
P>Это почему??
Потому что в оригинале << это побитовый сдвиг влево. Плюс используется ошибка языка допускающая вычисления значений без присвоения их в переменную или передачи в качестве параметра.
P>Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
Чушь какая-то причем тут безопасность типов? Господа, отделяйте мухи от котлет.
Отсуствие расширяемости тоже звучит забавно. Создай новую процедуру и делай в ней все что хочешь.
P>Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
Нет, проблем — Abstraction (computer science)
P>А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
Суть в том, что это не библиотека предоставляющая примитивы.
P>Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
Можно ссылку на то, о чем ты ведешь речь?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>В том-то и дело, что иногда где-то в цепочке исключение магическим C>образом преобразуется в другой тип из-за наведенных ошибок. И такое не C>сразу можно заметить.
Это вообще вещи обычно обратно зависимые.
Я плякаль. Что не скажешь лиш бы почувствовать себя элитой. 
