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

PD>>А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.

AVK>Так в приложении это функционал в конце концов нужен. Или ты предлагаешь делать одну и ту же работу 2 раза?

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

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

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

Это ты Дворкину скажи:

А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.

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

Автор: Pavel Dvorkin
Дата: 14.02.06

:
Re[13]: Каков глубокий смысл сериализации?

Автор: Pavel Dvorkin
Дата: 14.02.06

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

S>А какое отношение длина файла имеет к сериализации? Ты что, думаешь что fseek волшебным образом ее сократит? Разве что если ты две матрицы поверх друг друга запишешь
Самое непосредственное. При этом будут записаны ненулевые элемениы только. В один проход. И размер волшебным образом сократится — расчеты я сегодня утром приводил, то ли в письме к тебе, скорее к VladD2, посмотри сам.

Это было бы понятно, если бы ты не знал другого способа сократить объем. Однако еще за два дня до этого постинга я написал тебе, как сериализовать разреженную матрицу без fseek. И ты к этому моменту на тот постинг уже ответил, т.е. текст читал. Просто предпочел проигнорировать. Как и вопрос про применение компрессии. Действительно — зачем об этом спорить? Лучше пойти в другую ветку и снова начать рассказывать про какие-то "файлы длины в N раз больше чем надо".

PD>Честно говоря, у меня никакого желания дискутировать нет с теми, кто себе это позволяет. Когда на такие передергивания идут — спорить бессмысленно. Это уже не спор для нахождения истины, а просто желание во что бы то ни было доказать свою правоту. Не гнушаясь при этом ничем.
Ну вот опять. Павел, да, я такой негодяй. Для доказательства своей правоты я не гнушаюсь перечитыванием переписки и называнием вранья враньем, а непонимания — непониманием. Зато я читаю аргументы, и меня можно убедить. Естественно, не при помощи стенаний и заведомо некорректных утверждений.

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

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

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

_>Глупость. Если так, то надо абсолютно все в коде проверять. Любой другой код потенциально опасный. Я те серьезно говорю. Поэтому часто код интерфейсный часто стараются покрыть проверками на граничные условия, а дальше, вглубь — пишут как можно эффективней. Еще раз, я не об assert'ах. Их же в релизе нет. Да их везде не поставишь.
Именно что проверять надо все и везде. По крайней мере строгую защиту памяти (такую как в управляемых средах) отключать нельзя вобще.
Иначе мы имеем то что имеем... нестабильно рабетающий софт и куча вирусов.

_>У тебя "а если" слишком много. Читай условие задачи. Оно четкое. Если бы у бабушки... то бабушка была бы дедушкой. Знаешь такую фразу? )))
Можно подумать у моих опанентов их меньше...

_>Еще раз объясняю — программирование есть инженерная специальность. И чтобы не рухнуло при запуске, чтобы нагрузки тянуло — надо основные узкие места продумывать при проектировании, считать, оценивать. Иначе будет полная фигня. Архитектуру по ходу потом уже не изменишь.
Правда чтоли? А я менял... теперь буду знать что это сделать невозможно...

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

_>Ты понимаешь, я не хочу тебя обидеть, оскорбить и т.д. Я говорю тебе то, что есть. Особенно в свете твоей фразы http://rsdn.ru/forum/Message.aspx?mid=1706572&only=1

Автор: WolfHound
Дата: 01.03.06

про PE-формат
Ну никода я не занимался ни разработкой линкеров, ни разработкой загрузчиков... но если ты думаешь что для меня будет проблоемой изучить PE формат или написатль приложение которое экономит каждый такт то поверь мне ты жестоко заблуждаешься.
Понимаешь для меня всякие там PE, файловые системы и тп это детали реализации абстракций с которыми я работаю. И мне чесно говоря начхать на то как они устроены если у меня не стоит задача работать на этом уровне абстракции.
Просто если следовать твоей логике то при разработке той подсистемы я должен был изучить: Формат сборок .NET, формат PE файлов, знать устройство файловой системы в плоть до того как винт читает информацию,... и еще много другой фигни. Хотя мне было достаточно частично изучить System.Reflection, System.Xml и иметь поток без произвольного доступа.
_>и твоих заяв про Сингулярити.
А именно? Только аргументированно пожалуйста.
_>Однако тенденция. И ты еще споришь с безусловно грамотными людьми вроде Павла. Я тебе серьезно говорю, ты изучай подход людей к решению проблем, это классический подход эффективных и успешных разработчиков. Он ничего нового не предлагает, он просто пытается тебе азбуку прочитать.
Я этот подход не хуже Павла знаю. Просто для меня это пройденный этап.

