Я считал, что компилятор (или же CLR) сможет понять, что так как внутри цикла мы не изменяем переменную s, то значение s.Length будет получено только один раз.
Дело в том, что это не локальная переменная внутри функции (жизненный цикл которой JIT-компилятор может отследить), а проперти стороннего объекта. JIT-компилятор не может гарантировать, что значение, возвращаемое этим свойством (по сути являющимся вызовом метода) не изменится на следующей итерации цикла (вдруг другой поток его меняет, или код внутри цикла неявно взаимодействует с тем объектом ?). Поэтому естественно, что нужно кешировать такие вещи в локальной переменной вручную.
SOAP хорош для гомогенных сред (Java — Java, .NET — .NET), в других же случаях маршаллинг сложных объектов не работает, и приходится заниматься всякими извращениями, как то перевод HashMap в массив MapEntry и так далее. В сухом остатке остается возможность маршаллить примитивы (строки, целые числа, массивы) и объектики, составленные из этих примитивов. По-моему, возня с WSDL и проблемы с обновлением серверной части не стоит этого. Куда лучше, на мой взгляд, сделать простейший интерфейс на HTTP запросах, который принимает и возвращает JSON / XML. И задокументировать методы вручную в коде и на викистраничке проекта.
Это не совсем правда — в индексе в действительности новый файл не создаётся. В противном случае вес репозитория увеличивался бы как минимум на размер переименованного файла. Но это не так.
Нет. Git отслеживает изменения _содержимого_ файлов, а не сами файлы. Вы можете скопировать файл 10 раз, и это не приведет к увеличению репозитория, в котором однажды этот файл был проиндексирован. Будут лишь созданы ссылки на ранее сохраненный объект, идентифицируемый хешем от содержимого файла. С удалением файла и последующим добавлением — та же самая ситуация (поскольку из истории объект не удалялся, при повторном добавлении его в репозиторий будет лишь создана ссылка на старый объект).
Непонимаю минусующих. По-моему, отличный пост-рецепт, будет полезен многим. Новости какие-то плюсуем стабильно, а вот такое — частенько в минуса уходит. Снобизм-с?
Неплохо, но в этом конкретном случае имхо проще сделать свой поток, который просто будет ожидать поступления новых элементов. А чтобы поток не крутился в вечном цикле, управлять им при помощи EventWaitHandle. Остановка потока производится аналогично, — устанавливаем isStopped в true и вызываем waitHandle.Set(). Поток просыпается и понимает, что ему приказано умереть. Этот подход прост и более универсален, поскольку не требует зависимости от WPF.
Взломщик, получив 2 таблицы, может сделать из таблицы хешей компактную свертку (прохешировав хеши простой хеш-функцией (скажем 32битной) и проставив на всем 32битном пространстве флаги 1 или 0). И после этого перебор будет делать так: брать юзера, пробовать на нем очередное слово из словаря, хешировать с солью, и проверять наличие в базе, НО перед этим выполняя проверку на наличие в свертке (то есть выполнив еще 1 раз хеширование простой хеш-функцией и сравнив флаг с единицей — если найдена единица, то лезем в базу и уже проверяем наличие, если 0 — переходим к след. проверяемому паролю). Таким образом можно ускорить перебор, практически не выполняя обращений к базе. Необходимо лишь первично прогнать таблицу с хешами и сделать в памяти хеш-таблицу свертки.
Что ж в этом плохого? Как раз за гибридными вещами будущее и есть. Никто не будет писать десктопные приложения на чистом функциональном языке. Программистам хочется делать не только функциональные абстракции, но еще и абстракции объектов, хранящих состояние. А уж чего больше в MVC и databinding'ах — ООП или функциональщины — это еще вопрос :) Реактивное программирование, судя по вики, к функциональному программированию не относится и является обособленной парадигмой, которую использует и ООП, и ФП. Выделение минимально необходимого это не есть изобретение ФП, это перифраз бритвы Оккама, методологического принципа, используемого повсеместно.
Где-то функциональный подход рулит (алгоритмы обработки потоковых данных к примеру, которые должны хорошо масштабироваться на N тредов и никакого состояния внутри особо не содержать). А есть сложные десктопные приложения, где состояние — это основное, и нужны какие-то абстракции, чтобы хранить это состояние. Не представляю себе WPF, реализованный в функциональном стиле. ООП просто сложнее приготовить правильно (зато проще сделать неправильно), это и приводит к тому, что библиотеки точатся и допиливаются годами, добиваясь смысловой целостности абстракций.
А как хуже-то? Повторно будет писаться в лог о том, что произошла ошибка? Или повторный try-finally приведет к деградации производительности? По сравнению с тем фактом, что *синглетон не удалось инстанцировать из-за исключения в конструкторе*, проблемы такого рода представляются мне малозначимыми :)
Хитро, конечно, придумано, возьму на заметку. Хотя, мне кажется, что идиома синглетона рушится таким подходом — ведь когда видят синглетон, справедливо полагают, что он должен конструироваться один раз. А тут вот так вычурно — не всем такой способ подойдет. Да и код с первого взгляда не понятен — кажется, что в нем допущена ошибка, и руки тянутся вписать блокировку :)
На мой взгляд, внутри double-checked-lock'а (раз уж поток зашел внутрь) уже нет смысла экономить на спичках, поскольку этот код выполняется 1 раз за всю жизнь приложения, ну может быть 2 раза у самых-самых везучих.
Вообще, я лично остановился на double checked locking синглетонах. Если уж мне нужно сделать синглетон, и если он должен быть потокобезопасным — я как правило выбираю либо этот способ, либо просто статическое поле, инициализируемое в статическом же конструкторе (это если мне вообще без разницы, когда будет создан синглетон — ленивость не нужна). Все остальные способы либо страдают чем-то, либо зависят от деталей того, как рантайм или компилятор обрабатывают всякие тонкие моменты типа порядка инициализации статических переменных, beforefieldinit итд, либо чересчур сложны для решаемой задачи (черт возьми, ведь мне всего-навсего нужен долбанный синглетон! мне не хочется использовать для этого нюансы конкретно используемого языка). Про это вы как раз очень в точку отметили:
Почему нехорошо «обманывать» язык? Потому что каждый такой «хак» очень легко нечаянно поломать. И потому что от него нет никакой пользы людям, которые пишут на других языках — а ведь паттерн предполагает универсальность.
С производительностью у DCL тоже все в порядке — он проигрывает самым оптимально написанным синглетонам сущие копейки. Поэтому мой выбор — DCL, пусть он и не самый «идеальный» вариант с точки зрения перфекционистов.
Знаете, я частенько обдумываю эту мысль, и пока пришел к выводу, что творчество и изобретательность обратно пропорциональны количеству доступных возможностей. Вспоминая себя в детстве, когда я на диалаповом модеме просиживал на wasm.ru и пытался выкачать инструменты на скорости 2-3 кбайта в секунду, и с каким рвением я тогда этим занимался, зачитывая до дыр книжки типа C++ for real programmers или Turbo pascal 6.0. А сейчас как-то лениво стало. Но если меня посадить в пустую комнату в которой есть только компьютер без интернета и компилятор, я уверен, что живо что-нибудь сделаю, все равно больше делать нечего. Поэтому я уверен, что в современном мире именно умение искуственного самоограничения, и достижения тем самым высокой концентрации, — будет самым важным инструментом для глубокого творчества.
Дело в том, что это не локальная переменная внутри функции (жизненный цикл которой JIT-компилятор может отследить), а проперти стороннего объекта. JIT-компилятор не может гарантировать, что значение, возвращаемое этим свойством (по сути являющимся вызовом метода) не изменится на следующей итерации цикла (вдруг другой поток его меняет, или код внутри цикла неявно взаимодействует с тем объектом ?). Поэтому естественно, что нужно кешировать такие вещи в локальной переменной вручную.
Нет. Git отслеживает изменения _содержимого_ файлов, а не сами файлы. Вы можете скопировать файл 10 раз, и это не приведет к увеличению репозитория, в котором однажды этот файл был проиндексирован. Будут лишь созданы ссылки на ранее сохраненный объект, идентифицируемый хешем от содержимого файла. С удалением файла и последующим добавлением — та же самая ситуация (поскольку из истории объект не удалялся, при повторном добавлении его в репозиторий будет лишь создана ссылка на старый объект).
С производительностью у DCL тоже все в порядке — он проигрывает самым оптимально написанным синглетонам сущие копейки. Поэтому мой выбор — DCL, пусть он и не самый «идеальный» вариант с точки зрения перфекционистов.
?
А подскажите плз, чем VM отличается от VZ? На сайте всё одинаково кроме габаритов:
www.asus.com/Notebooks/Multimedia_Entertainment/N56VM/
www.asus.com/Notebooks/Multimedia_Entertainment/N56VZ/
Цены бы не было.