В статье, помимо тега, упоминания о LXDE нету, а жаль. Сбежал на него с Unity 3D\2D, которые дико тормозили на моем стареньком нетбуке и отжирали большую часть оперативной памяти (а у меня ее 2Гб), не давая открыть более 3 вкладок любого браузера. С LXDE открыт хромиум с несколькими вкладками, пиджин, скайптаб и монодевелоп — ничего не тормозит (огромное спасибо kekekeks за последние две проги). Программы, если лениво тянуться до мыши (или искать в меню), запускаю через Ctrl+Alt+T -> programname & exit
Я так понял, что он не только про методы говорит, а про свойства также например, на них действительно нельзя сделать ссылки без создания делегатов, которые возвращали бы их значения. А ссылка на оригинал есть в стандартном месте (не знаю как точно называется, панель под статьей).
Проходил на клаве нормально вертолеты, без напряга. В VC самое сложное было для меня — миссия, где флаеры с самолета нужно сбрасывать — чертыхался с клавой. С другой стороны: GTA:SA на клаве проходил норм, а когда перепроходил на геймпаде — не смог попасть из базуки в вертолет на ходу, плюнул и прошел эту часть на клаве. Saints Row 3 весь проходил на клаве — самолеты были удобные. Думаю, что по настоящему мало вещей, которые удобнее на геймпадах. Часто дело лишь в кривом портировании на клавиатуру + мышь. И да, я проходил THPS4 на клаве на 100% — никаких проблем.
Не очень вас понимаю. В статье написано, что все делегаты могут иметь произвольное количество ссылок на методы. Это не одно ли и то же, что они все — multicast? В любом случае теперь эти слова есть в комментариях.
Мне кажется, что часто имеют в виду, что порядок подписки не может быть гарантирован. Во-первых, в большинстве случаев, когда подписчиков более 1-2, становится сложно проследить и гарантировать логический порядок подписки (особенно если они отписываются и снова подписываются в процессе работы). А во-вторых, в многопоточном окружении мы не можем знать, какой поток первым осуществит подписку.
Я бы не стал использовать эту особенность даже для простых случаев — такие порой становятся сложнее, а править «хаки» в них забывают. Не говоря уже о приятной отладке для других членов команды.
и еще — такой вопрос уже задавался команде разработчиков C#. Ответом было «мы не можем изменить имеющийся синтаксис вызова события через делегат, т.к. на это могли повязаться. Получается, что для решения этой проблемы нужно добавлять такую возможность к языку.» Также там было написано, что хотели сделать ключевое слово для вызова, но после обсуждения отказались от этой идеи.
> Если вдруг список подписчиков на события опустел — это вызовет фатальную ошибку при отправке им события?
Подписчиками являются непосредственно методы, и при «отправке им события» мы вызываем все методы по порядку. Соответственно когда список методов пуст, есть два пути: не делать ничего или вызвать исключительную ситуацию. Второе обычно лучше, вызывает меньше непонимания в процессе отладки. Хуже, когда какие-то ошибки «проглатываются».
И вообще, делегат используется не только в механизме событий и отсутствие «ссылки на метод» как-то иначе кроме как пустой ссылкой показывать странно.
Я бы не стал использовать эту особенность даже для простых случаев — такие порой становятся сложнее, а править «хаки» в них забывают. Не говоря уже о приятной отладке для других членов команды.
Подписчиками являются непосредственно методы, и при «отправке им события» мы вызываем все методы по порядку. Соответственно когда список методов пуст, есть два пути: не делать ничего или вызвать исключительную ситуацию. Второе обычно лучше, вызывает меньше непонимания в процессе отладки. Хуже, когда какие-то ошибки «проглатываются».
И вообще, делегат используется не только в механизме событий и отсутствие «ссылки на метод» как-то иначе кроме как пустой ссылкой показывать странно.