Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не лечится такая неряшливость. Будут не эти проблемы, так другие.
А так будут и эти проблемы, и другие, и их пересечение. Это хорошо?
ЗЫ
Что касается "неряшливости"... Я, например, могу довольно часто ошибаться по мелочевке. При этом я без проблем пишу и ну С++, и на C#, так как их компиляторы, возможно, в купе с паттернами безопастного программирования позволяют ловить 99.999% всех ошибок еще на стадии компиляции. При этом я, обычно, сосредоточен на основной задаче и допускаю минимум логических ошибок. Таким образом, в каком-то смысле "неряшливость" очень даже лечится.
Теперь о С++ вс. Шарп. Когда я пишу на С++ мне приходится больше времени уделять паттенам безопасного программирования и поиску замены отсуствующих конструкций языка. Все это время вычитается из времени затрачиваемого на кодирование и местное проектирование. В итоге С++ становится значительно менее эффекивным средством разработки.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> ПК> Влад, извини, но сейчас ты сказал совершеннейшую глупость. Полиморфным класс может стать "вдруг" только при абсолютно неграмотном проектировании.
>> Извини и ты меня, но глупость говришь ты. Полиморфным класс будет и без виртуальной функции.
ПК>В терминах C++ полиморфным называется класс с виртуальными функциями.
Я не имел ввиду С++-ной терминалогии. Она довольно сильно расходится с реальным смыслом слова "полимрфизм". Перегрузка функций, к примеру, тоже полиморфизм.
ПК> Это я и имел в виду. Перефразируя: виртуальные функции "вдруг" появиться могут в классе, ранее их не имевшем, только при абсолютно неграмотном проектировании. Т.е., случай "никто не знает, когда появится виртуальная функция" в моем понимании — абсолютно неграмотное проектирование. Как ты уже ранее говорил: "бардак и отсутствие дизайна".
Тогда в следующий раз когда захочешь порассуждать о глупости не забудь уточнить как твои оппоненты понимают те или иные понятия.
ПК>Дело далеко не только и не столько в экономии. Далеко не всегда функции должны быть виртуальными по своей природе. Виртуальная функция — зависимость базового класса от наследника. В тех случаях, где это не нужно/не предусматривается, делать функции виртуальными "на всякий случай" — и есть безграмотный дизайн.
"На всякий случай" лучше вообще ничего не делать. Но я говорю не об этом. Я как раз говорю о случаях "экономии", т.е. когда по логике приложения нужно бы сделать функцию витуальной, но человек осноываясь на некоторых известных ему ограничениях обходится статическим полиморфизмом.
ПК>...в данном случае сделать act() виртуальной — грубая ошибка дизайна.
Я где-то призывал делать все публичные методы виртуальными? А вот делать виртуальными скрытые методы, как в твоем случае — это вообще экстровогантно. Шарпм такие экстравогантности отказывается компилировать.
>> К тому же, любой мало-мальски долго живующий проект постоянно изменяется. И внесение изменений в дизайн — это совершенно нармальный процесс (рефакториг). И если твой дизайн плохо поддается изменению, то плох такой дизайн.
ПК>Это никак не коррелирует с тем, что часть классов может не иметь виртуальных функций по проекту.
А я и не утрверждал подобного. Ты вообще с кем споришь то?
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>ХР в чистом виде мне не очень подходит.
Нам тоже. Вот например юнит-тестирование пытались прикрутить несколько раз. Последний раз я даже написал базовый набор тестов и сделал его отработку после ночного билда. Но, увы, не прижилось. Может потом, когда система в общем и целом устаканится.
VD> У них сдвиг по фазе на юнит-тестах,
У них много сдвигов. Вот только часть этих сдвигов почти универсальна, а часть уже на универсализм не тянет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Зачем ее тогда делать виртуальной? Для красоты?
В С++ можно переопределять скрытые функции. Это крайне не интуитивно, но в некоторых случаях позволяет повысить инкапсуляцию, как в прочем в некоторых других понизить.
ПК>> Впрочем, это здесь далеко не самое важное. Можешь ее сделать protected, если тебе так больше нравится (хотя вот это уже и будет ошибкой, т.к. тогда у наследников появится возможность ее вызывать, чего они делать не должны). Главное, что функция act() должна быть невиртуальной.
AVK>Слишком куцый пример. Я так и не смог понять мысль, которую ты хотел донести.
Товаришь борется с очередной ветренной мельницей. Он думает, что кто-то тут призывает делать все методы виртуальными, так сказать на всякий случай.
AVK>Тем не менее за год, что я писал на джаве, я сам ни разу с такими проблемами не сталкивался и не слышал чтобы кто то из-за этого поимел что то серьезное. Зато слышал кучу матюков за воткнутые не к месту final. У виртуальности есть две стороны медали — с одной стороны она действительно снижает защищенность, но с другой стороны увеличивает гибкость и позволяет расширять библиотеки не только теми способами о которых догадались подумать их создатели.
+1
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>С удовольствием бы согласился, если бы не периодичность падений
Это сказка. У меня Янус не падал с тех пор как пофиксили глюки в Сентиловском коде.
ГВ> и выстреливаний exceptions у того же Janus, к примеру.
Тебе уже 200 раз говорили, что анменеджед-приложение созданное в аналогичных условиях было бы вообще неработоспособным. И так же говорили, что очень многие серьезные проблемы Януса вызываны неподобающим поведением анменеджед-кода (ну, не можем мы переписать Jet и IE).
ГВ>Есть и другие доводы, которые в сумме не позволяют мне думать, что повсеместное внедрение .Net приведёт к появлению безглючных программ.
К безглючным не приведет. Токого никто и не утвреждал. Это очередное передергивание. Речь идет о существенном снижении количества ошибок, и повшении живучисти приложения в виду понижения степенит критичности ошибок.
ГВ>Меня, как пользователя, чрезвычайно мало интересует — на каком уровне возникает проблема. Либо разработчики её решают, либо — нет.
Ну, обратись к разработчикам Jet-а. Или заплати за портирование Януса на MSSQL.
VD>>Короче опять Джет. С mssql-ем такого небыло бы. ГВ>Неча на зеркало пенять...
Так не пеняй. Я проанализировал (года два назад) ситуацию и объем работы по обходу проблем и пришел к выводу, что проще портировать на mssql, но времени на это ни у кого не находится. Там нужно довтльно много переписать.
ГВ> Повторю: меня, как пользователя, совершенно не интересует, по причине какого из компонентов проявляются подобные вещи. Меня раздражает сам факт появления окошек stack trace. А ещё более раздражает то, что ты, например, считаешь возможным пытаться доказывать, что сие суть норма и есть хорошо.
Опять передергивание. Я не говрю, что стэк-трэйсы — это хорошо. Я говорю, что это значительно лучше чем GPF с закрытием приложения и потерей незаписанных данных (а то и порчей БД).
ГВ> Знаешь, это очень мило звучит, но я как-то успел привыкнуть к другому подходу к оценке некорректного поведения собственной программы.
Что я еще могу сказать? Ну, чето тебе в 201 раз повторить?
ГВ> И чужие программы я оцениваю по тем же критериям. ИМХО — не самым худшим. В частности, если программа выдаёт Assertion Violation Fault (по сути — то же самое, что и stack trace), то это ничем не лучше, чем выстреливание Continue/Quit. И в том и в том случае проявлется неработоспособность программы в определённых штатных, по видимому, ситуациях — иначе, они не были бы обработаны встроенными обработчиками.
Нет, уж. Случае координально разные. AV/GPF — это практически наверняка полный крах приложения, причем в большом количестве случаев это еще и порча памяти процесса с возможной порчей/потерей данных. Подобные ошибки зачастую бывают ошибками второго или третьего порядка (наложенными) и крайне трудно ловятся. Причем диагностическая информация выдаваемая при AV/GPF практически ничего не говорит разработчкику. А стэк-трэйс это мягкое сообщение о наличии проблемы с возможностью отладить код. При этом наложенности быть не может. По крайней мерее третьего порядка точно.
VD>>Просо проект не денежный и некому серьезно заняться даной проблемой, а так как не особо достает вот и живет очень давно. ГВ>Оправдываться я и сам умею.
Неспорю. Вот только я не оправдываюсь. Я обясняю. Если тебе оно нужно, то пара килобаксов решат проблему в лучшем виде. Меня эта проблема не достает (я ее словил 2 раза за все время). Так что...
ГВ> ИМХО, суть в том, что на мой взгляд, .Net просто позволил наплевать на некоторые вещи, или почему-то не позволил сконцентрироваться на них. Только-то и всего.
Дотнет позволяет пользоваться софтом в котором есть проблемы. Только и всего. А плевать или нет зависит от тех усилий которые нужно вложить в исправление ошибки. Если бы в Янусе постоянно вылетали бы AV, то ты просто бы бросил бы им пользоваться.
ГВ>>>К слову сказать, 1.1.4b3.185 гораздо лучше, чем 1.1.3. VD>>207 была самя качественная. ГВ>Попробую выкачать, спасибо.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>А потому, что GPF приведёт к более сильному недовольству пользователей и, следовательно — более острой реакции производителя софта. Ну а stack-dump window так сильно пользователей не раздражает. VD>>Конкретный пример. Ворд вылетает на ревиженах вот уже более 10 лет. Реакция производителя нулевая.
ГВ>Дык. MS и не на такие штуки никак не реагирует. И о чём это говорит? Да ни о чём.
Это говорит только об ошибочности твоих утверждений.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>А почему нет? Если ошмбка вызвана рассинхронизацией потоков, то это вполне себе временный выход. VD>Вот это и есть замазывание ошибки.
Тут какое дело. АВК говорит, что 99% ошибок известно, но нет времени. Если можно 1 раз написать обёртку для вызова Jet-функциональности благодаря которой для пользователя заметно повыситься устойчивость, то это ИМХо благо. А потом потихоньку исправлять ошибки. Вполне себе временное решение. К тому же достаточно общее.
VladD2,
> ПК> В терминах C++ полиморфным называется класс с виртуальными функциями.
> Я не имел ввиду С++-ной терминалогии. <...>
Я не видел никаких других значений термина "полиморфный класс". "Полиморфизм" вообще может означать много разных вещей, но это уже совсем другой разговор.
> Я как раз говорю о случаях "экономии", т.е. когда по логике приложения нужно бы сделать функцию витуальной, но человек осноываясь на некоторых известных ему ограничениях обходится статическим полиморфизмом.
Тогда это разговор о других use cases (читай, смена темы). В оригинальном примере ничего подобного я не обнаружил.
>>> К тому же, любой мало-мальски долго живующий проект постоянно изменяется. И внесение изменений в дизайн — это совершенно нармальный процесс (рефакториг). И если твой дизайн плохо поддается изменению, то плох такой дизайн.
> ПК>Это никак не коррелирует с тем, что часть классов может не иметь виртуальных функций по проекту.
> А я и не утрверждал подобного. Ты вообще с кем споришь то?
Твой аргумент о легкости внесения изменений относился к наличию в классе виртуальных функций. Этот аргумент в обсуждавшемся случае невалиден.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
ГВ>>С удовольствием бы согласился, если бы не периодичность падений VD>Это сказка. У меня Янус не падал с тех пор как пофиксили глюки в Сентиловском коде. Блин
. Хотя, справедливости ради, я не знаю — произошло сие падение в версии c пофиксеным сентинеловским кодом или без оного. Но факт остаётся фактом — Janus грохнулся.
ГВ>> и выстреливаний exceptions у того же Janus, к примеру. VD>Тебе уже 200 раз говорили, что анменеджед-приложение созданное в аналогичных условиях было бы вообще неработоспособным. И так же говорили, что очень многие серьезные проблемы Януса вызываны неподобающим поведением анменеджед-кода (ну, не можем мы переписать Jet и IE).
Тем не менее — факт остаётся фактом.
ГВ>>Есть и другие доводы, которые в сумме не позволяют мне думать, что повсеместное внедрение .Net приведёт к появлению безглючных программ. VD>К безглючным не приведет. Токого никто и не утвреждал. Это очередное передергивание. Речь идет о существенном снижении количества ошибок, и повшении живучисти приложения в виду понижения степенит критичности ошибок.
Хм... Я вот и думаю — о чём мы тогда спорим, вообще? ИМХО, с точки зрения пользователя нет разницы, свалилась ли программа с AV/GPF или снесла данные. Пример с Java NetBeans я уже приводил. Собственно, к тем же непредсказуемым последствиям приводит и нажатие на кнопку Continue в AVF-окне.
ГВ>>Меня, как пользователя, чрезвычайно мало интересует — на каком уровне возникает проблема. Либо разработчики её решают, либо — нет. VD>Ну, обратись к разработчикам Jet-а. Или заплати за портирование Януса на MSSQL.
Ни того, ни другого делать не буду. Пока что Janus "не тянет" на платный софт, а за модификацию Jet мне лично платить незачем. Я, собственно, относительно Janus уже высказался — в целом я отношусь к нему более чем положительно, а отрицательные оценки использую как иллюстрации к своим высказываниям.
VD>>>Короче опять Джет. С mssql-ем такого небыло бы. ГВ>>Неча на зеркало пенять... VD>Так не пеняй.
Супер! Но я же и не пеняю. На Джет, вроде бы, пеняешь ты.
VD>Я проанализировал (года два назад) ситуацию и объем работы по обходу проблем и пришел к выводу, что проще портировать на mssql, но времени на это ни у кого не находится. Там нужно довтльно много переписать.
Ну и что? Так может быть, здесь, в дизайне, как раз собака и порылась?
ГВ>> Повторю: меня, как пользователя, совершенно не интересует, по причине какого из компонентов проявляются подобные вещи. Меня раздражает сам факт появления окошек stack trace. А ещё более раздражает то, что ты, например, считаешь возможным пытаться доказывать, что сие суть норма и есть хорошо. VD>Опять передергивание. Я не говрю, что стэк-трэйсы — это хорошо. Я говорю, что это значительно лучше чем GPF с закрытием приложения и потерей незаписанных данных (а то и порчей БД).
Я отлично понимаю то, что ты говоришь. Но у меня всё время складывается впечателение, что ты (и не только ты) не хочешь понять одной простой вещи: что методы недопущения ошибок, приводящих к AV/GPF и ошибок, приводящих к stack dump — одни и те же. Научись бороться с первым — и научишься избавляться от второго. Только вот C++ в данном случае "проповедует" куда как более эффективную парадигму, чем try...catch...finally + GC.
ГВ>> Знаешь, это очень мило звучит, но я как-то успел привыкнуть к другому подходу к оценке некорректного поведения собственной программы. VD>Что я еще могу сказать? Ну, чето тебе в 201 раз повторить?
От количества повторений истинность тезиса... как известно... кхм...
ГВ>> И чужие программы я оцениваю по тем же критериям. ИМХО — не самым худшим. В частности, если программа выдаёт Assertion Violation Fault (по сути — то же самое, что и stack trace), то это ничем не лучше, чем выстреливание Continue/Quit. И в том и в том случае проявлется неработоспособность программы в определённых штатных, по видимому, ситуациях — иначе, они не были бы обработаны встроенными обработчиками. VD>Нет, уж. Случае координально разные. AV/GPF — это практически наверняка полный крах приложения, причем в большом количестве случаев это еще и порча памяти процесса с возможной порчей/потерей данных.
AV — почти то же самое, что и stack trace — суть нарушение критически важных ограничений на данные. GPF может свидетельствовать и о более сложных ошибках.
VD>Подобные ошибки зачастую бывают ошибками второго или третьего порядка (наложенными) и крайне трудно ловятся. Причем диагностическая информация выдаваемая при AV/GPF практически ничего не говорит разработчкику. А стэк-трэйс это мягкое сообщение о наличии проблемы с возможностью отладить код. При этом наложенности быть не может. По крайней мерее третьего порядка точно.
Хммм... А не мог бы ты уточнить критерии упорядочивания ошибок? Я не совсем тебя понимаю, когда ты говоришь о первом .. n-ом порядке ошибок. ИМХО, stack trace это суть то же самое, что и AV-окно, только с добавленным дампом стека. И то и то появляется вследствие критической неисправиой ошибки. Например вследствие некорректности данных: NULL-pointer, или NULL-reference, или ещё что-то в таком же роде. Значит, если мы хотим продолжить работу программы, то нужно либо повторить действие, либо его прекратить, поскольку всё, что мы смогли предпринять на данный момент — это сообщить о фатальной ошибке.
VD>>>Просо проект не денежный и некому серьезно заняться даной проблемой, а так как не особо достает вот и живет очень давно. ГВ>>Оправдываться я и сам умею. VD>Неспорю. Вот только я не оправдываюсь. Я обясняю. Если тебе оно нужно, то пара килобаксов решат проблему в лучшем виде. Меня эта проблема не достает (я ее словил 2 раза за все время). Так что...
...так что, добавим ещё одну иллюстрацию к тезису о том, что некоторые программы безглючно работают только на компьютерах своих разработчиков.
ГВ>> ИМХО, суть в том, что на мой взгляд, .Net просто позволил наплевать на некоторые вещи, или почему-то не позволил сконцентрироваться на них. Только-то и всего. VD>Дотнет позволяет пользоваться софтом в котором есть проблемы. Только и всего. А плевать или нет зависит от тех усилий которые нужно вложить в исправление ошибки. Если бы в Янусе постоянно вылетали бы AV, то ты просто бы бросил бы им пользоваться.
Так они и так вылетают. Или причины появления stack trace сильно отличаются от причин Assert Violation Fault?
Кроме того, я когда-то вполне себе даже пользовался Embarcadero Tools несмотря на их потрясающую глючность.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>>>А потому, что GPF приведёт к более сильному недовольству пользователей и, следовательно — более острой реакции производителя софта. Ну а stack-dump window так сильно пользователей не раздражает. VD>>>Конкретный пример. Ворд вылетает на ревиженах вот уже более 10 лет. Реакция производителя нулевая. ГВ>>Дык. MS и не на такие штуки никак не реагирует. И о чём это говорит? Да ни о чём. VD>Это говорит только об ошибочности твоих утверждений.
"Более острая реакция" вовсе не означает (увы), что она влечёт за собой исправление ошибок.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>А чего это они "пролетают" наверх и всё, что я вижу — это stack trace? AVK>А как должно быть? Красивое окошко с тем же самым сообщением? Или молчаливое проглатывание?
Ну, я бы ожидал, как минимум, что некое действие будет возобновлено.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>И получать такой же бред? VD>Открытые оскорбления являются хорошим доказательством отсуствия аргументов.
ГВ>>Влад, не путай законченную мысль, выражаемую статьёй, и удовлетворительно работающую программу, выражаемую кодом. VD>Извини, но я кое-что понимаю в обоих областях.
Это тема отдельного, о-о-очень большого спора, и давай пока не будем в него ввязываться. Хотя мне странно видеть, что ты не можешь отличить аллегоричного выражения мысли от оскорбления.
VD>ЗЫ
VD>В общем, можете оставаться виртуально в кменном веке и не верить, что можно жить по другому. Реальность от этого не изменится. Сейчас можно и нужно проектировать и кодировать по другому. Более эффективно, просто и надежно.
Ну что же... в ответ могу пожелать оставаться в вечно меняющемся мире менеджерской демагогии.
Ты уж извини, но мне, как-то, мир живых людей и исполнительных компьютеров куда интереснее мира исполнительных людей и живых компьютеров. Так-то вот уж...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Волк-Призрак, Вы писали:
ГВ>>Хрена себе баги кодеров! Кодерские-то баги обычно очень быстро вылазят. ВП>Не знаю.... Представьте кодерский баг copypaste, где в функции, в которой д. б. происходить вызов чегото вроде: ВП>
ВП>Это вроде как ошибка кодинга, но этот лик может всплыть после Страшного Суда
У такого бага может быть куча последствий, так что гадать когда он всплывёт — неблагодарное занятие.
ГВ>>Ты правда, считаешь, что лучшая защита от ошибок, это конструкция вроде такой: ГВ>>
ГВ>>? ВП>Я подозреваю что речь идёт об ошибках компияции вроде "$variable is null pointer" и "$variable is unassigned pointer" или "error — returning null pointer", а не проверок на уровне синтаксических конструкций.
Дык, вроде как речь идёт о выкусывании ошибок, возникающих в runtime. А их можно выловить только явно или неявно внедрив проверки вроде показанной.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу, и потому вылавливаются влёт. ГВ>Если ситуация доведена до такой — то это есть беда проектирования. Как минимум — следствие нарушения контроля типов. Извини, но это — медицинский факт. Во всяком случае — по моей практике.
У меня есть смутное подозрение, что в состав твоей практики никогда не входило производство сложного тиражного софта. Если бы ты этим занимался — никогда бы такого не сказал.
ГВ>Кто же дураку запретит? Кстати, как ты думаешь, кого именно пытаются культивировать "современные направления IT-индустрии"? Я имею ввиду — в интеллектуальном смысле?
Культивация — дело хорошее, но компетентного специалиста из дурака ты все равно никогда не сделаешь. А толковых программистов — мало, очень мало. Поэтому работать приходится с тем, что есть.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну что же... в ответ могу пожелать оставаться в вечно меняющемся мире менеджерской демагогии.
Как там говорят... кто громче всех кричит "вор"?
Если ты просто не понимаешь какие-то мысли — это не причина называть их "демагогией".
Если ты их понимаешь и понимаешь их ошибочность — расскажи своему начальству, как надо делать лучше. Тебя просто с рапростертыми объятиями примут. Если, конечно, ты действительно это знаешь. И тогда ты, со своими прозрениями в этой области, оставишь всех своих конкурентов без штанов. Есть какие-то возражения против этого плана?
Боюсь, что спор опять зашел в тупик. Но это и неважно, по большому счету.
Пока одни будут упорно писать все на С++ и упиваться сознанием свой крутизны, другие будут использовать .NET и выпускать более функциональные и качественные программы. А рынок всех расставит по своим местам
Здравствуйте, Дарней, Вы писали:
Д>Пока одни будут упорно писать все на С++ и упиваться сознанием свой крутизны, другие будут использовать .NET и выпускать более функциональные и качественные программы. А рынок всех расставит по своим местам
Повторять как мантру... с утра и в полдень... и на ритуале подъёма флага компании.
Только что, во время очередной синхронизации, Janus вывалил очередной Exception... Впрочем, нет — так ведь не бывает, верно?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Повторять как мантру... с утра и в полдень... и на ритуале подъёма флага компании.
Не надо грязи. Я просто делаю свою работу, и делаю ее настолько качественно, насколько это возможно в существующих обстоятельствах. Теми инструментами, которые упрощают мою задачу. Только и всего.
ГВ>Только что, во время очередной синхронизации, Janus вывалил очередной Exception... Впрочем, нет — так ведь не бывает, верно?
На фоне отсутствующих как класс С++ аналогов — это аргумент в пользу сам понимаешь чего
VladD2,
> Что касается "неряшливости"... Я, например, могу довольно часто ошибаться по мелочевке. При этом я без проблем пишу и ну С++, и на C#, так как их компиляторы, возможно, в купе с паттернами безопастного программирования позволяют ловить 99.999% всех ошибок еще на стадии компиляции.
> Когда я пишу на С++ мне приходится больше времени уделять паттенам безопасного программирования и поиску замены отсуствующих конструкций языка.
Это не означает, что у всех так. Другим приходится больше времени уделять тому же при использовании C# и библиотеки .Net. Особенно при переходе с JavaScript и Python: вопреки твоим заявлениям, в функциональном стиле на C# получается не очень. И что?
Все это только говорит о том, что разным людям лучше подходят разные языки. Однако некоторые почему-то продолжают настаивать на безусловных преимуществах одного языка. Ну-ну...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
>>> В общем, не нужно выдавать свои желания за действительность. С++ пытается позволять писать в разных стилях, но рассчитан он в основном на два: структурный и ОО. И в этом свете ОО-дизайн является (должен являться) главной стратегией проектирования ПО. GOF, насколько я помню, использовал С++ в качестве одного из основных языков примеров.
>> ПК>Ну и что?
>> Вот и странно, почему 90% С++-программистов эти принципы или игнорируют, или вообще о них не слышало.
> Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
> Естествнно речь шла о принципах ОО-дизайна.
Я в своем ответе их не разделял. Пожалуйста, могу перефразировать. Паттерны не относятся к принципам ОО-дизайна. Принципы ОО-дизайна — open-closed, dependency inversion, Liskov substitution и т.п.
> Принципами ООП их подменил уже ты. Я же просто не согласен с тем, что перечисленный тобой список является принципами ООП. Принципы ООП — это наследование, инкапсуляция, полиморфизм. Куда засунуть приведенные тобой принципы я даже и не знаю.
Если не относить к принципам перечисленное мною, то паттернам там вообще ловить нечего. Паттерны по отношению к перечисленным мной принципам (критериям качества ОО-дизайна) — средства их достижения.
> Не буду повторяться. АВК вот тут
очень хорошо описал данный подход. То что ты с ним не согласен еще не значит, что он не верен. Еще раз повторю только то, что ты умудрился будучи моложе меня очень сильно увязнуть в доисторических догмах. Технологии меняются. С ними меняются и подходы.
От всей этой риторики суть никуда не девается. Проблемы такого подхода видны невооруженным глазом, тот же Янус уже давно в них уперся. Проблемы заключаются в том, что без должного проектирования на ранних стадиях, внесение изменений в программу в дальнейшем очень сильно осложняется.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Шарпм такие экстравогантности отказывается компилировать. 
Но я же и не пеняю. На Джет, вроде бы, пеняешь ты. 