_>Далее, просто смешно читать твои посты про "удачную архтитектуру". Детский сад. Ща объясню.
Ню-ню.
_>Понимаешь, удачных архитектур не бывает.
Идеальных не бывает это да. А вот достаточно хорошие те удачные вполне.
_>И обычно непосредственные разработчики это прекрасно знают. И больше всех обычно недовольны и хотят ее еще улучшить. То есть больше всего критикуют архитектуру непосредственные разработчики. Это даже не факт, так оно и есть на самом деле. Поверь. Нет идеальных решений. Конечно если ты не прочитал впервые книжку вроде "Банда четырех" или что-то еще. Тогда некоторые начинают просто на них молиться. Надеюсь, что не так.
Если ты думаешь что я хоть одну свою программу считаю идеальной то ты заблуждаешься. Другое дело что если я считаю что программа достаточно хлороша для тех задач которые она решает я не потрачу на нее больше ни секунды времени.

_>У меня тоже есть свои архитектурные решения. И знаешь, я не буду их хвалить. Наоборот, переписываю по частям. Сервер приложения свой фактически. Почему и как — не спрашивай, но задача серьезная. 3 года как занимаюсь, экономический эффект серьезный у нас от этого. Но. Недостатков — валом. Даже больше. Другие есть хвалят. Я — ни за что.
Я вот тоже пишу серверы приложений и тоже прекрасно знаю все недостатки. Другое дело что недостаток недостатку рознь.
Если недостаток серьезный (мешает жить) то приоретет его исправления очень высокий ибо чем дольше он будет оставатся тем сложнее его будет исправить.
Но если недостаток похоронен под кучей абстракций в редко изменяемом коде то и черт с ним. Без него работы хватает.

_>Фигня. Ни жаба, ни С# не дают такого эффекта.
Как вы не любите кошек? Да вы просто не умеете их готовить.
Можешь посмотреть мои сообщения двухлетней давности... я там тоже самое говорил.
_>Эффект дают МЕТОДИКИ.
Вот именно. Дела в том что кроме самих языков и сред выполнения есть еще и средства разработки так вот такие мега рулезы как ReSharper и IDEA очень сильно влияют на процесс разработки.
_>Т.е. тест-драйвен-девелопмент, продумывание на бумажке как у eao197. Ну и просто опыт. А на чем писать — не так важно. Хотя, если конечно это в чем-то сопоставимые языки (я про императивные vs декларативные vs функциональные).
C++ и x86 assembler это императивные языки. Вот только для того чтобы писать на них нужно затричивать очень разное колличество усилий.
С жабой и шарпом по сравнению с С++ тоже самое. Если при работе на С++ мне приходилось отвлекатся на всякие там UB то при работе на C# я об этом не думаю даже подсознательно. Болие того с помощью тогоже ReSharper'а я могу очень быстро менять архитектуру. Да и подходы к самой архитектуре совершенно другие нежели в С++.

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

E>И слава богу. Кто-то занимается драйверами. Кто-то системами кэширования в файловых системах. Кто-то построением оптимальных планов выполнения запросов в СУБД. Кто-то реализацией криптоалгоритмов в смарткартах. И с удовольствием используют знания о стоимости различных операций, полученных в начале карьеры/обучения.

E>Не все же считают, что полезное современное приложение -- это Web-приложение в паре с РСУБД и повсеместным использованием XML.
Да причем тут это? Иван говорил об уневерсальных принципах, а ты опять начал разводить демагогию про ВЕБ приложения.

