Вопрос вполне философский - Философия программирования

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот как раз то, что не всегда уязвимость есть уязвимость Дворкин тщетно пытался объяснить своим оппонентам. Я отлично понимаю, что приведённый фрагмент кода — одна из распространённейших уязвимостей. Только всё зависит от задачи. И если Дворкин утверждает, что на 200% уверен в том, что суммарная длина szFisrtName + szLastName не превысит буфера, то, почему-то, я ему верю. Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения.
Нет. Уязвимость это всегда уязвимость. Даже есть это и не будет уязвимостью пока код править только Павел но когда код начнет править кто-то еще...

ГВ>Я про всех никаких посылок сделать не мог. Ибо сам являюсь частью этих самых "всех" и от .Net ну совсем не фанатею. А вот то, что .Net был приплетён к той самой дискуссии не совсем по месту — уверен до сих пор.
Ладно сведем понятие все до Я, Влад и Антон.

ГВ>Как совершенно справедливо утверждает Дворкин, истина всегда конкретна (у нас же не метафизичисеский форум, верно?).
Дело в том что этот форум именно что метафизический...
ГВ>И в рамках конкретных, озвученных им условий его решение нельзя признать неадекватным. Тогда как контрпримеры — более чем не к месту.
Контрпримеры чего? Того что операции над строками с длинной будут по крайней мере не медленней чем операции над строками с терминатором в конце?

ГВ>Погоди. Причём тут "борьба" с длиной строк? Да, Дворкин на самом деле упоминал перерасход памяти на длину в случае коротких строковых значений. Только причём тут архитектурная ошибка создателей C — совсем не понимаю.

ГВ>Про архитектурную ошибку крутое, надо сказать, определение, особенно, если учесть, что ASCIIZ-формат долеко не так глуп, как тебе кажется. Дело в том, что таким образом мы избавляемся от необходимости синхронизировать информацию о длине в поле длины с фактической длиной строки. То есть, сама строка становится защищённой от ошибок рассинхронизации данных. А это немало. Так что, я бы поостерёгся таких заявлений.
А вот с этого места по подробней пожалуйста. Чем установка терминатора в конце надежней установки длинны в начале? Не понимаю.

ГВ>А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием. Я надеюсь, ты не об этом:
Меня сегодня чегото поиск не взлюбил

А просматривать сотни сообщений...

ГВ>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
Нам джидаям...

ГВ>Очень хорошо. Более того, я даже отлично понимаю, о чём конкретно ты говоришь, произнося сии лозунги. Ещё более того, я отлично понимаю, какое влияние на тебя предварительно оказал C++ и свойственные ему подходы к проектированию. Я только в одном не уверен. В том, что это поймёт тот, кто не имеет за плечами опыт работы с C++. Не сочти за переход на личности, будь добр.
Вот только я сам довольно долго избавлялся от полюсовых замашек... мой плюсовый опыт в основном лежит в категории как делать не надо. В этом смысле плюсовый опыт несомненно ценен. Но плюсовые методы я не использую.

ГВ>Нет, Андрей. Ну как ты мог обо мне такое подумать? Это ж корова (священная!) мычит, а не ты.
В следующий раз не стоит выражатся двусмысленно. Я не люблю читать меж строк.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А не сообщит ли уважаемый сэр, откуда следует, что именно этот файл я сам сформировал ? Я ведь ясно написал
PD>>А вот я указатель на эту строку в memory-mapped файле возьму
PD>в этом примере. Откуда здесь файл — неизвестно, может, просто текстовый, в этом случае, конечно, нуля в конце нет, но идея та же — строка с терминатором без дллины.
Может я не так понял но мне почемуто мерещится что при расказе о той программе где тебе позарез нужно было уложится в 100 мсек ты говорил про то что генерировал какойто фаил?
Ссылку найти что-то не получается.

PD>Хм, интересно. Правильная архитектура сама по себе, а кэш сам по себе.
Правильно.
PD>Он в эту архитектуру вообще не входит, так что ли ?
Да.
PD>И при проектировании программы ты никак не подозревал об его существовании, а потом начал думать, как бы это улучшить, и ввел кэш ?
Именно.
PD>Что-то здесь не так. И , кажется, я даже понимаю что.
Не так тут то что такой стиль работы противоречит твоим привычкам.

