Здравствуйте, Sergey, Вы писали:
S>В компьютер сайнсе — может быть. А в жизни это именно полное переписывание, S>причем не только показывалки (которая всем устраивает), а половины всей S>системы. Замечательное решение несуществующей проблемы
Значит — хреновый дизайн как у показывалки, так и у всей системы.
Здравствуйте, alexeiz, Вы писали:
A>А что нужно сделать, чтобы свою кодировку реализовать? В том смысле, что std::codecvt имеет 7 защищенных виртуальных do_xxx методов, которые нужно определить. А в .NET как я вижу как минимум три класса нужно реализовать Encoding, Encoder & Decoder.
Неправильно видишь. Минимально достаточно 1 класс и реализовать в нем 6 методов, по 3 на каждое направление преобразования:
Но. повторяю, все это имеет небольшое практическое значение — все часто используемые кодировки в дотнете есть.
A> У них в сумме куча виртуальных методов (так как все эти классы abstract).
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> давай на примерах более приближенных к жизни: >> >>
>> CWindow * window = new CButton();
>> ...
>> // используем некоторый код наботающий с window (полиморфно)
>>
>> delete window;
>>
ПК>Данный код будет иметь смысл, например, если у CWindow есть хоть одна виртуальная функция. Это совсем не тот случай, что рассматривался ранее.
Имхо, данный код как не имел смысла, так и после реплики Влада не имеет.
Поскольку у нас есть принцип подстановки Лисков, нет абсолютно никакого смысла писать
CWindow * window = new CButton();
вместо
CButton * button = new CButton();
потому что коду, который "работает с window полиморфно", в соответствии с этим принципом совершенно пофиг, что в него попадает — указатель на CWindow или на его потомка.
Так что я не вижу ни одной причины писать такой код, и дал бы по рукам программисту, его написавшему.
Единственная возможная причина — ограничить использование объекта только методами CWindow, но я для таких случаев просто объявляю рядом ссылку нужного типа, благо она ничего не стоит — заодно можно навесить константность и все такое прочее.
Ну уж я и не говорю, что нет никакой необходимости писать явный delete при наличии армиии оберток указателей (для данного случая — std::auto_ptr и boost::scoped_ptr).
Совсем другое дело, если new происходит не в этой функции, а в какой-то внешней (т.е. фабрике), которая генерит разнообразных потомков CWindow и возвращает указатели CWindow — но это автоматически означает, что иерархия классов CWindow изначально разрабатывалась для такого использования и если дизайнер при проектировании такой иерархии не объявил деструктор CWindow виртуальным, с ним надо сразу же сделать что-нибудь нехорошее.
Здравствуйте, VladD2, Вы писали:
VD>Все это помому, что они думают на С++ и измеряют все его метриками.
Ну, если мерой LISP .Net померять, так .Net вообще отдыхает и нервно курит в сторонке (по крайней мере — с точки зрения комбинаторных возможностей, часто называемых "метапрограммированием"). Уж извиняйте. Это к вопросу о "высокоуровневости". Так что, приходится сравнивать с тем, что попроще — с C++.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>А перепроектировать продукт... Ну ты что! Это же, млин, честь великая, достойная Наполеона местного масштаба. Это же сразу десяток менеджеров закладывать в бюджет нужно! Так что, те самые представители "маленьких компаний" как тот кот из анекдота: "зъисть-то он зъист, да хто ж ему дасть!" на то есть проверенные коты, которые жрут умеренно и время от времени успокаивающе мурчат за печкой (на собраниях). Дальше о глюке феномена "доверия к проверенным кадрам" рассказывать или сам догадаешься? VD>Ну, прямо крик души притесненного и обделенного таланта.
Ладно, ладно. Я понимаю: в ответ не наедешь — весь день, как оплёванный. Ладно, прощаю тебе переход на личности.
VD>А я вот не считаю, что все места занимаются разными долболомами, а умным и правильным места не дают. И боюсь, что если этим самым умным и правильным (по их самомнению) доврить работу тех самых "котов", то вместо продукта будет полный абзац,
VD>а юзеры будут выслушивать объяснения почему, видите ли, GPF лучше сообщения об ошибки с возможностью продолжения.
... и не слишком внимательное чтение постингов...
ГВ>>А я вот, уже давно ни отчего не фигею. Привык, что несмотря на рассуждения о необходимости "правильно" проектировать, программы как писали через ж... так и будут писать. VD>Извини, но программы валятся и глючат не от недостатков проектирования. Это в оснвовном ошибки кодеров. Вот таких уверенных как ты. Для которых язык ничего не значит, а все ошибки от кривых рук.
... и излишние упрощения тоже.
ГВ>> И виноватых не сыщешь, потому что у всех есть разумные и логичные оправдания. VD>Ага. Как у тебя, например.
... и... об этом уже было.
ГВ>>И распространение управлямых сред типа Java/.Net ситуацию не улучшит, а только ухудшит. Одно хорошо — stack trace станет просто ординарным явлением, а не предсмертным криком программы. VD>Уже улучают. Янус по крайней мере работает. А хваленые версии которые должны были летать, так и не появились на свет.
... и стандартную манагёрскую демагогию — тоже. В рамках той же демагогии управленцев можно сказать, что раз Janus вываливает сообщения об ошибках, то он не работает.
ГВ>>Влад, вот давай, не будем путать "как надо" и "как делают"? Потому что надо: ГВ>>- строить цельные модели (за очень небольшие деньги могу тебе немного рассказать на эту тему ); VD>Ага. У МС 20 лет и их состояния не хватило построить цельную модель. Или ума. Жаль тебя не встретили. Сейчас бы глядишь работали на супер стабильном Ворде.
... безаргументный этот, как его.
ГВ>>- продумывать их до реализации; ГВ>>- поменьше суетиться и лизать одно место начальству.
VD>Да задолбал ты уже со своим продумыванием.
Эк, однако!
VD>Там баги.
Правильно. Думать нам некогда — мы работаем.
VD>Баги кодеров, а не дизайнеров. А выловить их не могут, так как это ошибки третьего-четвертого порядка, и потому что вылезают они только при стечении некоторых абстаятельств.
Хрена себе баги кодеров! Кодерские-то баги обычно очень быстро вылазят.
VD>Ну, еще, возможно, из-за того, что разные средства проверки орфографии поставляются криворукими уродами на которых в МС сильно повлиять не могут.
О редакторе Word я не говорил, ну уж коль скоро...
VD>И тут бы очень помог бы вариант когда вместо GPF мне бы вылетело окно с кнопочкой Континьё.
Давай попробуем предугадать последствия нажатия на Continue? Я не случайно приводил пример с NetBeans, которая теряет при этом настройки проекта. Как ты думаешь, что произойдёт в Word-е, если пользователь нажмёт Continue? Например, ты сможешь поручиться за то, что после нажатия на Continue и Save вместо текста в файле не окажется дамп стека? А это, в принципе, не сложно сделать — прокастили результат функции к типу TextData — и понеслаь!
ГВ>>А происходит "как всегда": менеджер принял техническое решение; VD>Ясно. Менеджер, значич дурак...
Угу, учту на будущее — какой именно смысл ты вкладываешь в это слово.
ГВ>>потому что "требования бизнеса" VD>Ну, да... теперь уже бизнес мешает.
Мешает не бизнес, а фетиш "требований бизнеса". Понимаешь, в чём разница понятий "бизнес" и "фетиш"?
ГВ>>(фетиш наш драгоценный, мать его трижды за ногу); взяли насквозь сертифицированного программиста, которому похрену, что будет на выходе — лишь бы начальство удовлетворить; VD>Мля, задолбали! Это ваши же, верне наши же, баги.
Какие такие "наши же"? Так ваши или наши?
VD>Уверен, что тот орел что насажал багов в Ворде сейчас вот так же втирает подобную чущь кому-нибудь на другом форуме по продуктам фирмы ххх. И он-то точно в багах не виноват, так как еще не нашел их. А те что нашело уже не баги.
Ну, орлов много. Одни втирают, что ошибки — это не ошибки, другие, что ошибки — это только глобальный бу-бух, третьи, что... Что из этого следует?
VD>Нефига сваливать проблемы на других. Ошибаются все! Это как закон всемирного тяготения, он неотвратим. Натура у человека такая. Он всегода ошибается. Именно ошибки и способность их анализировать сделали человека человеком. И слушать пургу про "других виновных" и "проблемы рынка" просто противно. Нужно думать о том, как повысить уровень программирования и создать гарантированных барьер хотя бы против самых болезненных ошибок. А не перекладывать отвественность на четри знает кого.
Ты правда, считаешь, что лучшая защита от ошибок, это конструкция вроде такой:
if (!validpointer(p)) { throw InvalidPointer; }
?
Если да, то нам с тобой на самом деле не о чем спорить, если нет — то перестань нести чепуху относительно "гарантированного барьера". Потому что даже "прокатку" по памяти обычно можно вычислить быстро. Главное — засечь её существование.
ГВ>>Только при чём здесь C++? А вот VD>Притом что это багодром. Это средсво не только не защищающее от ошибок, но и порой подталкивающее к их совершению.
Блин, ну сколько можно повторять. Никто не защитит программиста (и программу) от ошибок лучше, чем он сам. Потому что трижды навороченное средство знать не знает ничего о том, как его собираются применять. То есть — вообще. Потому что оно — средство. Можно запросто поломать молоток, если вколачивать им тупой короткий гвоздь в железную стену. А виртуальный барьер против ошибок Null Reference (даже не самих ошибок, а последствий в виде краха программы) как раз и подталкивает к их совершениею куда как больше, чем "вседозволенность" C++. Потому что ничто так не подталкивает к ошибкам, как иллюзия защиты от них. Забегая вперёд, скажу, что это же справедливо и для C++.
VD>Конечно дотнет или Ява не панацея. Конечно они не решат всех проблем, покрайней мере, в одночасье. Но это рельный и ощутимый шаг в правильном направлении.
Мне бы твою уверенность, Влад. К сожалению, мне пока что за словом ".Net" ничего кроме очень толкового маркетинга, очень бестолковой технологической эклектики, рассчитанной на... (не будем о грустном) — не видно. Ну, было уже нечто похожее в IT-индустрии, PL/xxxx называлось. Так что, я очень-очень сомневаюсь, что это шаг в "правильном направлении". Да и в самом по себе существовании такого "направления" в техническом виде — тоже очень сомневаюсь. Впрочем, поживём — увидим.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Нет. Не все, что с классами — ООП. Читать определение ООП.
Вики тебе в руки.
ПК>См., например, James O. Coplien. Multi-Paradigm Design for C++
Зачем? Я достаточно знаю С++ чтобы иметь о нем собственное мнение.
ПК>Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
Это только по-твоему.
ПК>Довольно глупо замыкаться на одном стиле, когда доступны другие.
Довольно глупо поощрять бардак и отсуствие дизайна как такового прикрываясь разговорами о стилях.
ПК>У "моих сторонников" идут слова о предпочтительности вынесения вспомогательных функций за пределы класса, изоляции данных от алгоритмов, уменьшении зависимостей, статическом контроле инвариантов и т.п.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Данный код будет иметь смысл, например, если у CWindow есть хоть одна виртуальная функция. Это совсем не тот случай, что рассматривался ранее.
Странно слышать подобню кромолу от человека со столь большим рейтингом в С++.
Это дизайн. Никто не знает когда появится виртуальная функция. Да и довольно странно выглядят иерархии биз виртуальных методов.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
VD>>Все это помому, что они думают на С++ и измеряют все его метриками. ГВ>Ну, если мерой LISP .Net померять, так .Net вообще отдыхает и нервно курит в сторонке (по крайней мере — с точки зрения комбинаторных возможностей, часто называемых "метапрограммированием"). Уж извиняйте. Это к вопросу о "высокоуровневости". Так что, приходится сравнивать с тем, что попроще — с C++.
Вообще-то функциональные языки под дотнетом во всю работают. Так что не надо ля-ля. Да и во многом курит скорее Лисп.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Руки прочь от Perl'а! А кстати, такого флейма еще не было: Perl vs PHP.
VD>Боюсь, что при этом С++-ники и C#-ники объеденятся и...
ПК>>Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
VD>Это только по-твоему.
ПК>>Довольно глупо замыкаться на одном стиле, когда доступны другие.
VD>Довольно глупо поощрять бардак и отсуствие дизайна как такового прикрываясь разговорами о стилях.
ПК>>У "моих сторонников" идут слова о предпочтительности вынесения вспомогательных функций за пределы класса, изоляции данных от алгоритмов, уменьшении зависимостей, статическом контроле инвариантов и т.п.
jazzer,
>>> давай на примерах более приближенных к жизни:
>>>
>>> CWindow * window = new CButton();
>>> ...
>>> // используем некоторый код наботающий с window (полиморфно)
>>>
>>> delete window;
>>>
> ПК>Данный код будет иметь смысл, например, если у CWindow есть хоть одна виртуальная функция. Это совсем не тот случай, что рассматривался ранее.
> Имхо, данный код как не имел смысла, так и после реплики Влада не имеет. > Поскольку у нас есть принцип подстановки Лисков, нет абсолютно никакого смысла писать >
> CWindow * window = new CButton();
>
вместо >
> CButton * button = new CButton();
>
Я все-таки не думаю, что Влад имел в виду буквально этот код В таком виде это вообще не имеет смысла (ой, прямо твоими словами заговорил). В общем, полагаю, к данному коду нужно относиться как к метафоре.
> <...> Так что я не вижу ни одной причины писать такой код, и дал бы по рукам программисту, его написавшему.
Ну, если пойти так далеко, и говорить именно об этом коде, то я бы дал по рукам программистам, написавшим оба варианта Без дополнительного кода не вижу ни одной причины писать это вместо:
CButton button;
> Ну уж я и не говорю, что нет никакой необходимости писать явный delete при наличии армиии оберток указателей (для данного случая — std::auto_ptr и boost::scoped_ptr).
+1
> Совсем другое дело, если new происходит не в этой функции, а в какой-то внешней (т.е. фабрике), которая генерит разнообразных потомков CWindow и возвращает указатели CWindow — но это автоматически означает, что иерархия классов CWindow изначально разрабатывалась для такого использования и если дизайнер при проектировании такой иерархии не объявил деструктор CWindow виртуальным, с ним надо сразу же сделать что-нибудь нехорошее.
Да, я полагаю, Влад именно что-то такое имел в виду. И да, снова с тобой согласен, нужно уж очень неряшливо писать, чтобы пропустить такое. По-моему, языком это уже не лечится...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Данный код будет иметь смысл, например, если у CWindow есть хоть одна виртуальная функция. Это совсем не тот случай, что рассматривался ранее.
> < ... ad hominem arguments skipped ... >
> Это дизайн. Никто не знает когда появится виртуальная функция.
Влад, извини, но сейчас ты сказал совершеннейшую глупость. Полиморфным класс может стать "вдруг" только при абсолютно неграмотном проектировании.
> Да и довольно странно выглядят иерархии биз виртуальных методов.
Зависит от контекста. Пример iterator traits уже приводили.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
> Это только по-твоему.
Я так понимаю, ссылок на авторитетные источники, где бы design patterns причислялись бы к принципам ООП, ты привести не сможешь.
> ПК> Довольно глупо замыкаться на одном стиле, когда доступны другие.
> Довольно глупо поощрять бардак и отсуствие дизайна как такового прикрываясь разговорами о стилях.
Безусловно. Однако в данном случае речь шла о сознательно принимаемых проектных решениях. Странно, что ты этого не заметил.
Здравствуйте, Волк-Призрак, Вы писали:
VD>>Ну, прямо крик души притесненного и обделенного таланта. А я вот не считаю, что все места занимаются разными долболомами, а умным и правильным места не дают. И боюсь, что если этим самым умным и правильным (по их самомнению) доврить работу тех самых "котов", то вместо продукта будет полный абзац, а юзеры будут выслушивать объяснения почему, видите ли, GPF лучше сообщения об ошибки с возможностью продолжения. ВП>интересно... А в самом деле, почему? Пусть объяснит!
А потому, что GPF приведёт к более сильному недовольству пользователей и, следовательно — более острой реакции производителя софта. Ну а stack-dump window так сильно пользователей не раздражает.
ВП>Правда последний шаг в этом направлении будет ИИ-низированый генератор кода по постановке задачи, и тогда роль системных архитекторов будут играть аналитики, а роль кодеров — системные архитекторы.... Не знаю, является ли это архи, хорошо, если программирование вообще и кодинг как класс вымрут за ненадобностью....
Ещё один мечтатель.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>>>Все это помому, что они думают на С++ и измеряют все его метриками. ГВ>>Ну, если мерой LISP .Net померять, так .Net вообще отдыхает и нервно курит в сторонке (по крайней мере — с точки зрения комбинаторных возможностей, часто называемых "метапрограммированием"). Уж извиняйте. Это к вопросу о "высокоуровневости". Так что, приходится сравнивать с тем, что попроще — с C++. VD>Вообще-то функциональные языки под дотнетом во всю работают. Так что не надо ля-ля. Да и во многом курит скорее Лисп.
Кхм. Вообще-то, они не только под дотнетом работают. Это как раз и говорит о мощности и высокоуровневости этих языков.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
VD>>Баги кодеров, а не дизайнеров. А выловить их не могут, так как это ошибки третьего-четвертого порядка, и потому что вылезают они только при стечении некоторых абстаятельств. ГВ>Хрена себе баги кодеров! Кодерские-то баги обычно очень быстро вылазят.
Не знаю.... Представьте кодерский баг copypaste, где в функции, в которой д. б. происходить вызов чегото вроде:
log.writestste(this)
threadsset.remove.this();
изза очепятки происходит
log.writestste(this)
threadsset.add.this();
Это вроде как ошибка кодинга, но этот лик может всплыть после Страшного Суда
ГВ>Давай попробуем предугадать последствия нажатия на Continue? Я не случайно приводил пример с NetBeans, которая теряет при этом настройки проекта. Как ты думаешь, что произойдёт в Word-е, если пользователь нажмёт Continue? Например, ты сможешь поручиться за то, что после нажатия на Continue и Save вместо текста в файле не окажется дамп стека? А это, в принципе, не сложно сделать — прокастили результат функции к типу TextData — и понеслаь! ))))
ГВ>Ты правда, считаешь, что лучшая защита от ошибок, это конструкция вроде такой:
ГВ>
Я подозреваю что речь идёт об ошибках компияции вроде "$variable is null pointer" и "$variable is unassigned pointer" или "error — returning null pointer", а не проверок на уровне синтаксических конструкций.
Это же сразу десяток менеджеров закладывать в бюджет нужно! Так что, те самые представители "маленьких компаний" как тот кот из анекдота: "зъисть-то он зъист, да хто ж ему дасть!" на то есть проверенные коты, которые жрут умеренно и время от времени успокаивающе мурчат за печкой (на собраниях). 