E>Извини, но звучит это не слишком правдоподобно.
Извени но если ты не работал в таком стиле. Именно раблотал те делал большое и сложное приложение то ты просто не можешь адекватно оценить этот стиль работы. Нельзя говорить о вкусе устриц если ты их не ел.
E>Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня.
Гм?... Я вижу только три причины менять код
1)Исправить баг
2)Изменить алгоритм
3)Изменить архитектуру.
E>Изменить код в C#/Java по сравнению с C++ действительно проще за счет современных IDE и особенностей самих языков (у которых нет стольких неоднозначностей, как в C++).
E>Но вот поменять алгоритм... Мне в свое время довелось в процессе обучения столкнуться с необходимостью смены алгоритма

Автор: eao197
Дата: 29.10.05

. И каждый алгоритм сразу же накладывал свои органичения на всю систему в целом. Например, решение СЛАУ методом Халецкого требовало больше памяти из-за чего размерности СЛАУ приходилось ограничивать. А метод итераций для получения приемлимой точности увеличивал время расчета на несколько порядков. Так что сменить алгоритм -- это может означать серьезный пересмотр требований к задачи и условий ее выполнения. И язык, на котором решение делается, может иметь совсем мизерное значение по сравнению с остальными факторами.
А я бы сделал обобщенный интерфейс и реализовал оба мотода. И дал пользователю (или автопилоту) выберать какой алгоритм решения использовать.
К томуже эта твоя задача скорее исключение из правил.
E>А уж если про смену архитектуры говорить... Ну например, много ли будет значить язык, если какой-нибудь statefull компонент потребуется переделать в stateless?
Много. Ибо придется менять много кода. И тот язык где это сделать легче однозначно в болие выигрошной позиции.

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