PD>Архитектура правильная — это замечательно. Никто и не предлагает неправильную реализовать. Так что это опустим как тривиальность.
Правильность архитектуры понятие растяжимое. Очень растяжимое и у разных людей оно очень разное...
PD>А вот что касается эффективности — у тебя подсознательно сработал прежний личный опыт или даже не опыт, а полученная ранее откуда-то информация. И она тебе подсказала, что реальное быстродействие здесь может быть резко повышено за счет кеширования. Грубо (очень грубо) говоря, при кешировании все то, что тормозит, будет вызываться в 10 раз реже, и хотя работать будет само по себе не быстрее, но это будет незаметно. Ты это все время в уме держал, поэтому все и получилось хорошо.
В уме я это точно не держал. Ну может быть гдето очень глубоко в темном углу подсознания.
Мне было мягко говоря не до производительности. Нужно было создась гибкую и стройную систему на основе кучи разрозненных и противоречивых требований. Некоторые требования пришлось убрать, другие добавить, третии изменить... все это дело нужно было согласовать... Причем как всегда система была нужна вчера.

PD>А теперь представь себе на минуту, что ты о кешировании никогда не слышал и даже не знаешь, что это слово означает.
Те представить что я не профпригоден?
PD>И вот ты сделал свой движок, тормозит он жутко, как сам пишешь, а про кэш ты не знаешь. Или хуже — неприменим здесь кэш. Или не дал результата. И других методов условно говоря внешней оптимизации нет (под внешней я понимаю то, что не относится к архитектуре по твоему же определению)
Я бы назвал это внутренними оптимизациями. Тк они выполняются внутри одного слоя не влияя на интерфейс этого слоя.
В моем случае был код типа такого(в реальной системе сущностей было на много больше):

interface ISomeHost
{
    ISome GetSome(ISomeKey key);
    ...
}
interface ISome
{
    ISomeElse SomeElse { get; }
    ISomeThing SomeThing { get; }
    ...
}

Причем все объекты были imutable и могли сравниватся на равенство не только по ссылкам но и по состоянию.
Причем данная архитектура была выбрана не по тому что тут открывается огромный простор для оптимизациий начиная от банального кеширования до генерации кода во время работы программы, а по тому что такая архитектура очень устойчива ко всяким недразумениям. И очень легка в поддержке и изменении.

PD> Что делать будешь ?
В четвертый раз все перепишу с учетом производительности. Всеравно это будет быстрее чем постоянно о ней думать.
Хотя последний раз я такими вещами занимался когда писал бинарный diff для бэкапа базы RSDN.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это уже слишком все же. Речь изначально шла о том, как вывести некие данные в некоем формате. Этот формат был задан мной для демонстрации того, где лучше использовать последовательный вывод, а где нет. Сам формат просто предложен для демонстрации (запись разреженной матрицы в определенном формате) Теперь оказывается, что fseek нужен не для того, чтобы выводит в файл наилучшим по моему мнению методом именно для этого формата, а вообще для того, чтобы уменьшить объем хранимых данных!!!
Есть задача и есть решение этой задачи.
Если стоит задача сохранить и востановить разряженую матрицу то использования fseek не оправданно и это тебе показали.
Также небыло продемонстрированно ни одного случая когда при необходимости сохранить и востановить состояние объекта нужен был бы произвольный доступ.
Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается.
Также произвольный доступ нужен при выполнении запросов. Это я про матрицу со средними значениями. Ибо мы востанавливаем объект не в том состоянии в котором он был до сохранения.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vdimas, Вы писали:

V>Во-первых, для нашей отрасли не между модулями а между абстракциями, а во-вторых, первый бросающийся в глаза агрумент — типизированность vs нетипизированность. Или оная статическая vs динамическая. Есть и другие аргументы. Погугли насчет того как пишутся критичные к надежности приложния и что там насчет сильной связи.

ослабление связей тоже достигается разными средствами. Использование более слабых видов типизации — только один из них. Уменьшение количества связей, а не их качества — это надежности не повредит, а даже совсем наоборот.

V>В общем, как всегда с ног на голову. Loose coupling — это не самоцель, а лишь один из параметров к оптимизации в наших многомерных задачах. В конкретных случаях, ессно, параметрам раздают конкретные коэффициенты. Ну а далее включаем стандартные механизмы многофакторных оптимизаций с весовыми коеф. и получаем результаты согласно весовых коеф. Все это относится не только к loose coupling, а вообще к любым критериям/параметрам. И именно поэтому не существует "серебрянной пули". В общем, спец должен не только обладать некими знаниями для успешной деятельности, но и уметь их прикладывать по месту.

V>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?

не использовал и не слышал ни от кого, что он серьезно это использует

То есть слышать то конечно слышал и даже немного видел, но все те проекты можно смело отнести к разряду псевдонаучной синекуры.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Нет, глупостью с твоей стороны на самом деле было то, что ты решил, что я обязан видеть в сообщениях других то и только то, что ожидаешь ты и ещё несколько авторов ФП.

