Здравствуйте, VladD2, Вы писали:
VVD>РСДН изначально был С++-ным сайтом. Почти все кто стоял у его истоков (и даже я) был С++-ником до мозга костей. Любое голосование тип "Ххх sv. C++" на этом сайте несколько лет назад был бы проигран с разгромным счетом. А теперь дивись
И что это доказывает? Привлекательность "направления .NET/C#" для... для кого? Или попросту то, что те, для кого привлекателен C# чаще заглядывают в "голосования"?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
: вместо исправления ситуации ошибку "замазали" требованием поддержки множественных вызовов Dispose. При этом сами же признают, что ошибки таким макаром прячутся: > ПК>
> ПК>Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
> ПК>of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.
> ПК>
> Я вижу только безграмотную реализацию паттерна. <...>
Это да, ошибку я сделал.
Но при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
> От таких ошибок не застрахует ни один язык. Это банальное не понимание паттерна.
Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
VladD2,
> ПК> Легко. Исключение в finally во время обработки уже выброшенного исключения. Первое при этом потеряется. Одна ошибка уже скрыта
> Эдак можно и до радио докапаться. В catch тоже исключения ведь могут быть.
Могут. Это одна из причин, почему catch лучше для освобождения ресурсов не использовать. Но с catch ситуация все же немножко лучше: туда мы попадаем только в случае обработки исключения, а в finally — всегда. Соответственно, в finally особенно сложно писать код, который бы не глотал исключения. И реально исключения зачастую глотаются. Собственно, в этом разница с C++, где легче получить abort(), чем на практике "проглотить" исключение.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И что это доказывает? Привлекательность "направления .NET/C#" для... для кого? Или попросту то, что те, для кого привлекателен C# чаще заглядывают в "голосования"?
Это пказывает, что даже С++-программисты (которые как раз значительно чаще заглядывают в голосования, как показывает практика) и сами осознают большую перспективность дотнета нежели нэйтив-С++-а. Ну, или то что относительная популярность дотнета ростет.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach.
foreach — это синтаксический сахар позволяющий быть менее многословным для выражения паттерна перебора. Абстракцией он не является. Абстракцией является интерфейс IEnumerable и IEnumerable<T>. Они кстати, я взык не вмонтированы.
ANS>Или итераторы C#2 те же.
Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это пказывает, что даже С++-программисты (которые как раз значительно чаще заглядывают в голосования, как показывает практика) и сами осознают большую перспективность дотнета нежели нэйтив-С++-а. Ну, или то что относительная популярность дотнета ростет.
Нет. Это показывает, что за одинаковые деньги люди скорее будут работать на C# чем на Си++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это да, ошибку я сделал.
ПК>Но при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
Это какое мое требование замазывает ошибки?
ПК>Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
Там ровно одна ошибка. Второй случай, то просто упрощенный вариант. И это на 2.5 метра кода две трити которого писали не самые квалифицированные специалисты. Не думаю, что эта статистика говорит о том, что этот паттерн является реальной проблемой. Тот же foreach куда чаще используется, но почему-то тебя он не волнует, хотя ошибки вроде выхода за границу массива бывают куда чаще.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Могут. Это одна из причин, почему catch лучше для освобождения ресурсов не использовать.
Ну, и чем тогда отличие C# в замазывании ошибок от С++.
ПК> Но с catch ситуация все же немножко лучше: туда мы попадаем только в случае обработки исключения, а в finally — всегда.
Ну, то-есть в finally мы не всегда потеряем информацию об исключении. Серьезная проблема однако.
ПК> Соответственно, в finally особенно сложно писать код, который бы не глотал исключения. И реально исключения зачастую глотаются.
Зачастую? Можно статистику? Я на своем веку еще не разу с такой ошибкой не сталкивался.
ПК> Собственно, в этом разница с C++, где легче получить abort(), чем на практике "проглотить" исключение.
Большое достоинство языка... простота получения вылета.
ЗЫ
И все же хотелось бы или услышать рельные обоснования утверждении о том, что Шарп замазывает ошибки, или признание не правоты.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
> Это какое мое требование замазывает ошибки?
Не твое, а спецификации. Требование поддержки множественных вызовов Dispose. (Множественные вызовы Finalize, обусловленные "воскрешением", не считаем).
> ПК> Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
...
> Там ровно одна ошибка. Второй случай, то просто упрощенный вариант.
Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
Ах в этом смысле. Да, действительно. Нужно было позвать base.Dispose(). Это АВК был не прав.
Вот только такую ошибку и без всяких паттернов можно залепить.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
> Ах в этом смысле. Да, действительно. Нужно было позвать base.Dispose(). Это АВК был не прав. > > Вот только такую ошибку и без всяких паттернов можно залепить.
Интересно, как можно не вызвать деструктор базового класса?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
E>>В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям.
VD>Это включается в понятие "просто уметь нормально программировать на С++".
Вначале мной было сказано:
А вот с C++-ом ситуация сложнее. Для того, чтобы нормально программировать на C++ и включится в большой, уже идущий проект, необходим уровень выше среднего.
На что ты мне возразил:
Полная ерунда. Чтобы нормально программировать нужно просто уметь нормально программировать. И человек поверхносно знающий С++ ничем не будет отличаться от человека поверхносно знающего C#.
Я же тебе говорю, что умение нормально программировать вообще в C++ оказывается недостаточно, поскольку есть масса мелких технических заморочек, которые постоянно нужно принимать во внимание. И вот тут ты мне объясняешь, что "нормальное программирование" + знание этих мелких деталей и есть "нормальное программирование на C++". Так ведь я об этом сразу сказал. И сразу сказал, что специалистов, которые "нормально программируют на C++" мало, и искать их, в нашей провинции, нужно днем с огнем. Или самим воспитывать из того, что есть.
VD> Ну, и по совместительству является недостатком языка усложняющим разработку.
С этим полностью согласен.
E>> В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код.
VD>С++-программисты недавно перешедшие на C# тоже делают не мало глупостей. Виной тому не какая-то эллитарность C#, а банальные привычки и попытка применять паттерны которые были нормальными в другой технологии, но бессмысленны или вредны в этой.
Опять повторю, про элитарность (в смысле того, что C++ программист круче всех и выше всех остальных на две, да нет, на три головы) я не говорил. Я говорил про недостаточное количество толковых C++ программистов. Если недостаточное количество для тебя эквивалентно элитарности, то это твои личные проблемы мировосприятия.
E>>И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами.
VD>Научи этом "матерых С++-ников" с этого сайта. У нас в половине статей delete или разные вариации free используются направо и налево. Вот, например, третья же статья в поиске по статьям выдала: VD>http://rsdn.ru/article/patterns/singleton.xml
VD>Что будет при исключении думаю ты и сам понимашь. И таких случаев море.
Боюсь, что если человек счел себя достаточно граммотным в C++, чтобы опубликовать статью с подобными ляпами, то здесь есть всего две дороги: либо сесть за изучение классиков типа Страуструпа, Александреску и Саттера, либо перейти на язык с GC. Думаю, что второй вариант гораздо проще.
E>> А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.
VD>Интересно, а какие задачи вы заставляете решать на С++ бывших Явщиков?
Да вот, пытались делать все свои проекты на нашем SObjectizer-е. В общем случае получалось средненько. И по объективным, и по субъективным причинам. Но переучить явщиков как раз не получилось. Поэтому теперь явщики программируют на Яве, а C++-ники на C++.
VD>>>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.
E>>С понтами -- это те, кто говорят: "Да дайте любую задачу, я вам щас ее за 5 минут!". А после пятиминутного махания шашкой оказывается, что решения, в лучшем случае, приходится ждать в два раза дольше намеченного срока.
VD>10 минут?
Это было бы смешно, если бы не было так грусно. Обычно бывает так: я приблизительно оцениваю, что на решение задачи требуется неделя. Поскольку у меня есть склонность слишком оптимистично занижать сроки, я делаю поправку и декларирую две недели. Обычно, в лучшем случае, решение приносят через месяц.
E>>Покажи мне, пожалуйста, где я говорил о нашей кастовости?
VD>Ты постоянно подчеркивашь какое-то различие между С++-программистами и другими. И найти их сложнее.
Не какое-то, а вполне конкретное. В C++, в отличии от Java или Ruby, на которых мне довелось попрограммировать, очень много внимания нужно уделять мелким техническим деталям (которые, при их игнорировании становятся большими занозами в заднице). И специалистов, которые считают нормальным такое внимание к этим деталям действительно становятся все меньше и меньше. Чему лично я вижу два объяснения.
Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
Во-вторых, сейчас C++ уже не мейнстрим. Это слишком сложный язык. На его изучение нужно тратить слишком много времени. А тратить много времени сейчас не любят. Начинающему специалисту гораздо проще освоить Java, C#, VB, Python и найти оплачиваемую работу согласно своему уровню подготовки не тратя лишнее время на такую сложную штуку, как C++.
VD>И то что деньги он получит большие за работу на Яве тебя почему-то удивляет.
Я не говорил, что меня это удивляет. Я привел еще одну причину, почему человеку, не знающему C++, нет стимула изучать C++.
VD> И вообще — это сквозит во всех твоих, да и не только твоих, словах.
Я у себя такого не замечал. А если ты между моих строк видишь какие-то намеки на элитарность, то ничего поделать не могу. "У нас свобода сновидений".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
+1
Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Здравствуйте, eao197, Вы писали:
E>>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
ЮБ>+1
ЮБ>Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
А я еще помню, как ввели try/catch, и template.
Действительно повезло родится вовремя.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).
VD>В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.
Вы меня удивляете. Сильно. Не знаю даже, что сказать... Варианты на выбор:
1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
2. Т.е. тот же ООП как инструмент абстракции излишен?
3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
P>>Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...
VD>boost::spirit — это LL(1)-парсер.
Spirit is an object-oriented recursive-descent parser generator framework [ etc ]
Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
VD> Про то что в нем есть closures я никогда не слышал.
Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach.
VD>foreach — это синтаксический сахар позволяющий быть менее многословным для выражения паттерна перебора. Абстракцией он не является. Абстракцией является интерфейс IEnumerable и IEnumerable<T>. Они кстати, я взык не вмонтированы.
Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией, и как его реализовать на C#1.
ANS>>Или итераторы C#2 те же.
VD>Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