PD>Вообще-то зря. Это не в укор тебе и не предложение начать изучать исходники ntfs.sys . Но почитать тех же Соломона — Руссиновича не мешает.
И на том спасибо. Вот например denis_krg считает что это фатальный недостаток и я не могу называтся программистом...
PD>У меня сегодня лекция по спецкурсу. Буду им рассказывать про селекторы, дескрипторы, страничный механизм. Чтобы програмировать на высоком уровне — это даром не надо. Даже про 4Г пространство знать необязательно (пока не припрет . А тем не менее на лекции эти ходят, хотя все спецкурсы у нас выбирают студенты, им нужно лишь требуемое количество набрать, а какие именно — они сами решают. И отменять этот спецкурс я не буду.
PD>А раньше я вел такой же спецкурс по BIOS-MS-DOS. int13h, int 21h, int2fh, Partition Table, BPB, FAT, ... Тоже не то, с чем им в реальной работе приходилось сталкиваться потом. И тоже ходили.
Как очень хорошо в соседнем

Автор: Merle
Дата: 02.03.06

сообщении сказал Иван: Им это интересно вот и ходят.

PD>Если за это же время — тогда да. Но ведь мне доказывали (не говорю ты), что надо сначала прототип сделать, и если выяснится, что он очень медленный, только тогда и улучшать. Что-то мне сдается, что прототип прокси-сервера за 2 дня не сделать... Впрочем, не знаю, я их не писал.
Я тоже не писал прокси серверы. Но это вобщем не суть важно. Важно то что прокси сервер начинают писать сразу без выделеной стадии прототипирования. Дело в том что первый вариант прокси который хоть както заживет и будет прототипом. Причем этот прототип появится очень быстро ибо внимаение на всякие молочи типа производительности на этом этапе не заостряется.
Далие когда прототип зашевилился сразуже начинают вырисовыватся архитектурные косяки. Первым делом исправляеются именно эти косяки при помощи современных IDE код править очень легко так что это процесс идет очень бысто и качественно ибо программисты не боятся менять код. О производительности (если конечно она не настолько низкая что невозможно отлаживатся) всеще никто не думает.
И только после того как не осталось видимых косяков в архитектуре начинают думать о производительносяти и делают это так: Берут в руки профайлер... И так как у нас правильная архитектура (а важнейшее всойство правильной архитектуры это возможность менять как реализации конкретных слоев не затрагиваю соседнии так и частичное изменение самой архитектуры без гемороя) просто начинают переписывать куски системы.

PD>Вот это заявление мне кажется очень важным. В сущности, здесь и определяется основная причина моего подспудного недоверия к этой управляемой среде.
Окружение это в первую очередь базы данных, сеть, ФС итп
PD>На С++ (Pascal, Fortran, Assembler) мы пишем на языке, а делаем машинные коды. Да, конечно, оптимизатор может быть неблестящим. Да, есть много такого, что нам остается неподвластно совсем или частично (WinAPI, FS, ...). Да, есть многопоточность.
Ну в .NET еще и библиотека добавляется. Но чем это отличается от техже библиотек которые подключяются к темже С++ и фортрану.
PD>Но в своем коде — я хозяин.. Что напишу — то и будет выполняться. Не может в моем коде вдруг неизвестно откуда вылезти новый высокоприоритетный поток и отнять время. Не может там быть захвачено больше адресного пространства и коммитировано памяти, чем я захватил и коммитировал. И т.д.
PD>А вот в управляемой среде — может. Может, GC проснется именно в тот момент, когда для меня лучше всего, чтобы он спал и видел третий сон.
А какая разница? Ты что пишешь приложение реального времени? Вот только под виндой это сделать всеравно не получится.
Кстати существуют мусорщики реального времени...
PD>Или, наоборот, я молю , чтобы он проснулся и память почистил, а он спит сном праведника. И т.д.
GC.Collect();...
PD>Фактически мы потеряли полный контроль над свои кодом.
А он у тебя был? Винда в любой мемент может забрать себе все процессорное время или всю память отдать соседнему приложению.
Да и компилятор тоже делает то что хочет.
PD>Эта ситуация не нова — она давно существует в средах программирования, где нет прямой компиляции на машинные коды. В интерпретаторах, проще говоря. В той же FoxPro, к примеру. Там тоже кто-то мусор убирает, потому как иначе нельзя. А когда он это делает — бог его знает.
PD>Вот это мне и не нравится. Ты пишешь — невозможно оценить, как поведет себя окружение.
Реально ГЦ в .НЕТ не смотря на то что не извесно когда он запустится он весьма предсказуем. Если знать как он работает можно настроить алгоритмы так что он будет работать без напрягов.

PD>Поскольку на C# и C++ окружение абсолютно одно и то же, за исключением .Net исполняющей среды, то из этого ясно следует — невозможно оценить поведение именно этой управляемой среды.Не слишком ли это большая плата за удобства этой среды ?
Вот именно то окружение и используемые библиотеки совершенно не предсказуемы.

PD>Поверь мне (и ты, и другие) — я вовсе не имею целью эту среду охаять. Кстати, я уже на С# свой первый проект соорудил и деньги за него получил. Удобно писать, не спорю. Я другое хочу понять — что именно мы отдаем за эти удобства ?
PD>Не слишком ли это большая плата за удобства этой среды ,
Реально мы платим незначительной потерей производительности и некоторым перерасходом памяти. Но со временем разница стирается.

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

WH>>Что-то мне подсказывает что там будут использованы поточные форматы бинарников.
PD>Это будет только если появится поточная форма виртуальной памяти
В таких ОС существуют два типа бинарников.
1)Что-то типа сборки из .NET. Как ты понимаешь ни какого отношения ни к виртуальной ни к какой бы то нибыло еще памяти эти бинарника вобщемто не имеют.
2)Скомпилиные под конкретную машину.(их к сати может и не быть это лишь оптимизация) Эти бинарники содержат код и данные. Также эти бинарники могут ссылатся на другие для того чтобы не дублировать код. Ссылки этих бинарников образуют ацикличный направленный граф. При загрузки такого бинарника сначала грузятся все те бинарники от которых он зависит. Тк при разных запусках бинарники могут быть загруженны по разным адресам нам при загрузке нужно будет скоррекитировать кучу ссылок внутри бинарника. Для этого нам нужно будет либо сделать здоровую таблицу с метаинформацией где и что подкрутить в бинарнике. Либо цинично сериализовать этот и бинарник и просто идти по потоку и при встречи ссылки генерировать нужный код. Что-то типа докомпиляции при загрузке. В принципе оба решения довольно близки по характеристикам но мне почемуто кажется что с сериалзацией проблем будет меньше.

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