ГВ>По существу моего замечания, как я понимаю, тебе возразить нечего? O'K, так и отметим.

по сушеству, говоришь?
Ну во первых — если ты думаешь, что хитроумная словесная эквилибристика — это круто и сразу показывает всем твой неимоверный IQ, то лучше тебе перестать так думать. У нас здесь все-таки не состязания адвокатов.
Во вторых — я не "ожидаю" чего-то услышать ни от кого. Выслушать интересные и оригинальные мысли я готов от любого. Некоторые пишут что-то интересное часто, некоторые — не очень, а некоторые — никогда.

ГВ>Вот здесь, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:

то, что более сложная операция еще и работает быстрее — это по твоему естественно?

ГВ>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.

рассуждения про .NET он сам начал. Видимо, своё самое первое сообщение ему и надо было похе*ить по факту, а еще лучше перед его совершением?

ГВ>И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".

доказал? что именно доказал и каким образом?

ГВ>Что же до одиозного высказывания Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.

"здесь так принято" и "по историческим причинам" — это стандартные отмазки для решений, принятых по невежеству или недомыслию.
если интерфейс урезает информацию, а быстродействие критично для задачи — значит, надо искать другой интерфейс, вот и всё. Сейчас, к счастью, не 90е годы, выбор имеется.
Даже если выбрать не из чего, длину строки все равно достаточно вычислить один раз — сразу после извлечения инфы. Дальнейшие операции над данными, (если операций будет больше чем одна

), однозначно окупят эту небольшую затрату.
вместо этого наш герой выбирает заведомо неэффективный путь решения задачи и начинает усердно его оптимизировать, положив большой болт на все принципы качественного кодирования — при наличии более быстрого и "чистого" решения

ГВ>Ну, ни ты ни я надо всей индустрией свечку не держали.

я работал в разнообразных областях, и представление о распространенности тех или иных задач имею достаточно хорошее

ГВ>Да даже если и предположить, что в индустрии чаще встречаются задачи, не требующие анализ свойств алгоритмов, это не отменяет необходимости такого анализа в тех случаях, когда это необходимо (это я специально повторяюсь, чтобы не возникало разночтений). А из априорной неизвестности такой необходимости следует, что анализировать в том или ином виде таки нужно всегда (это я снова специально повторился).

ГВ>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?

есть определенная отличная от нуля вероятность, что под кустом, возле которого ты собрался разводить костер, сидит смертельно опасная ядовитая змея. Нужно ли перед разведением костра обшаривать палкой все окрестные кусты? Всё еще уверен, что нужно? А если известно, что дело происходит в Сибири, где самая опасная змея — это всего лишь гадюка, зато на каждом кусте пачками сидят опасные клещи?

ГВ>Нет, не замечаю таких изменений, которые бы подходили под определение разумности. Помощь в навигации — да. Но тенденции к сверхразумности пока не замечаю. Кроссмодульная оптимизация здесь ни при чём — ей как идее сто лет в обед.

никто и не говорит про разумность. Всего лишь автоматизация рутинных операций по оптимизации.
Идея то старая, но достойные практически применимые реализации появились совсем недавно. Как это обычно и бывает.

ГВ>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях.

"не самых благоприятных"?

благоприятнее условия даже придумать сложно

ГВ> Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят.

ГВ>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).

эта священная корова по крайней мере подтвердила свою жизнеспособность в существующих на данный момент условиях. В отличие от.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>"...если умеет думать головой..." Ха-ха-ха. Нет такого человека, который сам бы вывел всю теорию сложности, или функциональный анализ, или топологию. Вот Ньютон говорил: "я стоял на плечах гигантов".

LCR>Чтобы вырваться из клетки невежества нужен проводник.

для этого нужны карты. А проводник нахрен не нужен, если это Сусанин.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, vdimas, Вы писали:

V>Не раздавай впредь ярлыков насчет недоучек, ok? То свое заявление насчет ассемблера я сделал после примерно 3-х летнего участия/чтения rsdn и не хуже тебя знаю, какие мнения на этот счет здесь ходят. Тем не менее счел возможным озвучить. Сможешь опровергнуть меня более быстрым своим кодом на "высокооптимизируемом" С++ — welcome. Не сможешь — держишь свои соображения насчет "неучей" при себе. (Кста, если обратил внимание, я тусуюсь ближе к лагерю сторонников С++ в местных баталиях)

