Pull to refresh
4
0
Deranged @Deranged

User

Send message
Эх, что-то у меня сутра с мозгами плохо совсем, [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»)], конечно, отчасти дело спасает.
Сейчас, что бы было совсем понятно, код

this.OnPropertyChanged(() => this.ShowOverrideButton);
полностью аналогичен коду

this.OnPropertyChanged(new Expression<Func<_type>>(new Func<_type>(() => this.ShowOverrideButton)));
, где _type — тип свойства.
Нет, я хочу сказать, что для свойства, значение которого часто меняется, будет сгенерирована тонна мусора, по одному экземпляру Delegate на каждый вызов.
Да, и по поводу DependencyObject — класс не заменим в ситуациях, когда у объекта много свойств, и у большей части экземпляров объектов значения этих свойств устанавливаются по умолчанию. Это даёт солидную экономию памяти. В купе с механизмом наследования значений и присоединенными свойствами, разработчик получает мощные возможности контроля над значениями свойств.
Однако если у класса мало свойств и их значения почти всегда разные, что очень характерно для классов, реализующих логику приложения или модель данных, то DependencyObject — не лучшее решение. Свойства зависимости хранятся вне экземпляров объектов в глобальной хеш-таблице, и само значение свойства занимает гораздо больше памяти, чем необходимо под экземпляр типа свойства. Поэтому использование INotifyPropertyChanged в модели данных — более чем оправдано.
Кроме того, нельзя получить прямой доступ к значению свойства зависимости из потока, которому не принадлежит DispatcherObject, даже на чтение.
Для начала поправьте заголовок поста, имя события — OnPropertyChanged.
А во вторых, вы понимаете, что каждый вызов

this.OnPropertyChanged(() => this.ShowOverrideButton);
приводит к созданию новой копии делегата, передаваемого в качестве параметра?
Интересно, сколько «хакеров» уже обломалось при попытке оплатить что-нибудь онлайн по указанным в скриншоте реквизитам, в порыве «омгхялява!!!1»? :)
Ровно в тех же ситуациях, что и в любом языке высокого уровня с поддержкой структур по значению. На C++ или на Pascal/Delphi писали?
Я о таком не слышал. И я даже себе представить не могу, как так можно взять и запретить шифровать содержимое моего диска. Ну, предположим, издали запрещающий закон, а я взял и зашифровал, тогда что? Какое можно назначить наказание?
Тенденция, конечно, печальная. Однако не всё так безнадежно. Пока интернет работает по протоколу 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, свежие дровишки.
Осталось допилить сервис совсем чуть чуть — дать возможность покупать право на просмотр фильма на неограниченный срок и улучшить функциональность плеера до уровня «обычного» видеоплеера, добавить поддержку 3D. По моему очень удобно иметь фильмотеку на удаленном сервере. Не надо тратить собственное дисковое место или болванки, данные никогда не потеряются. В дальнейшем возможен автоматический «апгрейд» форматов фильмов. Например уже сейчас доступны 3D-стерео фильмы. Опять же отсутствие траха с форматами контейнеров и глюками кодеков — отличный плюс.
Так же как, собственно, и приборка. Нормальные люди «клеят» навигаторы на лобовое стекло.
Виртуаьная машина не прокатит. Сейчас в винде и так введена концепция виртуализации устройств. От дедлоков это не спасает.
Фреймворк этим заниматься не может в принципе без большущего и сложненного драйвера режимя ядра, который бы перехватывал и редиспетчеризировал все системные вызовы обращений к обьектам ядра и строил бы граф зависимостей по потокам, да еще и управлял бы им. Еще нужно не забывать про вытесняющую многозадачность. При том бы 50% процессорного времени уходило бы на работу этого драйвера. Т.к. фактически любая операция ввода-вывода сопряжена с некоторым объектом ядра...
Ну на счет стека... Брать указатели на стековые переменные и передавать их во вне без приостановки потока любят начиающие программисты. Тот, кто понимает как всё работает, так никогда не поступит.
А по другому не выйдет. Либо ядро ОС видит весь граф принадлежности обьектов потокам и зависимостей, либо этим занимается программист...
Думаю что в существующих ОС напрямую от потоков отказаться не выйдет. Для этого нужно целиком менять всю концепцию ОС. И фреймворком тут не отделаешься... Нужно делать .NET OS.
>Почему-то все забывают про процессы. Это гораздо более удобный метод
>организации многозадачной обработки, чем нити. И гораздо более
>эффективный в реализации в ядре операционной системы. У процессов много
>достоинств, а единственный недостаток - это сложность переключения
>контекста виртуальной памяти. Но в нормальных процессорах поддержка уже
>давным давно сделана на аппаратном уровне через идентификаторы
>виртуальных адресных пространств. На ненормальных, то есть, производных
>от x86, проблема решается через хитрые кэши первого уровня.
Бред вы полный написали. Процессы не исполняются. Процесс - среда для потоков. Процесс жив до тех пор пока в нем есть хотя бы один поток. Не надо забывать, что контест процесса удовольствие дорогое, намного более дорогое чем контекст потока.

>Процессы снимают проблему со стеками и со сборкой мусора, вполне
>естественным образом: стеки различны, а при завершении процесса все
>занимаемые ресурсы можно освободить.
Чего за бред про стеки? У каждого потока свой стек (под виндой даже 2). С этим проблем никаких нет.

Товарищи! Ну кто вам сказал, что в современных ЯВУ нет средств неявного обращения с потоками? Для примера возьмем C#. Вводится понятие пула потоков. Для каждого процесса создается пул рабочих потоков. Причем обращение к ним происходит неявно, посредством вызова Delegate.BeginInvoke/EndInvoke. Подробней читаем тут:
http://www.codeproject.com/csharp/AsyncMethodInvocation.asp
Такая концепция коренным образом отлична от классической. В классической модели программист явно указывает набор комманд, и поток в котором этот набор должен выполняться. Такой подход противоречит самой идее масштабируемости приложения под любое число ядер. Напротив, в концепции с пулом потоков, заранее не предопределено в каком потоке будет выполняться та, или иная подпрограмма. Есть один или несколько "главных" потоков, которые раздают некоторому множеству "рабочих" потоков очереди заявок на выполнение операций. Такой подход хорош во всем. Скажем если ядра в процессоре 2, то нет смысла держать больше 2х рабочих потоков. А если 16, то есть и еще какой.
Теперь про классический Win32 и C++. В самом языке С++ нет встроенных конструкций организации пула потоков. Однако WinAPI предоставляют подмножество функций user-mode APC (Asynchronous Procedure Calling) для задания очереди асинронных операций для потока. Используя APC, можно создать пул потоков без каких либо затруднений. Именно на этой концепции и держится часть механизма обработки прерываний - DPC - суть тот же APC, толко режима ядра и при повышенном IRQL.
Однако никакие концепции и абстракции не решат проблему синхронизации доступа к ресурсам и исключения взаимоблокировок. Конечно можно разработать общий способ, как например в C# ключевое слово lock(...). Однако всё равно компилятор никогда сам не определит точные блоки кода, на которые надо ставить блокировку, т.е. критические секции сам не расставит. Это оочень интеллектуальная задача. Можно конечно лочить всё подрад, но производительность в таком случае упадет капитально. Всё равно синхронизацию должен будет определять программист.
12 ...
39

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Software Developer, Software Architect
From 4,000 $
Git
.NET
Designing application architecture
C++
Qt
QML
WPF
Visual Studio
C#
Software development