WH>>Object -> Serializer -> GzipStream -> EncryptStream -> NetStream -> Net -> NetStream -> DecryptStream -> GzipStream -> Deserializer -> Object
WH>>Самое смешное то что в Object могут быть гигабайты информации но вот эта цепочка этого даже не почувствует ибо она есть O(1) памяти.
PD>С помощью fseek еще много чего нельзя делать. И не надо его совать туда, где он ни при чем — в сетевые потоки.
А сетевые потоки, компрессия и шифровине появились через пол года после того как была реализована сохранение и загрузка из файла...

PD>Кстати, ответь на такой вопрос. А зачем Вам тогда BinaryWriter/Reader ? У него ведь (о ужас!) Seek метод есть. Исключить его, и все дела!
Для тех случаев когда нужно сделать что-то еще кроме сохранения/загрузки данных. Например в томже бинарном diff'е я Seek использовал очень активно ибо этого требовала задача.
А сохранение/загрузка матрици не требует Seek. А если она его не требует то зачем платить больше? А плата это не только память и производительность но еще и архитектура. Как ты передаш матрицу по сети если ты использовал Seek? А вот я сделаю это вобще не напрягаясь. Мое решение прекрасно себя чувствует в условиях сильного изменения требованей к системе, а вот твое... Это я и называю правильной архитектурой.

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

WH>Да причем тут это? Иван говорил об уневерсальных принципах, а ты опять начал разводить демагогию про ВЕБ приложения.

Универсальных принципах, говоришь... Ну покажи мне универсальный приницп вот здесь:

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

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

WH>Гм?... Я вижу только три причины менять код
WH>1)Исправить баг
WH>2)Изменить алгоритм
WH>3)Изменить архитектуру.
0) Улучшить качество кода (рефакторинг).

Ты сейчас говоришь о следствиях. Т.е. решили изменить архитектуру, пришлость править код. Я же говорил о другом. Исправление бага -- это один уровень (возможно самый низкий). Эти исправления могут не затрагивать ни выбранных алгоритмов, ни выбранной архитектуры. Смена алгоритма уже более высокий уровень, но на архитектуре не скажется. И т.д. Так вот, чем выше уровень вносимых изменений, тем меньше влияние языка реализации (имхо).

WH>А я бы сделал обобщенный интерфейс и реализовал оба мотода. И дал пользователю (или автопилоту) выберать какой алгоритм решения использовать.

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

WH>К томуже эта твоя задача скорее исключение из правил.

Из каких правил?
Имхо, здесь собрались люди, представляющие совсем разные области программирования (только вот плотность распределения по областям разная). И в каждой области свои правила действуют.

Вот что мне не нравится, так это то, что представители мейнстримовых направлений (в том числе упомянутых мной web-разработок) распространяют свои правила на все остальные области программирования. Считая при этом, что их взгяд на эффективность является более правильным. И мне нравится, что хотя бы Павел Дворкин упорно привлекает внимание к тому, что это далеко не всегда так.

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

E>И слава богу.
Хм.. Специально не стал писать ни "к счастью", ни "к сожалению" в этой фразе, хотя рука тянулась..

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

E>Извини, но звучит это не слишком правдоподобно. Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня. Изменить код в C#/Java по сравнению с C++ действительно проще за счет современных IDE и особенностей самих языков (у которых нет стольких неоднозначностей, как в C++).
Уровня конечно разного, но любое изменение архитектуры все равно выливается в изменение кода, а менять код в новых языках, как ты сам сказал, проще, следовательно...