интересно, почему вдруг сопоставление "С++ vs ручное кодирование" првератилось в "мой код против твой код"? Вероятно, чтобы потом доказать, что мой код ни на что не годится? Ну так я и не позиционирую себя как программиста на ассемблере. Я на нем уже лет десять не писал, если тебе это так интересно.
Я всего лишь сказал, что код современного компилятора мало кто способен превзойти по скорости. Ты можешь это сделать? Прекрасно, очень хорошо для тебя. Желательно подтвердить это фактами, конечно. Но если не можешь, я попробую поверить на слово

V>Разница в том, что в случае Б в тим-лидерах и более старших руководителях ходили люди, гораздо менее ориентирующиеся в своей специальности, чем рядовые программисты. Такое действиетльно наблюдалось часто.. довольно давно... Сейчас мне такой сценарий кажется маловероятным. Ответ на эти твои длинные копи-пейсты содержался в самом начале, см. выделенное.

если руководители не разбираются в предмете, то нет никакой разницы, идиоты их подчиненные или нет. Они все равно не смогут заметить разницы.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А собственно, почему ? Из чего следует, что они есть ? Я призываю думать и о реализации — мне говорят — у Вас проблемы с абстрагированием. Если я про абстрагирование вообще почти не говорю, потому что это для меня просто промежуточный этап, то из этого следует, что я вообще это делать не умею ?

PD>Мягко выражаясь, странная логика.

странноватая логика — это начинать описывать свои рассуждения с конца. В особенности, когда тебя спрашивают про начало и ты не можешь внятно про него рассказать.
Никакого внятного объяснения, почему для ускорения скорости работы со строками ты выбрал ASCIIZ-строки, я так и не добился.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Дарней, Вы писали:

Д>Ну во первых — если ты думаешь, что хитроумная словесная эквилибристика — это круто и сразу показывает всем твой неимоверный IQ, то лучше тебе перестать так думать. У нас здесь все-таки не состязания адвокатов.

Овладевайте предметом, что я могу ещё сказать? Можно проще — не бросайте слов на ветер. Они ведь, как воробей...

Д>Во вторых — я не "ожидаю" чего-то услышать ни от кого.

Да, согласен, возможно, что я сделал неправильное предположение относительно твоих ожиданий. Но это был единственный способ охарактеризовать мотивацию возникшего противостояния. Возможно, что я и здесь ошибаюсь.

Д>Выслушать интересные и оригинальные мысли я готов от любого. Некоторые пишут что-то интересное часто, некоторые — не очень, а некоторые — никогда.

+1

ГВ>>Вот здесь, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:

Д>то, что более сложная операция еще и работает быстрее — это по твоему естественно?

ГДЕ???? Перечитай внимательно вот эту ветку дискуссии. Читать с 24-го по 33-е сообщение. Дальше уже "разводка" началась: Дворкин привёл заведомо искусственный пример и к этому примеру прицепились.

Повторяю исходный пример вместе с условиями: на входе N 'const char*' без дополнительной информации. Выполнить конкатенацию за минимальное время. Общая длина всех N строк никогда (то есть, вообще, то есть — совсем никогда, даже на Марсе) не превысит 500 байт. Наводящий вопрос 1: куда будем std::string совать (не забывая о том, что std::string по умолчанию работает с malloc/free)? Наводящий вопрос 2: что такое фрагментация памяти? Наводящий вопрос 3: а что, если заказчик запретит использовать C++ не говоря уже о .Net?

ГВ>>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.

Д>рассуждения про .NET он сам начал. Видимо, своё самое первое сообщение ему и надо было похе*ить по факту, а еще лучше перед его совершением?

А он его и не о том писал, о чём нектороые подумали. Я понимаю, что ПД совершил нецензурное действие — упомянул .Net не в благоговейном смысле.

ГВ>>И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".

Д>доказал? что именно доказал и каким образом?

Он доказал, что безопасные подходы напрочь "сливают" по быстродействию перед потенциально опасным, но обдумано применённым. Прости, но твой пример с strcat совершенно не подходит, поскольку strcat попросту не передаёт нужной информации пользователю, а именно — указатель на конец результирующей строки. Без этой маленькой детали поточные операции конкатенации налетают на оверхед, связанный либо с обновлением поля длины, либо с необходимостью вычисления длины строки заново.

ГВ>>Что же до одиозного высказывания Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.

Д>"здесь так принято" и "по историческим причинам" — это стандартные отмазки для решений, принятых по невежеству или недомыслию.

В огороде бузина, в Киеве пальцем в небо тычут. Да, верно. "исторические причины" часто становятся отмазками. Ровно до тех пор, пока не столкнёшься со следствиями этих исторических причин без возможности на них повлиять. Дальше можно возопить к небесам и предать интерфейс анафеме. Говорят, помогает медитация на тотем.

