[offtopic]Спасибо. Статья дала повод еще раз порадоваться переходу на .NET, с его юникодом на всех уровнях + IFormatter и CultureInfo соответственно.[/offtopic]
Я еще могу себе представить как этот алгоритм можно использовать в Eve для нахождения точек с самым толстым количеством ресурсов, методом методичного тыка «а ля пчелиный рой», или чего-то в таком духе. Но вот как численный метод поиска глобальных экстремумов может помочь в расчете оптимальной формы фюзеляжа или кузова болида, представляю с трудом. Думается, самая сложная часть в таком деле будет заключаться в составлении многомерной функции, экстремумы которой и надо будет найти, а потом еще и интерпретировать.
Меня вопрос заинтересовал, я сам намучался с рефакторингом классов, реализующих INotifyPropertyChanged «штатным» способом. Пока приемлемого решения мне на ум не приходило.
Эх, что-то у меня сутра с мозгами плохо совсем, [Conditional(«DEBUG»)] спасает первую версию, а версию с выражением — нет. ИМХО подобные накладные расходы в релизной версии никак не оправданы.
А нет, пардон, всё немного не так, код транслируется в такую вот хитрую штуку:
this.OnPropertyChanged<bool>(Expression.Lambda<Func<bool>>(Expression.Property(Expression.Constant(this, typeof(_owner_type)), (MethodInfo) methodof(_ownerType.get_ShowOverrideButton)), new ParameterExpression[0]));
Т.е. всё еще куда более запущено! При каждом вызове создаётся синтаксическое дерево с использованием рефлексии!
[Conditional(«DEBUG»)], конечно, отчасти дело спасает.
Нет, я хочу сказать, что для свойства, значение которого часто меняется, будет сгенерирована тонна мусора, по одному экземпляру Delegate на каждый вызов.
Да, и по поводу DependencyObject — класс не заменим в ситуациях, когда у объекта много свойств, и у большей части экземпляров объектов значения этих свойств устанавливаются по умолчанию. Это даёт солидную экономию памяти. В купе с механизмом наследования значений и присоединенными свойствами, разработчик получает мощные возможности контроля над значениями свойств.
Однако если у класса мало свойств и их значения почти всегда разные, что очень характерно для классов, реализующих логику приложения или модель данных, то DependencyObject — не лучшее решение. Свойства зависимости хранятся вне экземпляров объектов в глобальной хеш-таблице, и само значение свойства занимает гораздо больше памяти, чем необходимо под экземпляр типа свойства. Поэтому использование INotifyPropertyChanged в модели данных — более чем оправдано.
Кроме того, нельзя получить прямой доступ к значению свойства зависимости из потока, которому не принадлежит DispatcherObject, даже на чтение.
Я о таком не слышал. И я даже себе представить не могу, как так можно взять и запретить шифровать содержимое моего диска. Ну, предположим, издали запрещающий закон, а я взял и зашифровал, тогда что? Какое можно назначить наказание?
Тенденция, конечно, печальная. Однако не всё так безнадежно. Пока интернет работает по протоколу IP — он принципиально неуправляем, неподконтролен и нецензурируем. Когда начнутся попытки массовых репрессий — все быстренько «переедут» в криптографические P2P-сети, а правозащитники продолжат охотится за единичными пользователями, не пользующимися криптографией. Ну а по поводу локального хранения информации — я думаю с TrueCrypt'ом все знакомы.
Для того, чтобы установить тотальный контроль за интернетом, необходимо полностью уничтожить его существующую физическую инфраструктуру, и построить новый интернет на оборудовании и протоколах, которые предотвращают P2P связи и туннелирование трафика любого рода. Это должна будет быть централизованная сеть. Никто на такой шаг никогда не пойдет.
Альтернативный маргинальный вариант — считать, что любой передаваемый пользователем трафик, неподдающийся анализу — нелегальный. Задача создания системы анализа пользовательского трафика в реальном времени, при учете практически бесконечного многообразия протоколов — невыполнима, и кроме того незаконна — она нарушает права человека.
Чувствую, не далек тот час, когда в сырых подвалах правоохранительных органов будут пытками добывать пароли от зашифрованных дисков.
Остаётся надеяться, что «борцы за права богатых правообладателей», участники специальной олимпиады для технически неграмотных лицемеров, а ля «я-несу-справедливость-for-the-great-justice, но за бешенное бабло», наконец поймут, что технически невозможно контролировать сегодняшний интернет, и начнут наконец бороться с настоящими преступлениями — повсеместной коррупцией и тотальным разворовыванием бюджета в стиле «распил-откат».
Наверное, если бы структуры в принципе были бы плохими, их бы в .NET не включили. Так что плохи не структуры, а изменяемые структуры, потому, что просто написать код, который делает не то, что хочет разработчик. Эрик Липперт упоминает об этом при первой удобной возможности.
Выводы статьи совершенно некорректны.
1. Все классы структур нужно делать неизменяемыми (immutable).
2. Структуры нужно использовать тогда, когда это удобно.
3. Структуры, передаваемые в методы по ссылке (ключевые слова ref и out) передаются, кто бы мог подумать — по ссылке, а не по значению — копирования не происходит, производительность не страдает.
4. Необходимо соблюдать инкапсуляцию. Если метод класса возвращает некоторый объект, модификация которого затронет состояние экземпляра класса, то класс должен позаботится о предотвращении такой модификации. Например, если требуется вернуть внутренний массив, нужно вернуть Array.AsReadOnly(source) а не сам source.
Это же всё прописные истины ООП, которые верны для любого объектно-ориентированного языка верхнего уровня.
Да по моему в самый раз. 3D-бум практически в разгаре. Все кинулись клепать телевизоры с поддержкой 3D, на PC опять же есть nVidia 3D Vision (со своими болячками, конечно, но куда без них). Так что дело по сути уже только за контентом.
P.S. К сведению для владельцев 3D Vidion — nVidia к слову уже наладила несколько онлайн-трансляций в 3D. Чтобы посмотреть нужен Silverlight 4, свежие дровишки.
P.S. 0 * 25 = 0…
Т.е. всё еще куда более запущено! При каждом вызове создаётся синтаксическое дерево с использованием рефлексии!
[Conditional(«DEBUG»)], конечно, отчасти дело спасает.
Однако если у класса мало свойств и их значения почти всегда разные, что очень характерно для классов, реализующих логику приложения или модель данных, то DependencyObject — не лучшее решение. Свойства зависимости хранятся вне экземпляров объектов в глобальной хеш-таблице, и само значение свойства занимает гораздо больше памяти, чем необходимо под экземпляр типа свойства. Поэтому использование INotifyPropertyChanged в модели данных — более чем оправдано.
Кроме того, нельзя получить прямой доступ к значению свойства зависимости из потока, которому не принадлежит DispatcherObject, даже на чтение.
d.А во вторых, вы понимаете, что каждый вызов приводит к созданию новой копии делегата, передаваемого в качестве параметра?
Для того, чтобы установить тотальный контроль за интернетом, необходимо полностью уничтожить его существующую физическую инфраструктуру, и построить новый интернет на оборудовании и протоколах, которые предотвращают P2P связи и туннелирование трафика любого рода. Это должна будет быть централизованная сеть. Никто на такой шаг никогда не пойдет.
Альтернативный маргинальный вариант — считать, что любой передаваемый пользователем трафик, неподдающийся анализу — нелегальный. Задача создания системы анализа пользовательского трафика в реальном времени, при учете практически бесконечного многообразия протоколов — невыполнима, и кроме того незаконна — она нарушает права человека.
Чувствую, не далек тот час, когда в сырых подвалах правоохранительных органов будут пытками добывать пароли от зашифрованных дисков.
Остаётся надеяться, что «борцы за права богатых правообладателей», участники специальной олимпиады для технически неграмотных лицемеров, а ля «я-несу-справедливость-for-the-great-justice, но за бешенное бабло», наконец поймут, что технически невозможно контролировать сегодняшний интернет, и начнут наконец бороться с настоящими преступлениями — повсеместной коррупцией и тотальным разворовыванием бюджета в стиле «распил-откат».
Выводы статьи совершенно некорректны.
1. Все классы структур нужно делать неизменяемыми (immutable).
2. Структуры нужно использовать тогда, когда это удобно.
3. Структуры, передаваемые в методы по ссылке (ключевые слова ref и out) передаются, кто бы мог подумать — по ссылке, а не по значению — копирования не происходит, производительность не страдает.
4. Необходимо соблюдать инкапсуляцию. Если метод класса возвращает некоторый объект, модификация которого затронет состояние экземпляра класса, то класс должен позаботится о предотвращении такой модификации. Например, если требуется вернуть внутренний массив, нужно вернуть Array.AsReadOnly(source) а не сам source.
Это же всё прописные истины ООП, которые верны для любого объектно-ориентированного языка верхнего уровня.
P.S. К сведению для владельцев 3D Vidion — nVidia к слову уже наладила несколько онлайн-трансляций в 3D. Чтобы посмотреть нужен Silverlight 4, свежие дровишки.