E> Например, решение СЛАУ методом Халецкого требовало больше памяти из-за чего размерности СЛАУ приходилось ограничивать. А метод итераций для получения приемлимой точности увеличивал время расчета на несколько порядков. Так что сменить алгоритм -- это может означать серьезный пересмотр требований к задачи и условий ее выполнения.
Ну как бы никто не говорит, что думать не надо. Stateless/stateful, как правило ясно еще на этапе знакомства с ТЗ, благо характеристики и особенности этих конструкций известны. А в остальном новые языки позволяют набросать прототип раньше, не думая о конкретной реализации, подгоняя ее по мере разработки, так как трудоемкость изменения существенно ниже.

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

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

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

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

Например, ты используешь дотнет и TCP-каналы. TCP канал — это очень сложное "соглашение о логике". Но ты не будешь описывать и реализовывать это "соглашение о логике" в своей системе, т.к. канал реализован операционкой и есть конкретный ропер в .Net. Ты просто даешь ссылку в доке на "хорошо известную сущность".

Ведь откуда вообще взялся обсуждаемый критерий? Из опыта разработки и поддержки больших систем и из банального стремления к упрощению этих процессов путем уменьшения кол-ва пунктов технической документации (грубо). Так что, до тех пор пока даже очень сложные технические зависимости не приводят к усложнению ТВОЕГО процесса разработки или поддержки, все ok.

Д>"Качество зависимостей" — это наличие циркулярных зависимостей, например. Относительно небольшое количество таких связей резко увеличивает свзяность всей системы в целом. Например, во втором фреймворке модули System и System.Configuration стали циркулярно зависимы. Нахрена — непонятно

Не знаю насчет "всей системы". Если ты разработчик этих двух сборок, то да, увеличивают сильно. А если ты пользователь (а ты именно пользолватель), то для тебя ничего практически не поменялось (изменения не существенны).

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

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

А почему ты думаешь, что застрял? Может он еще в дороге?

M>Уровня конечно разного, но любое изменение архитектуры все равно выливается в изменение кода, а менять код в новых языках, как ты сам сказал, проще, следовательно...
При серьезных изменениях в архитектуре, имхо, речь будет идти не столько об изменении, сколько о переписывании заново...

M>Ну как бы никто не говорит, что думать не надо. Stateless/stateful, как правило ясно еще на этапе знакомства с ТЗ, благо характеристики и особенности этих конструкций известны. А в остальном новые языки позволяют набросать прототип раньше, не думая о конкретной реализации, подгоняя ее по мере разработки, так как трудоемкость изменения существенно ниже.

Смотря в каких областях. Не везде есть выбор из нескольких языков.

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

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

AVK>Это ты Дворкину скажи:
AVK>

А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.

Мда. Здесь я немного загнул. Дворкин и в самом деле говорил о другом подходе к построению тестов.

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

E>>Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня.
WH>Гм?... Я вижу только три причины менять код
WH>1)Исправить баг
WH>2)Изменить алгоритм
WH>3)Изменить архитектуру.

А "добавить фичу" — это уже не причина изменения кода?

WH>К томуже эта твоя задача скорее исключение из правил.

А какие задачи не являются "исключением из правил"? Огласите весь список, пожалуйста.

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

-1 за это:

ГВ>>А что такое string_length() ?

WH>чтото типа
WH>WH>int string_length(const char* str)
WH>{
WH>    return ((int*)str)[-1];
WH>}
WH>

В общем, я в спор пока не вмешивался, т.к.:
1) согласен с обоими сторонами сразу (все предложенные варианты хороши при их прикладывании по месту)
2) из-за п.1. когда-то написал свою библиотеку строк из 7-ми (!!!) совместимых м/у собой представлений (совместимых по операциям). Два из них были основаны на std::string (char/wchar_t), один на COM BSTR, еще два на стандартной ASCIIZ(char/wchar_t) и еще два на структуре типа этой:

template<typename _E, size_t N>
struct static_string {
        const N size;
        _E buff[N];
};

