Здравствуйте, VladD2, Вы писали:
ГВ>>А потому, что GPF приведёт к более сильному недовольству пользователей и, следовательно — более острой реакции производителя софта. Ну а stack-dump window так сильно пользователей не раздражает. VD>Конкретный пример. Ворд вылетает на ревиженах вот уже более 10 лет. Реакция производителя нулевая.
Дык. MS и не на такие штуки никак не реагирует. И о чём это говорит? Да ни о чём.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Просто ты настолько привык, что процесс программирования это сложный, отвественнй и кропотливый процесс, что просто не можешь себе представить, что код можно писать со скоростью выражения своих мыслей на естественном языке.
И получать такой же бред?
VD>Я точно так же пишу и стати. Сначало пишу общий план. Потом начинаю писать отдельные фрагменты. Потом читаю что получилось... переписываю... так сказать, кристализую мысль. В итоге через несколько итераций получается статья. Потом, как ты знашь, выношу ее на суд других и устраняю проблемы которые я не заметил. По-моему, очень продутивный подход. И при программировании он тоже прекрасно применим.
Влад, не путай законченную мысль, выражаемую статьёй, и удовлетворительно работающую программу, выражаемую кодом.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Кхм. Вообще-то, они не только под дотнетом работают. Это как раз и говорит о мощности и высокоуровневости этих языков.
VD>Ты на два сообщения вверх голову подними. Это был ответ на бессмысленное заявление: VD>
если мерой LISP .Net померять, так .Net вообще отдыхает и нервно курит
VD>Я как бы просто намекнул, что сравнение языка с платформой — это логическая ошибка. Только и всего.
Правильно, а потому нечего пенять на "C++ — мышление" окружающим. Поскольку ты же сам таким образом и противопоставляешь язык библиотеке.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Волк-Призрак, Вы писали:
ПК>>Например, как без свободных функций вызвать в шаблоне/generic функции скалярное умножение двух векторов, если вектор может быть как встроенным массивом, так и структурой, определенной пользователем? Со свободными функиями легко: ПК>>
ПК>>Задача пользователя данной функции — определить scalar_multiplication для типов, которые передаются в данную функцию. Это можно сделать для любых типов, даже если тип определен в какой-то библиотеке, модифицировать которую мы не можем.
ВП>Всё это проблематично только потому, что в шаблоны некоторых языков нельзя примитивные типы вставлять. А вы не обратили внимание, что происходит в данном примере?? Оборачивание свободной функции объектом! Так что проблема свободных функций не становится мене надуманной имхо после данного примера.
Где здесь упомянутое оборачивание? Кроме того, scalar_multiplication в приведёном примере предполагается настолько же глобальным, насколько глобален и сам оператор "*".
ПК>>Еще один, классический пример — функция swap(). Та же история: ее можно использовать из любых шаблонов для любых типов именно потому, что она является свободной функцией: пользователь может использовать готовую, либо, при желании, определить свою, более оптимальную, для своих или библиотечных типов. ВП>Не думаю, что т. н. несвободные функции являются ущербными по своей функциональности только потому что они не свободны. Либо язык позволяет использовать примитивные типы в шаблонах, либо нет. Это более серьёзная проблема оо-языков чем "свобода" или "рабство" функций.
Прежде всего, это проблема C# и Java, не стоит здесь обобшать. Для C++ такой проблемы нет в принципе.
ВП>Именно отсутствие возможности создать что либо в стиле
[пример поскипан]
ВП>более сильно ограничивает меня чем отсутсвие свободных фунций. Необъходимо также заметить, что подобный манёвр требует спецмализации шаблона по всем примитивнымтипам и по классу Number (или его логическим аналогам). О Number-классах хочу сказать особо то, что я не понимаю, почему (хотя бы) для них не сделали перегрузку операторов "по мнемоническим именам". Чтонибудь вроде строгого соответствия THISCLASS OPERATOR_MULTIPLY(THISCLASS arg); оператору *
Здесь непонятно, где именно нужно копать. ИМХО, предпринята не слишком остроумная попытка "абстрагироваться от железа", вот и приколы...
ПК>>В результате, без нормальной поддержки свободных функций, многие возможности языка недоступны пользователю, не желающему писать в ОО-стиле. ВП>Язык стал бы слишком сложен с точки зрения написания рантайма. Но за простоту относительную реализации пришлось заплатить слишком дорого.
Об том и речь, что чудес не бывает.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Не скажу насчёт формального багрепорта, но в Янусе нередко возникает ошибка transaction deadlock. VD>Ошибки бывают всегда и везде. Вопрос в критичности и массовости ошибок. Согласись, что для менеджед-кода эти показатели значительно ниже.
С удовольствием бы согласился, если бы не периодичность падений и выстреливаний exceptions у того же Janus, к примеру. Есть и другие доводы, которые в сумме не позволяют мне думать, что повсеместное внедрение .Net приведёт к появлению безглючных программ.
VD>А делдлоки... это не дедлоги, а скорее проблемы с параллельным обновлением БД из разных потоков.
Меня, как пользователя, чрезвычайно мало интересует — на каком уровне возникает проблема. Либо разработчики её решают, либо — нет.
VD>Короче опять Джет. С mssql-ем такого небыло бы.
Неча на зеркало пенять... Повторю: меня, как пользователя, совершенно не интересует, по причине какого из компонентов проявляются подобные вещи. Меня раздражает сам факт появления окошек stack trace. А ещё более раздражает то, что ты, например, считаешь возможным пытаться доказывать, что сие суть норма и есть хорошо. Знаешь, это очень мило звучит, но я как-то успел привыкнуть к другому подходу к оценке некорректного поведения собственной программы. И чужие программы я оцениваю по тем же критериям. ИМХО — не самым худшим. В частности, если программа выдаёт Assertion Violation Fault (по сути — то же самое, что и stack trace), то это ничем не лучше, чем выстреливание Continue/Quit. И в том и в том случае проявлется неработоспособность программы в определённых штатных, по видимому, ситуациях — иначе, они не были бы обработаны встроенными обработчиками.
VD>Просо проект не денежный и некому серьезно заняться даной проблемой, а так как не особо достает вот и живет очень давно.
Оправдываться я и сам умею. ИМХО, суть в том, что на мой взгляд, .Net просто позволил наплевать на некоторые вещи, или почему-то не позволил сконцентрироваться на них. Только-то и всего.
ГВ>>К слову сказать, 1.1.4b3.185 гораздо лучше, чем 1.1.3. VD>207 была самя качественная.
Попробую выкачать, спасибо.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
ГВ>>... и излишние упрощения тоже. Д>Тем не менее, факт остается фактом. Подавляющее большинство ошибок — это ошибки кодирования.
Угу, и потому вылавливаются влёт.
ГВ>>Потому что даже "прокатку" по памяти обычно можно вычислить быстро. Главное — засечь её существование. Д>Всего то навсего. Разве же это сложно — выявить то самое сочетание факторов, которое проявляется раз в месяц на одном компьютере из десяти?
Если ситуация доведена до такой — то это есть беда проектирования. Как минимум — следствие нарушения контроля типов. Извини, но это — медицинский факт. Во всяком случае — по моей практике.
Д>Вероятно, именно поэтому в инструкциях по кодированию появляется запрет под страхом смертной казни примененять арифметику указателей
Давай теперь подумаем — зачем и для кого пишутся инструкции по кодированию?
ГВ>>Блин, ну сколько можно повторять. Никто не защитит программиста (и программу) от ошибок лучше, чем он сам. Д>Бывают опасные бритвы, а бывают безопасные. Если очень хорошо постараться, то можно порезаться и безопасной. Но перерезать ей себе горло точно не получится. Ну если не считать особо талантливых индивидуумов
Кто же дураку запретит? Кстати, как ты думаешь, кого именно пытаются культивировать "современные направления IT-индустрии"? Я имею ввиду — в интеллектуальном смысле?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>С удовольствием бы согласился, если бы не периодичность падений и выстреливаний exceptions у того же Janus, к примеру.
А ничего что источник этих самых эксепшенов в Jet? Или в глюках джета тоже дотнет виноват?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>С удовольствием бы согласился, если бы не периодичность падений и выстреливаний exceptions у того же Janus, к примеру.
AVK>А ничего что источник этих самых эксепшенов в Jet? Или в глюках джета тоже дотнет виноват?
С точки зрения российских юзверей во всём виноват Чубайс, а не дотнет или дотда, или ещё какая борода
А насчёт того что были вы вынуждены использовать Jet.... Вообще в данном случае у меня, как пользователя Януса, биллюдтень с одним пунктом, итот проставлен
Здравствуйте, AndrewVK, Вы писали:
ГВ>>С удовольствием бы согласился, если бы не периодичность падений и выстреливаний exceptions у того же Janus, к примеру. AVK>А ничего что источник этих самых эксепшенов в Jet? Или в глюках джета тоже дотнет виноват?
А чего это они "пролетают" наверх и всё, что я вижу — это stack trace?
Впрочем, в любом случае — с Новым Годом!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, adontz, Вы писали:
A>Например отсыл сообщения об ошибке на newbug@janus.rsdn.ru,
Ты еще не забыл что янус проект некоммерческий? 99% багов разработчикам известны, проблема в том что нехватает ресурсов их пофиксить.
A> повтор запроса раза 3-4 (вдруг получиться?)
Здравствуйте, AndrewVK, Вы писали:
VD>>Что я могу скзать? Отсталое у тебя понимание. Или ты редко работал с исследователькими проектами. Подобный стиль и является частью процесса проектирования.
AVK>Это верно не только для исследовательских проектов. Собственно это одна из составляющих ХР.
ХР в чистом виде мне не очень подходит. У них сдвиг по фазе на юнит-тестах, а для того же R#-а оно не очень то прокатывает. Хотя возможно тут я и ошибаюсь.
AVK> И в нашем проекте мы тоже в итоге к подобному пришли, поскольку, как оказалось, самые качественные решения были получены именно таким путем.
Согласен. Паше же тяжело понять и принять пдобный подход, так как на плюсах он очень рискованный. Тут безопастность дотнета, автоматизированный рефакторинг и т.п. очень кстати оказывается. Так что как всегда мы смотрим на жизнь с разных уровней абстракции.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Нет, XP включает обязательный этап проектирования на каждой итерации. В классике, если не ошибаюсь — несколько дней на двухнедельных итерациях. Отличие от водопада в итерационном характере процесса, а не в отсутствии проектирования.
А про отсуствие проектирования — это ты уже домыслил. Просто и само проектирование и исполнение проекта могут быть выполненны по разному.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Безусловно. И Влад ведь тоже не говорит что проектировать вовсе не нужно. Но ключевое отличие — проектирование делается по месту, только на основании уже доступных данных, без особых предположений что там будет дальше. И тут есть еще один момент — исходной информацией для проектирования являются не только требования заказчика, но еще и текущее состояние системы (сложность программных структур, бутылочные горлышки, потребление ресурсов алгоритмом и т.п.). В точке 0 второй состовляющей у тебя практически нет. Поэтому собственно Влад и предлагает — спроектировать вчерне и получить более полную информацию о будущей системе, а потому же проектировать более тщательно и приближать существующую систему к идеалу путем рефакторинга.
Очень верно сформулировал. Подписываюсь под каждым словом.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК> Я так понимаю, ссылок на авторитетные источники, где бы design patterns причислялись бы к принципам ООП, ты привести не сможешь.
>> GOF тебя устроит?
ПК>Более чем. Итак, хоть одну ссылку оттуда, где бы паттерн назывался принципом ООП.
Пашь, меня уже задолбало бороться с вводимыми тобой подменами понятий. К сожалению я не всегда замечаю их сразу. В данном случае ты снова боришся с собственной подменой, а не с моим высказыванием. Посторайся в будущем удерживаться от подобных приемов.
Повторю еще раз цитату (полностью):
>>> В общем, не нужно выдавать свои желания за действительность. С++ пытается позволять писать в разных стилях, но рассчитан он в основном на два: структурный и ОО. И в этом свете ОО-дизайн является (должен являться) главной стратегией проектирования ПО. GOF, насколько я помню, использовал С++ в качестве одного из основных языков примеров.
>
> ПК>Ну и что?
>
> Вот и странно, почему 90% С++-программистов эти принципы или игнорируют, или вообще о них не слышало.
Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
Естествнно речь шла о принципах ОО-дизайна. Принципами ООП их подменил уже ты. Я же просто не согласен с тем, что перечисленный тобой список является принципами ООП. Принципы ООП — это наследование, инкапсуляция, полиморфизм. Куда засунуть приведенные тобой принципы я даже и не знаю.
ПК>Чудной ты человек... Тебе ж даже ход рассуждений продемонстрировали. Ты чем бросаться эпитетами, показал бы изъяны в последнем...
Я вижу уровень обсуждения (мышления можно сказать) и вижу, его ущербность. Вижу, что веловек рассуждает об использовании одного массива вместо другого, а не о том самом дизайне, используя при этом потенциально опасные решения. Подобную практику я называю халтурой. Нормальным выходом тут было бы применение какого-нибудь Моста или еще чего, но не описанных извратов.
ПК>+1: нормальный подход в качестве создания прототипа.
>> анализируешь резуальтат и рефакторишь прототип в законченное и более грамотное решение.
ПК>-1: прототип не годится для создания конечного дизайна.
очень хорошо описал данный подход. То что ты с ним не согласен еще не значит, что он не верен. Еще раз повторю только то, что ты умудрился будучи моложе меня очень сильно увязнуть в доисторических догмах. Технологии меняются. С ними меняются и подходы.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И получать такой же бред?
Открытые оскорбления являются хорошим доказательством отсуствия аргументов.
ГВ>Влад, не путай законченную мысль, выражаемую статьёй, и удовлетворительно работающую программу, выражаемую кодом.
Извини, но я кое-что понимаю в обоих областях.
ЗЫ
В общем, можете оставаться виртуально в кменном веке и не верить, что можно жить по другому. Реальность от этого не изменится. Сейчас можно и нужно проектировать и кодировать по другому. Более эффективно, просто и надежно.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> А в чем реальная разница? Что не дает сделать функция входящая в класс? И чем класс отличается от пространства имен для статической функции?
ПК>http://rsdn.ru/Forum/Message.aspx?mid=972007&only=1
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Речь о свободных функциях, которых, как мы уже выяснили, нет.
Так особо не нужны вот и нет. Я вообще не могу понять это упирание в незначительные подробности. Все необходимые возможности есть. То что подходы дргие, так это не удивительно.
ПК>Главным является то, что класс, в отличие от namespace, нельзя расширять в других модулях.
Да? И так:
class A
{
static void Test(int i);
}
class B : A
{
static void Test(string s);
}
?
Да и что мне даст расширение этого же класса если функции независимы?
ПК> Да и вообще, с точки зрения процедурного программирования, о котором шла речь, классы просто болтаются под руками: никакой нужды в них там нет,
Согласен. Особой нужды нет. Это всего лишь делает язык более стройным и простым. Нет лишних сущьностей нет и нужны лишнее запоминать и объяснять.
ПК>но несмотря на неудобства приходится использовать,
Да нет особых неудобств. Только структуризация становится лучше. Вот и все.
ПК> только из-за того, что их навязывает язык.
Он их и навязывает, чтобы небыло 100 разных вариаций одного и того же.
ПК>Если же посмотреть чуть шире, включая в область рассмотрения шаблоны/generics, то будет видно, что, например, некоторые техники, связанные с перегрузкой, из-за отсутствия свободных функций работать не будут.
ПК>Например, как без свободных функций вызвать в шаблоне/generic функции скалярное умножение двух векторов, если вектор может быть как встроенным массивом, так и структурой, определенной пользователем? Со свободными функиями легко: ПК>
ПК>Задача пользователя данной функции — определить scalar_multiplication для типов, которые передаются в данную функцию. Это можно сделать для любых типов, даже если тип определен в какой-то библиотеке, модифицировать которую мы не можем.
К "свободным функциям" это никакого отношения не имеет. Это ограничения дженериков. Если можно было бы обращаться к статическим членам дженериков, то нахждение функций в классах никак бы тут не помещало бы.
Ну, и решается все это довольно просто. Всегда можно передавать интерфейсы и делегаты через обычные параметры и свойства. Решения получаются только гибче. Это действительно насильное приучение к ООП, но тут я особых проблем не вижу.
ПК>Еще один, классический пример — функция swap(). Та же история: ее можно использовать из любых шаблонов для любых типов именно потому, что она является свободной функцией: пользователь может использовать готовую, либо, при желании, определить свою, более оптимальную, для своих или библиотечных типов.
Ерунда это, а не пример. Никакой связи со "свободной функцией" тут нет. Передавай сколько влезет делегаты. В них могут быть как статические, так и экземплярные методы. Проблем никаких тут нет.
ПК>В результате, без нормальной поддержки свободных функций, многие возможности языка недоступны пользователю, не желающему писать в ОО-стиле.
Возможности остаются на месте. Причем даже большее количество парадигм можно без извращений использовать. Например, можно написать код в функциональном стиле. Ну, а то что в ООЯ программиста подталкивают к ОО-дизайну, так это скорее хорошо чем плохо.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ИМХО, суть в том, что на мой взгляд, .Net просто позволил наплевать на некоторые вещи, или почему-то не позволил сконцентрироваться на них. Только-то и всего.