Извини моё ёрничество, но оснований к твоему утверждению об отмазках я в той одиозной дискуссии не заметил. Если желаешь — докажи обратное. С удовольствие соглашусь с тобой, если оказался неправ.

Д>если интерфейс урезает информацию, а быстродействие критично для задачи — значит, надо искать другой интерфейс, вот и всё. Сейчас, к счастью, не 90е годы, выбор имеется.

Я уже напоминал цитату, не буду повторяться. Не было возможности использовать C++. Да он и не нужен при обсуждаемых операциях.

Д>Даже если выбрать не из чего, длину строки все равно достаточно вычислить один раз — сразу после извлечения инфы. Дальнейшие операции над данными, (если операций будет больше чем одна

), однозначно окупят эту небольшую затрату.

А вот фокус как раз в том, что судя по всему операция ОДНА, так что остальные рассуждения отбрасываются по факту их неприменимости.

Д>вместо этого наш герой выбирает заведомо неэффективный путь решения задачи и начинает усердно его оптимизировать, положив большой болт на все принципы качественного кодирования — при наличии более быстрого и "чистого" решения

К счастью, этой задачей занимался не кодер, нахватавшийся "правильных" принципов, а вменяемый программист. С чем я ПД вкупе с его заказчиками и поздравляю.

ГВ>>Ну, ни ты ни я надо всей индустрией свечку не держали.
Д>я работал в разнообразных областях, и представление о распространенности тех или иных задач имею достаточно хорошее

Сие наблюдение не имеет доказательного значения, поскольку неизвестны а) условия, б) твоё влияние на контекст. Так что, делать выводы относительно всей индустрии, пока не соберёшь справки ото всех — бессмысленно.

ГВ>>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?

Д>есть определенная отличная от нуля вероятность, что под кустом, возле которого ты собрался разводить костер, сидит смертельно опасная ядовитая змея. Нужно ли перед разведением костра обшаривать палкой все окрестные кусты? Всё еще уверен, что нужно?

Ты исходишь об априорном знании о ядовитости змей и вероятности их появления. Так что, пример не в кассу.

Вообще, я считаю, что в такие места лучше не ходить, а поляну под пикник, буде приспичило, подготавливать огнемётом.

Д>А если известно, что дело происходит в Сибири, где самая опасная змея — это всего лишь гадюка, зато на каждом кусте пачками сидят опасные клещи?

Тогда причём тут змея? Нужно думать о противоэнцефалитной прививке, не правда ли?

Одним словом, в своих примерах ты забываешь о том, что некоторое знание о контексте у тебя уже есть. Я же приводил свой пример для иллюстрации некоторого "предельного" состояния — отказ от анализа вообще. Однако, пример правомерен, поскольку такой тезис (об отсутсвтвии необходимости предварительного анализа алгоритмов) неоднократного приводился оппонентами Дворкина. Дескать, сначала абстракция — потом разбираемся.

ГВ>>Нет, не замечаю таких изменений, которые бы подходили под определение разумности. Помощь в навигации — да. Но тенденции к сверхразумности пока не замечаю. Кроссмодульная оптимизация здесь ни при чём — ей как идее сто лет в обед.

Д>никто и не говорит про разумность.
Д>Всего лишь автоматизация рутинных операций по оптимизации.
Д>Идея то старая, но достойные практически применимые реализации появились совсем недавно. Как это обычно и бывает.

Верно подмечено. Потому-то это и не означает эпохального прорыва. Задачи кроссмодульной оптимизации в случае того же самого C++ давным-давно решаются посредством шаблонов и совершенно классической оптимизации на уровне одного модуля. Актуальной КМО стала при активном использовании языков типа Java, где нет явного inline. Тогда как Java... Впрочем, это уже тема для другого флейма.

ГВ>>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях.

Д>"не самых благоприятных"?

Д>благоприятнее условия даже придумать сложно

Ух ты!!!? То есть, явное требование применять только C — это просто таки благоприятнейшие условия для .Net?

ГВ>> Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят.
ГВ>>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).

Д>эта священная корова по крайней мере подтвердила свою жизнеспособность в существующих на данный момент условиях. В отличие от.

А ты знаешь, кого вообще больше? Цитату напомнить? Она касалась, казалось бы, умнейших людей планеты... Так что, на основании жизнеспособности того или иного бзика далекоидущие выводы делать не стоит.

Здравствуйте, Дарней, Вы писали:

V>>Во-первых, для нашей отрасли не между модулями а между абстракциями, а во-вторых, первый бросающийся в глаза агрумент — типизированность vs нетипизированность. Или оная статическая vs динамическая. Есть и другие аргументы. Погугли насчет того как пишутся критичные к надежности приложния и что там насчет сильной связи.

Д>ослабление связей тоже достигается разными средствами. Использование более слабых видов типизации — только один из них.

Чудовищно опасный способ, кстати. Как с позиций производительности, так и с позиций надёжности.

Д>Уменьшение количества связей, а не их качества — это надежности не повредит, а даже совсем наоборот.

Что есть "качество связи"?

V>>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?

Д>не использовал и не слышал ни от кого, что он серьезно это использует

То есть слышать то конечно слышал и даже немного видел, но все те проекты можно смело отнести к разряду псевдонаучной синекуры.

Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А впрочем, может ты и прав. На фанатиков логикой действовать — не получается.

Ох, что-то сдается мне что фраза "Я тут в очередной раз с адептами .Net схватился." является синонимом "Захотелось мне в очередной раз пофлеймить."

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

ГВ>>Вот как раз то, что не всегда уязвимость есть уязвимость Дворкин тщетно пытался объяснить своим оппонентам. Я отлично понимаю, что приведённый фрагмент кода — одна из распространённейших уязвимостей. Только всё зависит от задачи. И если Дворкин утверждает, что на 200% уверен в том, что суммарная длина szFisrtName + szLastName не превысит буфера, то, почему-то, я ему верю. Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения.
WH>Нет. Уязвимость это всегда уязвимость.

А давай не будем путать понятия (1) потенциально опасный код и (2) уязвимость программы? (1) может и не означать (2), а вот обратное, как правило, верно.

WH>Даже есть это и не будет уязвимостью пока код править только Павел но когда код начнет править кто-то еще...

Ну, если к тому времени условия поменяются так, что будет снято ключевое требование к быстродействию, а вместо него появится требование устойчивости к изменениям внешних данных, то тогда такая программа с большой вероятностью будет переписана полностью... На данный же момент ситауция, как я понимаю, такая, что вероятность модификации небольшая, а ламеров к модификации не подпустят.

ГВ>>Я про всех никаких посылок сделать не мог. Ибо сам являюсь частью этих самых "всех" и от .Net ну совсем не фанатею. А вот то, что .Net был приплетён к той самой дискуссии не совсем по месту — уверен до сих пор.
WH>Ладно сведем понятие все до Я, Влад и Антон.
O'K

ГВ>>Как совершенно справедливо утверждает Дворкин, истина всегда конкретна (у нас же не метафизичисеский форум, верно?).
WH>Дело в том что этот форум именно что метафизический...

Ага. Значит, применять некие некорректные но "конкретные" аргументы для опровержения некоей "метафизической" истины — это правильно? Мда. Дзен-буддисты нервно медитируют в сторонке.

ГВ>>И в рамках конкретных, озвученных им условий его решение нельзя признать неадекватным. Тогда как контрпримеры — более чем не к месту.
WH>Контрпримеры чего? Того что операции над строками с длинной будут по крайней мере не медленней чем операции над строками с терминатором в конце?

Да не откуда там было взять длины-то.

Ты c const char* никогда не работал, что-ли?

ГВ>>...ASCIIZ-формат долеко не так глуп, как тебе кажется. Дело в том, что таким образом мы избавляемся от необходимости синхронизировать информацию о длине в поле длины с фактической длиной строки. То есть, сама строка становится защищённой от ошибок рассинхронизации данных. [...]
WH>А вот с этого места по подробней пожалуйста. Чем установка терминатора в конце надежней установки длинны в начале? Не понимаю.

Тем, что не требует модификаций дополнительного отвлечённого от содержания строки поля. Строка получается "самодокументированной". Достаточно плюхнуть '\0' в нужном месте и получаем строку. Конкатенация тоже выполняется просто: найти в строке-назначении 0 и скопировать, начиная с этого адреса, указанную строку. Потом поставить 0 по адресу следующего за последним символа. И здесь не требуется, например, отслеживать смещение от начала строки, так что, такая операци применима, например, при поточной передаче данных.

Сравни вот такие конструкции:

void transmit(const char *src)
{
  while(*src) do_low_level_transmit(*src++);
}

void transmit(const char *src, int size)
{
  while(size-- >= 0)
    do_low_level_transmit(*src++);
}

Второй вариант выглядит более сложным и более подверженным ошибкам... ИМХО, разумеется.

