есть еще пара подходов «прозрачной» для пользователя регистрации:
1) picamatic.com — они сразу пишут, что вы зарегистрированы =) идея в том регистрация привязывается к вашему компу (чтобы вас не перепутать с другим — ключом выступает значение, навечно лежащее в куках).
не всегда применимо, но шаблоны рвет
2) mybrute.com — у вас сразу спрашивают имя, и после этого вы можете пользоваться ресурсом. если хотите, чтобы эта учетная запись осталась за вами — нажимаете кнопочку «задать пароль».
опять же, не всегда применимо, но для онлайн игрушек, когда не хочется отпугивать пользователя регистрацией — самое то. собственно, это и есть игрушка =)
>1. Множества (как класс в библиотеке) в С# всё-таки есть, и на любой вкус.
Про то, для чего нужно «множество», о котором я написал в этом посте, я написал и комментом выше и в самом посте:
«если где-то нужно передать в качестве аргумента функции несколько флагов»
+
LoadEmployees (ref dsEmployees, EmployeeKind.Coder | EmployeeKind.Manager);
Создавать специально обьект для множества всего лишь для одиночного вызова функции как-то не хочется.
>2. Пишите [Flags] вместо [FlagsAttribute]
спасиб, поправлю =)
Про "<<" Тоже известное «вуду». Просто про него чаще знают те, кто работал с C/C++ =)
А «множества», про которые я говорил, нужны, например, для такого (загрузить из базы список пользователей, определенного вида. например только программистов и менеджеров):
Хороший комментарий. А почему наследоваться от враппера на unmanaged ресурс плохо, и к каким сложностям это приводит, можно понять уже из того, что написано в этой и предыдущей записи.
>касается вообще всего блока внутри «if (manual)»: смысла я не понял. потому что не понял с чего бы это коллектору вызывать какой-то там Dispose у каких-то managed ресурсов. и зачем делить на красных и белых? не диспознуто — диспозай.
пример не придуман, а взят из мсдн. не то что бы мсдн — последняя инстанция, но как «пожелания от MS» пойдет. Я могу только предполагать, зачем было решено разделить освобождение managed и unmanaged ресурсов.
Скорее всего дело тут в следующем. Как только был вызван Dispose из кода программы (а не во время работы сборщика мусора) предполагается «полная и прямо сейчас» очистка всех unmanaged ресурсов. А они могут быть не только в самом классе, но и внутри его managed член-переменных. Ждать, когда для них вызовется GC — не вариант. Поэтому для managed переменных тоже предполагается вызов Dispose — чтобы они тоже могли освободить свои unmanaged ресурсы.
>внимательный легко читатель найдет принципиальные ошибки в коде…
указание на ошибки только приветствуется — это же хорошо когда на них указывают. хуже когда про ошибки не говорят.
>… из-за которых использовать эту мега-идею не получится.
я сам предложенный класс мега-гениальным не считаю. он просто есть и он просто взят из msdn. вариантов его можно предложить разных и много. хуже, лучше — зависит от конкретной ситуации.
>при этом забыть вызвать base.Dispose(..) никто не мешает.
base.Dispose(...) таки забывают, согласен. иногда по забывчивости, а иногда — по не знанию.
>так что — имплементируйте IDisposable, пользуйтесь using, и всем будет хорошо.
С этим никто не спорит. Все верно.
Только я больше о другом: если тебе нужно наследовать от стандартного класса, например System.Windows.Forms.UserControl, то что в этом случае делать? Интерфейс IDisposable уже реализован в предке (на уровне System.ComponentModel.Component).
А очень хочется, чтобы твой контрол работал с unmanaged ресурсами. Например этот контрол должен уметь рендерить при помощи OpenGL и для этого ему надо уметь захватывать контекст устройства. И, соотвественно, уметь корректно его освобождать.
Перекрывать уже существующий метод Dispose — не вариант. И что тогда? Хотя про такое наследование у меня почти ничего и не написано… =(
Напишу следующий пост про наследование и Dispose =)
Но это уже не сегодня.
очень хорошая статья — мне понравилось. никаких обид.
да я и не претендовал на новизну: сразу предупредил что речь всего лишь о пересказе известной информации. просто она, на мой взгляд, представляет некоторый интерес.
вникать — потому что в MS библиотеках так и сделано освобождение ресурсов. И если вы наследуетесь от какого либо класса, который есть в стандартной библиотеке, то должны знать, как вам, как потомку, предполагается освобождать ресурсы.
Извините за капслок, но, блин, я помню еще то время когда рейтрейсеры писались на спектруме, работали в ЧБ и ждать приходилось даже оп часу и больше.
У меня ломка детских стереотипов и вообще когнитивный диссонанс =)
1) picamatic.com — они сразу пишут, что вы зарегистрированы =) идея в том регистрация привязывается к вашему компу (чтобы вас не перепутать с другим — ключом выступает значение, навечно лежащее в куках).
не всегда применимо, но шаблоны рвет
2) mybrute.com — у вас сразу спрашивают имя, и после этого вы можете пользоваться ресурсом. если хотите, чтобы эта учетная запись осталась за вами — нажимаете кнопочку «задать пароль».
опять же, не всегда применимо, но для онлайн игрушек, когда не хочется отпугивать пользователя регистрацией — самое то. собственно, это и есть игрушка =)
собственно пример в посте как раз и демонстрирует эту технику
Про то, для чего нужно «множество», о котором я написал в этом посте, я написал и комментом выше и в самом посте:
«если где-то нужно передать в качестве аргумента функции несколько флагов»
+
LoadEmployees (ref dsEmployees, EmployeeKind.Coder | EmployeeKind.Manager);
Создавать специально обьект для множества всего лишь для одиночного вызова функции как-то не хочется.
>2. Пишите [Flags] вместо [FlagsAttribute]
спасиб, поправлю =)
А «множества», про которые я говорил, нужны, например, для такого (загрузить из базы список пользователей, определенного вида. например только программистов и менеджеров):
LoadEmployees (ref dsEmployees, EmployeeKind.Coder | EmployeeKind.Manager);
пример не придуман, а взят из мсдн. не то что бы мсдн — последняя инстанция, но как «пожелания от MS» пойдет. Я могу только предполагать, зачем было решено разделить освобождение managed и unmanaged ресурсов.
Скорее всего дело тут в следующем. Как только был вызван Dispose из кода программы (а не во время работы сборщика мусора) предполагается «полная и прямо сейчас» очистка всех unmanaged ресурсов. А они могут быть не только в самом классе, но и внутри его managed член-переменных. Ждать, когда для них вызовется GC — не вариант. Поэтому для managed переменных тоже предполагается вызов Dispose — чтобы они тоже могли освободить свои unmanaged ресурсы.
указание на ошибки только приветствуется — это же хорошо когда на них указывают. хуже когда про ошибки не говорят.
>… из-за которых использовать эту мега-идею не получится.
я сам предложенный класс мега-гениальным не считаю. он просто есть и он просто взят из msdn. вариантов его можно предложить разных и много. хуже, лучше — зависит от конкретной ситуации.
>при этом забыть вызвать base.Dispose(..) никто не мешает.
base.Dispose(...) таки забывают, согласен. иногда по забывчивости, а иногда — по не знанию.
>так что — имплементируйте IDisposable, пользуйтесь using, и всем будет хорошо.
С этим никто не спорит. Все верно.
Только я больше о другом: если тебе нужно наследовать от стандартного класса, например System.Windows.Forms.UserControl, то что в этом случае делать? Интерфейс IDisposable уже реализован в предке (на уровне System.ComponentModel.Component).
А очень хочется, чтобы твой контрол работал с unmanaged ресурсами. Например этот контрол должен уметь рендерить при помощи OpenGL и для этого ему надо уметь захватывать контекст устройства. И, соотвественно, уметь корректно его освобождать.
Перекрывать уже существующий метод Dispose — не вариант. И что тогда? Хотя про такое наследование у меня почти ничего и не написано… =(
Напишу следующий пост про наследование и Dispose =)
Но это уже не сегодня.
да я и не претендовал на новизну: сразу предупредил что речь всего лишь о пересказе известной информации. просто она, на мой взгляд, представляет некоторый интерес.