#define DEF_STR(name, str) static_string<char, sizeof(str)/sizeof(str[0])> name= { sizeof(str)/sizeof(str[0])-1, str }; 

// sample
DEF_STR(str1, "abcd");

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

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

ГВ>Не везде. Всё зависит от условий.
Да везде. Везде.

WH>>Павел много чего говорил вот только в большинстве случаев можно было сделать иначе не потеряв при этом ничего кроме потенциальных неприятностей.
ГВ>В его условиях? Ты уверен?
Процентов на 90. Надо нужно смотреть задачу.

ГВ>Откуда в языке C инлайн-функции? Токмо дефайны.
Ну это ты оптимизаторам скажи.

WH>>Не понял. Зачем это надо. Какую задачу ты решаешь?
ГВ>Например, отправляю строку по сети обычным send(). На начало отправки длина строки неизвестна.
Это как не извесна? У тебя же строка с длинной?

ГВ>Но факта наличия это не отменяет. Выводы из этого можно делать любые.
Вывод один: Какойто оптимизатор недоделанный придумал мега комманды которые будут очень быстро работать со строками... Вот только он не подумал о том что железо меняется и меняется быстро.
Так что теперь эти комманды как и большая часть x86ого камня никому не нужный баласт.
Кстати я нашел еще одну проблему ASCIIZ строк. Их можно копировать только посимвольно. Те на паралельных архитектурах будут прблемы с производительностью по сравнению со строками с длинной.

ГВ>Значит, авторам ASCIIZ количество таких задач не казалось исчезающе малым.
Я думаю они просто не особо долго думали над этим вопросом.

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

ГВ>Это утверждение следует из ваших же посылок о том, что анализировать алгоритмы не нужно. Однако, поскольку лоб не разбит, то значит, всё-таки анализируете? Значит, можно поздравить с "соврамши"?
Никто не говорил что анализировать вобще не нужно. Анализировать не нужно в самом начале когда еще ничего нет ибо это крайне мало эффективно, а вот когда уже есть прототип который хоть както дышит все проблемы вылазят как на ладоне. И вот тут то и начинается анализ. Не раньше. Ибо проблемы вылазят в таких местах о которых никто даже не подозревал те эти проблемы прото не возможно обнаружить при проектировании на бумажке.
К томуже всякие алхимические катализаторы типа ReSharper'а очень сильно ускоряют проверащение не поймешь чего в программный продукт.
Вобщем для того чтобы понять нужно поработать в такм стиле.

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

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

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

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

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

Вообще, проблема в том, что в стандартной библиотеке слишком слабая реализация строки с т.з. архитектуры. Они могли бы представить более гибкий механизм, например выделить отдельную стратегию ХРАНЕНИЯ содержимого строки. То, что сейчас там выделен отдельно всего-лишь аллокатор — не сильно спасает. Например, я написал аллокатор типа такого:

template<typename _E, size-t N>
FixedBuffAllocator 
{
    _E buffer[N];
    
    typedef _E value_type;
    
    [skip]

    pointer allocate(size_t count) {
        if(count>N)
            throw std::out_of_range("FixedBuffAllocator<>::allocate");
            
        return buffer;
    }
    
    size_t maxsize() { return N; }
}

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

Затем, когда я использую этот аллокатор в векторе, все просто чудесно. Я так же чудесно могу использовать этот аллокатор и со строками... но не получаю приличного выигрыша на малых строках для которых это все и предназначено. Ибо многие реализации STL имеют локальный буфер 16 или 32 байта, в которых хранят короткие значения, а нафига мне этот дополнительный локальный буффер, если этот буффер уже содержится в моем аллокаторе?

В общем, к такому сложному вопросу как строки в STL подошли немного в "лоб", в результате чего мы видим то, что видим. А именно — тонны всяких кастомных реализаций С++ строк.

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

Многие ругают С++ за его работу со строками, и есть за что. Не за использование со стандартным аллокатором, разумеется (это первый аргумент только что изучившего STL новичка), а за отсутствие четких представлений о сценариях использования на момент разработки.