Кроме того, нет необходимости выбирать и фиксировать размер поля длины. Каким оно должно быть? 1 байт (паскаль)? 2 (часто хватает)? 4 (почти предел)? 8 (хватит надолго)? 16 (навсегда?)? Байт длины длины + означенное им значение (на случай споров)? Всех этих заморочек удаётся избежать, когда символьный поток просто разрезается терминаторами. Поскольку меньше заморочек — меньше и приколов. Автоматы обработки строк можно строить не опасаясь переполнения счётчика позиции, к примеру. А это тоже предотвращает ряд проблем в некоторых случаях.

Но я, разумеется, не собираюсь агитировать за повсеместный переход на const char*...

ГВ>>А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием. Я надеюсь, ты не об этом:
WH>Меня сегодня чегото поиск не взлюбил

А просматривать сотни сообщений...

Я подожду. Да и Дворкин, похоже, заинтересовался.

ГВ>>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
WH>Нам джидаям...

...завсегда везде ништяк? Так чего тогда спорите?

ГВ>>Очень хорошо. Более того, я даже отлично понимаю, о чём конкретно ты говоришь, произнося сии лозунги. Ещё более того, я отлично понимаю, какое влияние на тебя предварительно оказал C++ и свойственные ему подходы к проектированию. Я только в одном не уверен. В том, что это поймёт тот, кто не имеет за плечами опыт работы с C++. Не сочти за переход на личности, будь добр.
WH>Вот только я сам довольно долго избавлялся от полюсовых замашек... мой плюсовый опыт в основном лежит в категории как делать не надо. В этом смысле плюсовый опыт несомненно ценен. Но плюсовые методы я не использую.

Я не говорил о прямом переносе методов. Я говорил о влиянии C++. В чём конкретно оно выражается в твоём случае — трудно сказать. Ну хоть в отборе неправильных методов. Тоже результат опыта.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что есть "качество связи"?

это как раз использование разной степени слабости типизации

ГВ>Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй?

а у нас вся индустрия такая

по ней и сужу

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Дарней, Вы писали:

ГВ>>Что есть "качество связи"?
Д>это как раз использование разной степени слабости типизации

То есть, связь с использованием слабой типизации — низкокачественная, а связь с использованием сильной типизации — высококачественная?

ГВ>>Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй?
Д>а у нас вся индустрия такая

по ней и сужу

Странная у вас индустрия...

Здравствуйте, Дарней, Вы писали:

LCR>>Чтобы вырваться из клетки невежества нужен проводник.
Д>для этого нужны карты. А проводник нахрен не нужен, если это Сусанин.

Да добро бы карты, а то, пачка Беломора предлагается...

Здравствуйте, Pavel Dvorkin, Вы писали:

Sinclair>>Поскольку он был воспитан на микроконтроллерах, где всю работу со строками надо было делать вручную

PD>Можно узнать — откуда эта информация ? Дело в том, что с микроконтроллерами я, насколько себя помню, никогда в жизни дела не имел. Нет такого в моей биографии. Это, конечно, печально, но вот нет...
PD>Так что сообщите пожалуйста, кто обо мне такую дезинформацию дает.

Вот так и создаются мифы.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>То есть, связь с использованием слабой типизации — низкокачественная, а связь с использованием сильной типизации — высококачественная?

нет, они просто разные

ГВ>Странная у вас индустрия...

а другого глобуса у вас нет?

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Овладевайте предметом, что я могу ещё сказать? Можно проще — не бросайте слов на ветер. Они ведь, как воробей...

не понял. каким предметом? искусством софистики, что ли?

ГВ>Повторяю исходный пример вместе с условиями: на входе N 'const char*' без дополнительной информации. Выполнить конкатенацию за минимальное время. Общая длина всех N строк никогда (то есть, вообще, то есть — совсем никогда, даже на Марсе) не превысит 500 байт.

конкатенация и прочие операции над полученными строками там выполняются далеко не один раз.

ГВ>Наводящий вопрос 2: что такое фрагментация памяти?

наводящий вопрос — что такое кэширование буферов и TLS?

ГВ>Наводящий вопрос 3: а что, если заказчик запретит использовать C++ не говоря уже о .Net?

а если он вообще запретит использовать строки с длиной?

ГВ>А он его и не о том писал, о чём нектороые подумали. Я понимаю, что ПД совершил нецензурное действие — упомянул .Net не в благоговейном смысле.

Пд совершил нецензурное действие — взялся ругать то, в чем не разбирается.

ГВ>Он доказал, что безопасные подходы напрочь "сливают" по быстродействию перед потенциально опасным, но обдумано применённым. Прости, но твой пример с strcat совершенно не подходит, поскольку strcat попросту не передаёт нужной информации пользователю, а именно — указатель на конец результирующей строки. Без этой маленькой детали поточные операции конкатенации налетают на оверхед, связанный либо с обновлением поля длины, либо с необходимостью вычисления длины строки заново.

