> А что скажете про двоеточие после имени входного параметра?
Аболютно стандартная нотация, общепринятая в литературе по computer science, языкам программирования, теории типов; используется во многих современных ЯП. Это *не* «как в Дельфи/Паскале», это «как везде кроме Си-подобных языков».
Да я знаю, что тут происходит, это был риторический вопрос. Просто то, что я наблюдаю в оnладчике и в консоли, никак не могу назвать «тип `byte` присутствует там с момента появления языка». Даже в C# перемалывать байты приятнее, чем в языке системного программирования C++.
> возвращают не значение, а специальную обертку вокруг него, называемую обещанием («promise») или задачей («task»).
Обычно немного не так. Promise (≈ TaskCompletionSource) асинхронная операция оставляет себе. А отдаёт соответствующий Future (≈ Task), который является, грубо говоря, read-only view для обещания.
> Поэтому рано или поздно возникает вопрос, почему с их помощью нельзя возрождать других ключевых персонажей, и почему противники не могут делать то же самое.
Противники в Borderlands 2 как раз могут: убитые боссы оказываются на своих местах при повторном попадании персонажа игрока в пройденные локации.
А невоскрешение Роланда — да, ломает всю идею.
Непонятно, чем автор объясняет отсутствие упоминания игр серии GTA в статье про механику смерти.
Помогает даже не название, а цвет. В GUI для Hg (SourceTree, например) можно проскользить взглядом вдоль линии одного цвета — охватишь взглядом все коммиты, сделанные в рамках работы над конкретной фичей. В том же SourceTree для Git цвета натурально не несут ни малейшего смысла. Скользя вниз по ветке какого-то цвета будешь спотыкаться об слияния, после чего надо пытаться понять, по какой родительской дуге надо продолжать движение.
> Куча просто придуманных слов, которые ни ассоциативно понять не получается, ни из контекста
Большинство понятий имеют аналоги в нашем мире, с ними ассоциируются, и из контекста извлекаемы:
теорема Адрахонеса — теорема Пифагора,
плитки теглона — мозаика Пенроуза,
Гилеин теорический мир — мир идей Платона,
весы Гардана — бритва Оккама,
и т. д.
>>> А что плохого в одинаковых хешах кроме упомянутой уже возможности вскрытия с помощью радужных таблиц?
Если злоумышленник знает, что у пользователей john.doe и jackie.brown одинаковые несолёные хэши, то будет уверен, что пароль от пользователя jackie.brown будет подходить к пользователю john.doe. (При этом не обязательно сами пароли будут совпадать, если мы имеем дело с коллизей; и это неважно.) Злоумышленник пойдёт к jackie.brown и купит её пароль за небольшие деньги — ей ведь ничего не стоит раскрыть свой работающий пароль и тут же его сменить на новый, чтоб покупатель старого пароля не имел доступ к её аккаунту. Таким образом в результате злоумышленник будет иметь доступ к аккаунту john.doe, используя для той или иной атаки чужой более уязвимый аккаунт с совпадающим хэшем. Или даже шуточный «терморектальный криптоанализ». Если его применить к john.doe и выпытать пароль, то john.doe всё-таки будет знать, что его пароль скомпрометирован. Но jackie.brown при этом не будет знать, что её конфиденциальность под угрозой. То есть с помощью пыток и криптографической дыры в безопасности можно добиться существенно больше, чем только с помощью пыток.
AES есть, да и всякое другое: msdn.microsoft.com/ru-ru/library/System.Security.Cryptography(v=vs.140).aspx.
>>> «Хэши солят» только для того чтобы противостоять подбору по радужным талицам
Хэши солят ещё и для того, чтобы одинаковые пользовательские пароли имели разные хэши.
>>> В том смысле что это частный случай CBC. В более общем смысле IV это скорее некоторое расширение ключа.
Не свовсем. Это расширение секретного ключа публично передаваемым куском.
>>> «IV — initialization vector (вектор инициализации). Нужен для подачи на вход шифрования первого блока.» — Нинужен!
Нужен. Позволяет избежать replay attacks, если в протоколе обеспечена постоянная смена IV. То есть злоумышленник (даже не понимая зашифрованного сообщения) не сможет организовать его повторную отправку — адресат будет отвергать повторные IV.
>>> Для правильного решения задачи нужно объявить отдельный метод, поместить в него установку IsModified и использовать в качестве обработчика, как всегда и делалось до появления лямбда-выражений в C#.
До появления лямбда-выражений в C# уже существовали замыкания, хоть и в другом синтаксисе. Если использовать отдельный метод, то не получится замкнуть «локальные» переменные метода.
Нам не нужно «помнить» метод, чтобы от него отписаться в Dispose(). Мы определяем отписку сразу же при подписывании лямбдой, просто откладываем её на потом.
В исходном блог-посте был упомянут Target Framework Moniker: «You can now use DNX to build portable .NET libraries that work on any .NET flavor that supports your package dependencies using the new dotnet TFM.» Можешь как-то прокомментировать?
> можно сделать чуть-более конструктивной и менее эмоциональной
Насчёт конструктивности: я ответственно подхожу к комментариям, не ленюсь их обильно снабжать фрагментами (псевдо)кода и приводить ссылки, даже если иногда хочется по-быстрому слабать коммент за две минуты с вопросами/ответами на пальцах. Что касается эмоциональности — я на этом форуме уже почти восемь лет, а Тепляков и того больше; немного фамильярности кашу не испортит.
А в чём логика? Почему для порядка нот «ля—си—до—ре—ми...» в последовательность «A—?—C—D—E...» вместо «?» нужно ставить «H», а не «B»?
Мне кажется, долг сознательного гражданина — по мере сил бойкотировать сложившуюся вопиюще иррациональную систему.
Почему не применяют в армии?
Строго говоря, Vector и Point — это разные типы данных (даже если одинаковые структуры данных).
Аболютно стандартная нотация, общепринятая в литературе по computer science, языкам программирования, теории типов; используется во многих современных ЯП. Это *не* «как в Дельфи/Паскале», это «как везде кроме Си-подобных языков».
std::uint8_t const b = 0xC9;
std::cout << b << std::endl;
unsigned char const b = 0xC9;
std::cout << b << std::endl;
Обычно немного не так. Promise (≈ TaskCompletionSource) асинхронная операция оставляет себе. А отдаёт соответствующий Future (≈ Task), который является, грубо говоря, read-only view для обещания.
Противники в Borderlands 2 как раз могут: убитые боссы оказываются на своих местах при повторном попадании персонажа игрока в пройденные локации.
А невоскрешение Роланда — да, ломает всю идею.
Непонятно, чем автор объясняет отсутствие упоминания игр серии GTA в статье про механику смерти.
Помогает даже не название, а цвет. В GUI для Hg (SourceTree, например) можно проскользить взглядом вдоль линии одного цвета — охватишь взглядом все коммиты, сделанные в рамках работы над конкретной фичей. В том же SourceTree для Git цвета натурально не несут ни малейшего смысла. Скользя вниз по ветке какого-то цвета будешь спотыкаться об слияния, после чего надо пытаться понять, по какой родительской дуге надо продолжать движение.
Большинство понятий имеют аналоги в нашем мире, с ними ассоциируются, и из контекста извлекаемы:
теорема Адрахонеса — теорема Пифагора,
плитки теглона — мозаика Пенроуза,
Гилеин теорический мир — мир идей Платона,
весы Гардана — бритва Оккама,
и т. д.
Если злоумышленник знает, что у пользователей john.doe и jackie.brown одинаковые несолёные хэши, то будет уверен, что пароль от пользователя jackie.brown будет подходить к пользователю john.doe. (При этом не обязательно сами пароли будут совпадать, если мы имеем дело с коллизей; и это неважно.) Злоумышленник пойдёт к jackie.brown и купит её пароль за небольшие деньги — ей ведь ничего не стоит раскрыть свой работающий пароль и тут же его сменить на новый, чтоб покупатель старого пароля не имел доступ к её аккаунту. Таким образом в результате злоумышленник будет иметь доступ к аккаунту john.doe, используя для той или иной атаки чужой более уязвимый аккаунт с совпадающим хэшем. Или даже шуточный «терморектальный криптоанализ». Если его применить к john.doe и выпытать пароль, то john.doe всё-таки будет знать, что его пароль скомпрометирован. Но jackie.brown при этом не будет знать, что её конфиденциальность под угрозой. То есть с помощью пыток и криптографической дыры в безопасности можно добиться существенно больше, чем только с помощью пыток.
AES есть, да и всякое другое: msdn.microsoft.com/ru-ru/library/System.Security.Cryptography(v=vs.140).aspx.
>>> «Хэши солят» только для того чтобы противостоять подбору по радужным талицам
Хэши солят ещё и для того, чтобы одинаковые пользовательские пароли имели разные хэши.
>>> В том смысле что это частный случай CBC. В более общем смысле IV это скорее некоторое расширение ключа.
Не свовсем. Это расширение секретного ключа публично передаваемым куском.
>>> «IV — initialization vector (вектор инициализации). Нужен для подачи на вход шифрования первого блока.» — Нинужен!
Нужен. Позволяет избежать replay attacks, если в протоколе обеспечена постоянная смена IV. То есть злоумышленник (даже не понимая зашифрованного сообщения) не сможет организовать его повторную отправку — адресат будет отвергать повторные IV.
До появления лямбда-выражений в C# уже существовали замыкания, хоть и в другом синтаксисе. Если использовать отдельный метод, то не получится замкнуть «локальные» переменные метода.
Можно делать примерно так так:
PropertyChangedEventHandler handler = (sender, e) => { /* Capturing some local variables. */ };
Entity.PropertyChanged += handler;
IDisposable subscriptionToken = Disposable.Create(() => { Entity.PropertyChanged -= handler; });
_compositeDisposable.Add(subscriptionToken);
Нам не нужно «помнить» метод, чтобы от него отписаться в Dispose(). Мы определяем отписку сразу же при подписывании лямбдой, просто откладываем её на потом.
Насчёт конструктивности: я ответственно подхожу к комментариям, не ленюсь их обильно снабжать фрагментами (псевдо)кода и приводить ссылки, даже если иногда хочется по-быстрому слабать коммент за две минуты с вопросами/ответами на пальцах. Что касается эмоциональности — я на этом форуме уже почти восемь лет, а Тепляков и того больше; немного фамильярности кашу не испортит.