Поэтому у StreamWriter есть параметр в конструкторе, чтобы стрим извне не освобождался при Dispose у StreamWriter. И то и то поведение нужное и полезное, поэтому дан выбор. Не понятно, к чему пример конкретно с ним.
Прикол тут в том, что на той же ps4 у меня выбран регион РФ, но язык английский. В итоге магазин у меня РФ, а игры идут на английской локализации. На xbox one такое сделать невозможно. Было бы на нем тоже самое, то и выбор в настройках не нужен был бы. А вот проблем издателя — вполне. Как говорят MS, данная особенность xbox one тоже не решается в один присест.
Не знаю, насколько это сюда подходит, но очень хорошим советом было бы давать возможность выбрать язык субтитров. Конкретно у xbox one есть одна неприятная особенность — доступные на выбор языки интерфейса привязаны к региону консоли. Выбрать регион РФ и английский интерфейс просто не получится, а вот играть с оригинальной озвучкой очень бы хотелось. Поэтому всегда радуют игры, которые имеют настройки языка субтитров и озвучки.
А так, дельные советы. У ААА разработчиков в основном проблем с этим нет. Сейчас как раз играю в rise of the tomb raider — достаточный размер шрифта для телевизора, контраст достигается цветом текста и плашкой позади него, реплики разных героев можно окрасить в разный цвет. Ну и язык в настройках тоже настраивается, уж здесь точно хочется слышать оригинал в лице Камиллы Ладдингтон.
Очень радует, что в отличие от obj-c в Swift можно в расширении класса MyViewController указать новые наследуемые протоколы и реализовать их поведение.
Учитывая, что эти расширения, суть, симбиоз протоколов и категорий, все это в obj-c можно делать. Протоколы наследуют протоколы. Категории наследуют и реализуют протоколы.
Выглядит забавно и любопытно, но, честно, никогда не сталкивался с необходимостью расширений, которые не привязаны к какому-то типу. Больше похоже на синтаксический сахар для helper-функций и методов. Называть это прям какой-то новой парадигмой protocol-oriented язык не поворачивается
Документация — для пользователей (Documentation is for users)
Документация для программистов, а посему, запилите мне, пожалуйста, список возвращаемых ошибок. А то стыдно за авторов — так кичатся дизайном языка, а документацию писать не умеют.
Это была всего лишь шутка. А суть ее вполне серьезна — все это всего лишь разные модели лицензирования, которые имеют свое право на жизнь и многими успешно используются. Сейчас очень популярна такая вещь как платные on-premise продукты, часто зовутся enterprise версиями. Бывает рядом с ними лежит и бесплатная с порезанным функционалом. Вы вроде скачали продукт, себе поставили, но вы платите постоянно, потому что получаете дополнительные фичи, техподдержку и прочие ништяки, которые пропишут. Перестали платить — получаете бесплатную обрезанную версию.
Это было бы уместно, будь это «табуретка как сервис». Вы платите все время, а столяр вам багфиксы, фичи новые пилит, техподдержку осуществляет, если че сломалось.
Эм, а ведение банковских операций это не целиком и полностью ИТ индустрия? Практически все денежные операции происходят за счет тех самых программистов. Не тележками же возят мешки денег.
Почту не убьют, но ее таки вытесняют из все большего количества областей. Тот же Slack и ему подобные определенно вытеснили ее как средства общения разработчиков. Mail листы и раньше выглядели архаично, сейчас вообще вызывает только смех и недоумение, когда есть куда более удобные средства. Дело привычки, это понятно — тех же разработчиков ядра сложно будет заставить перейти на что-то другое. Почта осталась разве что для более формального общения и рассылок всяческих. Хотя как средство оповещения о более скоротечных событиях тоже вытеснили мессенджеры — кто-то сделал пуш — бот прислал сообщение в общую группу. Благо интеграций между сервисами полно, и узнаешь ты об этом сразу, а не когда там дойдет письмо и его соизволит скачать клиент, если оно вообще дойдет. А уж повседневное общение мессенджеры и социалочки так точно давно монополизировали.
Буферизированный канал, по сути, семафор. На счет безопасности, не вижу разницы. Разве что код с мьютексом будет куда очевиднее и скорее всего быстрее.
Умный компилятор говорит, что так нельзя, ибо goto прыгает через инициализацию переменной. Ежели умудрится скомпилировать, то, по идее, что на стеке будет, то в «a» и попадет.
Не вдаваясь сильно в мифы, я лично читал вот про это windows.microsoft.com/en-us/windows-10/activation-in-windows-10 Сменилась терминология и появилась новая вещь — digital entitlement, которая фигурирует только в рамках активации windows 10 и совершенно отдельно от традиционных ключей. Видим отсюда ноги и растут — механизм таки изменился. Дальше уже все гадают, как же он на самом деле работает. Я вот действительно никаких ключей в свою винду не вводил при апгрейде и выдает она мне не мой ключ от Windows 8, а какой-то по-умолчанию, который на сайте МС записан.
ПО, искусственно сделавшего так, что ПО без этой процедуры работало хуже, чем может.
А как еще ему делать? Давать полную версию и надеяться, что ее купят при условии полной работоспособности и так? Винда точно так же стала триальной — пользоваться вроде как можно, но не полноценно, ибо лицензии на это пользование у тебя нет. Все логично и правильно.
Зачем при этом серийник винды писать в BIOS
Очевидно, что хэши чьи-то сохранять это быть зависимым от всех проблем, которые будут обязательно у OEMщиков. МС дает продукт и способ его активации, который от OEM не зависит — BIOS, чем бы это не являлось на самом деле, надежное защищенное хранилище для этой активации. Даже в случае потери данных можно восстановить. Не был бы BIOS, было бы другое какое-то хранилище (TPM какой-нить), не суть важно, но оно должно быть изолированным от всего остального. Опять же, логично и правильно. Других вариантов нормальных и нет.
Вот как раз поиск вообще не создает проблем и наконец стал элементом повседневной работы, чего не скажешь о 7 и прошлых. Работает молниеносно и сразу после установки софта находит новые элементы. Поиск по бинарникам своим работает — regedit и прочие системные утилиты ищет без проблем. А так, это очевидно поиск по элементам пуска. Если при установке софта не ставить галку добавления туда, то и поиск ничего не найдет
При том, что вы предложили сделать всё указателями, как там.
Они всего лишь пример реализации, больше ни для чего эти языки я не упоминал. Поэтому они здесь не при чем. Я не сравнение языков делаю и их обсуждать вообще не собирался. И пример реализации именно со стороны программиста — мне нет дела до их реального устройства. Что видит программист — вот что важно. В этих языках он не видит этих деталей, они ему не нужны. В Go зачем-то показывают, хотя тоже не нужны. И мне интересна причина, зачем.
Тогда непонятно, почему вы предложили всё сделать указателями, как там, ведь там не всё сделано указателями.
Потому что к словам придираетесь. Обобщение оно тут от лени расписывать каждую несущественную деталь, которая к сути отношения не имеет. Можно еще про boxing вспомнить, че уж тут.
Мы получим невозможность сделать массив структур, компактно расположенный в памяти, что в некоторых случаях плохо скажется на производительности. Вы, кстати постоянно забываете уточнить, что указателями хотите сделать не всё, а только объекты.
Кого это беспокоит? Кто об этом будет думать? Разработчик Go? Да не в жизни. Я говорю о философии языка и забота о кеш френдли структурах там никаким местом. Для таких целей есть другие языки. Какие вообще оптимизации, когда методы у структур по значению это выбор по-умолчанию. Go сделан для создания микросервисов, это прям вот вся его суть. Какие там структуры данных, когда у нас рантайм одна большая магическая коробка, в которой происходит что-то, о чем никто кроме самого рантайма не знает. Пока там будешь заботиться о бедном кеше, в этом кеше все будет засрано горутинами, которые нещадно мультиплексятся без всякого на то контроля со стороны программиста. Ни в одном докладе о Go никто даже не обмолвился о каких-то микрооптимизациях — философия она диктует то, как применяется язык. Все говорят об одном — горутинах и как правильно писать асинхронный код.
Отсутствие этой фенечки не позволяет писать код, который учитывает наличие процессорного кеша.
Поэтому я уточнил про специфику — C# не об этом и подавляющее большинство софта на это плюет. Собственно, почему практически нигде ref не встретишь, а если встретишь, то явно кто-то костыль нагородил. Как и структуры, собственно, тоже редкость. Учет процессорного кеша означает работу со множество вычислений, которые сильно зависят от кэш промахов. Слишком узкий кейс в рамках дотнета. Об этом могут заботиться джетбрейнс, но не разработчики бизнес-приложений на аспнете. И например то, что за каким-нить DateTime на самом деле стоит структура — кому это интересно? Да никому. Кто от этого что-то выигрывает? Да никто. Он выглядит как класс, создается как класс, применяется как класс. Замени его на класс и мир не заметит. Низкоуровневое программирование это вон к плюсам — там рады поговорить о выравнивании, кеш линиях, кеш промахах, раскручивании циклов, предсказаниях переходов и еще много чего я тоже могу умного вспомнить, потому что это то, для чего он нужен многим многим многим разработчикам и без чего язык этот собственно и не нужен. Но они решили оставить структуры, потому что так захотелось. Могли не оставлять и ничего бы существенного язык не потерял. А так, да, греет душу — можно на кеш оптимизироваться. Интринсики еще надо для полноты картины.
А при чем тут другие языки? Я про них это все знаю. Речь о простоте Go и внезапно взявшейся низкоуровневой фиче как то передача структур по значению или ссылке. Мой изначальный посыл — это выбивается из философии языка. Тут нужно одно, скорее всего только указатели, что разом решит мутные вопросы, из синтаксиса уйдет лишнее, а минусов мы не получим. Язык нас подталкивает так работать, что это все не нужно просто напросто — есть просто заноза в заднице, когда же использовать в методе указатель. И пачка разных методов создания переменной, что сами авторы хотели бы тоже упростить. Тоже самое C# — ref там используется по праздникам и обычно не от хорошего дизайна изначально. А если еще и структуры с помощью них модифицировать, то вообще караул — кому-то надо вспомнить, что это не С++. Язык подталкивает к оперированию объектами, где вопросов о ссылках не появляется. Структуры больше фенечка и объективных преимуществ в рамках платформы и ее специфики в основном не несут. Заменил на класс с правильными свойствами и ничего сильно не изменилось. Но это и не Go, это громадный язык с кучей возможностей, там это кажется лишним скорее с точки зрения философии управляемых языков — эдакий привет из C++.
Что до критики, то кто-то много возомнил о себе. Критики мало и она имеет минимальный резонанс. Пошумели в 2-3 статьях и тишина.
А так, дельные советы. У ААА разработчиков в основном проблем с этим нет. Сейчас как раз играю в rise of the tomb raider — достаточный размер шрифта для телевизора, контраст достигается цветом текста и плашкой позади него, реплики разных героев можно окрасить в разный цвет. Ну и язык в настройках тоже настраивается, уж здесь точно хочется слышать оригинал в лице Камиллы Ладдингтон.
Учитывая, что эти расширения, суть, симбиоз протоколов и категорий, все это в obj-c можно делать. Протоколы наследуют протоколы. Категории наследуют и реализуют протоколы.
Выглядит забавно и любопытно, но, честно, никогда не сталкивался с необходимостью расширений, которые не привязаны к какому-то типу. Больше похоже на синтаксический сахар для helper-функций и методов. Называть это прям какой-то новой парадигмой protocol-oriented язык не поворачивается
Документация для программистов, а посему, запилите мне, пожалуйста, список возвращаемых ошибок. А то стыдно за авторов — так кичатся дизайном языка, а документацию писать не умеют.
А как еще ему делать? Давать полную версию и надеяться, что ее купят при условии полной работоспособности и так? Винда точно так же стала триальной — пользоваться вроде как можно, но не полноценно, ибо лицензии на это пользование у тебя нет. Все логично и правильно.
Очевидно, что хэши чьи-то сохранять это быть зависимым от всех проблем, которые будут обязательно у OEMщиков. МС дает продукт и способ его активации, который от OEM не зависит — BIOS, чем бы это не являлось на самом деле, надежное защищенное хранилище для этой активации. Даже в случае потери данных можно восстановить. Не был бы BIOS, было бы другое какое-то хранилище (TPM какой-нить), не суть важно, но оно должно быть изолированным от всего остального. Опять же, логично и правильно. Других вариантов нормальных и нет.
Они всего лишь пример реализации, больше ни для чего эти языки я не упоминал. Поэтому они здесь не при чем. Я не сравнение языков делаю и их обсуждать вообще не собирался. И пример реализации именно со стороны программиста — мне нет дела до их реального устройства. Что видит программист — вот что важно. В этих языках он не видит этих деталей, они ему не нужны. В Go зачем-то показывают, хотя тоже не нужны. И мне интересна причина, зачем.
Потому что к словам придираетесь. Обобщение оно тут от лени расписывать каждую несущественную деталь, которая к сути отношения не имеет. Можно еще про boxing вспомнить, че уж тут.
Кого это беспокоит? Кто об этом будет думать? Разработчик Go? Да не в жизни. Я говорю о философии языка и забота о кеш френдли структурах там никаким местом. Для таких целей есть другие языки. Какие вообще оптимизации, когда методы у структур по значению это выбор по-умолчанию. Go сделан для создания микросервисов, это прям вот вся его суть. Какие там структуры данных, когда у нас рантайм одна большая магическая коробка, в которой происходит что-то, о чем никто кроме самого рантайма не знает. Пока там будешь заботиться о бедном кеше, в этом кеше все будет засрано горутинами, которые нещадно мультиплексятся без всякого на то контроля со стороны программиста. Ни в одном докладе о Go никто даже не обмолвился о каких-то микрооптимизациях — философия она диктует то, как применяется язык. Все говорят об одном — горутинах и как правильно писать асинхронный код.
Поэтому я уточнил про специфику — C# не об этом и подавляющее большинство софта на это плюет. Собственно, почему практически нигде ref не встретишь, а если встретишь, то явно кто-то костыль нагородил. Как и структуры, собственно, тоже редкость. Учет процессорного кеша означает работу со множество вычислений, которые сильно зависят от кэш промахов. Слишком узкий кейс в рамках дотнета. Об этом могут заботиться джетбрейнс, но не разработчики бизнес-приложений на аспнете. И например то, что за каким-нить DateTime на самом деле стоит структура — кому это интересно? Да никому. Кто от этого что-то выигрывает? Да никто. Он выглядит как класс, создается как класс, применяется как класс. Замени его на класс и мир не заметит. Низкоуровневое программирование это вон к плюсам — там рады поговорить о выравнивании, кеш линиях, кеш промахах, раскручивании циклов, предсказаниях переходов и еще много чего я тоже могу умного вспомнить, потому что это то, для чего он нужен многим многим многим разработчикам и без чего язык этот собственно и не нужен. Но они решили оставить структуры, потому что так захотелось. Могли не оставлять и ничего бы существенного язык не потерял. А так, да, греет душу — можно на кеш оптимизироваться. Интринсики еще надо для полноты картины.