это актуально только в том случае, если строки часто передаются в/из внешний asciiz-based код, а расходы на собственно обработку данных невелики. ПД сам сказал, что основной затык по скорости был при обработке строк внутри программы.

ГВ>В огороде бузина, в Киеве пальцем в небо тычут. Да, верно. "исторические причины" часто становятся отмазками. Ровно до тех пор, пока не столкнёшься со следствиями этих исторических причин без возможности на них повлиять. Дальше можно возопить к небесам и предать интерфейс анафеме. Говорят, помогает медитация на тотем.

у нас сейчас не 90е годы, и такое встречается редко

ГВ>Извини моё ёрничество, но оснований к твоему утверждению об отмазках я в той одиозной дискуссии не заметил. Если желаешь — докажи обратное. С удовольствие соглашусь с тобой, если оказался неправ.

я имел несчастье следить за этой дискуссией долгое время, и у меня сложилось именно такое впечатление. ПД сначала решил, как сделать — а потом придумал, почему надо делать именно так. Ничем другим его невнятные объяснения я объяснить не могу.

ГВ>А вот фокус как раз в том, что судя по всему операция ОДНА, так что остальные рассуждения отбрасываются по факту их неприменимости.

это уже твои домыслы. ПД сам заявлял противоположное.

ГВ>Ты исходишь об априорном знании о ядовитости змей и вероятности их появления. Так что, пример не в кассу.

ну а как же. Когда ты собираешься делать проект, у тебя же должна быть хотя бы общая информация о возможных проблемах?

ГВ>Вообще, я считаю, что в такие места лучше не ходить, а поляну под пикник, буде приспичило, подготавливать огнемётом.

тогда тебе в армию наверно надо. там тоже любят радикальные решения

ГВ>Тогда причём тут змея? Нужно думать о противоэнцефалитной прививке, не правда ли?

при том, что из возможных рисков надо выбирать самые значимые. Алгоритмические сложности могут входить в их число, а могут и не входить. Равно как и необходимость написания низкоуровневого кода.

ГВ>Одним словом, в своих примерах ты забываешь о том, что некоторое знание о контексте у тебя уже есть. Я же приводил свой пример для иллюстрации некоторого "предельного" состояния — отказ от анализа вообще. Однако, пример правомерен, поскольку такой тезис (об отсутсвтвии необходимости предварительного анализа алгоритмов) неоднократного приводился оппонентами Дворкина. Дескать, сначала абстракция — потом разбираемся.

А кто предлагает отказываться от анализа вообще? Такой тезис приводил только сам Дворкин — "оптимизируй везде, где можно"

ГВ>Верно подмечено. Потому-то это и не означает эпохального прорыва. Задачи кроссмодульной оптимизации в случае того же самого C++ давным-давно решаются посредством шаблонов и совершенно классической оптимизации на уровне одного модуля. Актуальной КМО стала при активном использовании языков типа Java, где нет явного inline. Тогда как Java... Впрочем, это уже тема для другого флейма.

А эпохального прорыва и не будет. Есть только эволюция, и игнорировать ее результаты просто глупо.

ГВ>Ух ты!!!? То есть, явное требование применять только C — это просто таки благоприятнейшие условия для .Net?

ух ты! почему то я не заметил во флейме тезиса ".NET это фигня, потому что мне запретили его использовать в проекте"

ГВ>А ты знаешь, кого вообще больше? Цитату напомнить? Она касалась, казалось бы, умнейших людей планеты... Так что, на основании жизнеспособности того или иного бзика далекоидущие выводы делать не стоит.

При чем здесь люди и их интеллект?
больше тех технологий, которые лучше умеют выживать. Если Дворкин лучше всех знает, как писать программы, почему его программы никто не использует? Только не надо начинать разговоры про маркетинг — его возможности очень сильно преувеличивают.

... << RSDN@Home 1.1.4 stable rev. 510>>

	От:	Pavel Dvorkin
	Дата:	28.02.06 12:22
	Оценка:	37 (3) +2

	От:	Pavel Dvorkin
	Дата:	28.02.06 12:24
	Оценка:

	От:	WolfHound
	Дата:	28.02.06 20:39
	Оценка:	-1

	От:	WolfHound
	Дата:	28.02.06 20:39
	Оценка:

	От:	WolfHound
	Дата:	28.02.06 20:39
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	01.03.06 00:45
Оценка:

	От:	Воронков Василий
	Дата:	01.03.06 01:45
	Оценка: