Я не спорю, что это не является жизненно необходимой фичей, но иметь под рукой было бы неплохо. Мне кажется, тащить целую стороннюю библиотеку для case-insensitive сравнения строк как-то излишне, а ведь это бывает нужно чаще, чем индексация по кодпоинтам. Даже в Rust, который вроде как системный язык и один из длинной очереди убийц C++, есть полноценная поддержка UTF-8.
Видимо, хотелось поддержки строковых операций с UTF-8, таких как расчёт длины строки (в codepoints), регулярные выражения, понимающие юникод, case folding, получение codepoint по индексу и т.п. Всё это есть в ICU, и его советуют применять как самое надёжное и полное решение для работы с юникодом, но отсутствует в языке. std::wstring в общем случае не рекомендуют использовать из-за его платформозависимости и, как я понимаю, проблемами с surrogate pairs. QString из Qt по умолчанию использует именно ICU как бэкенд. В Go, например, таблицы диапазонов встроены в язык, и все эти операции тоже есть в стандартной библиотеке сразу над UTF-8.
В классическом подходе на модели накладываются небольшие одинаковые текстуры, ну там «камень» или «кирпич» и повторяются сколько надо раз, чтобы покрыть всю поверхность. Мегатекстура же имеет размер во всю поверхность карты, так что можно рисовать уникальные текстуры, которые никогда не повторяются. На самом деле, глаз это не очень замечает, если сама игра интересна, так что для игрока эффект не особо впечатляющий. Разве что специально ходить и разглядывать уникальные трещины и пыль.
У C++ есть киллер-фича — ты не платишь за то, чем не пользуешься. То есть, вся эта темплейтная ООП-мешанина в ряде случаев конвертируется или инлайнится в обычные функции без vtable, что позволяет сэкономить память и такты процессора. Конечно, в JIT и интерпретируемых языках такое отсутствует, но сам JIT очень неплох. Хоть и не истина в последней инстанции, Benchmarks Game позволяет оценить качество оптимизаций JVM против C++: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp — отрыв не такой уж большой. А вот потребление зато памяти серьёзное, да и самопроизвольно срабатывающий GC для игрового кода подходит не очень. Вообще, на Java игры есть, не только известный Minecraft, но и Starmade, например, или Retro-Pixel Castles. Мне кажется, отсутствие красивой графики вызвано и непопулярностью платформы для игроделия, и отсутствием серьёзных движков с хорошим инструментарием, и падением производительности на стыке Java и нативного кода (JNI), который дёргает OpenGL.
А компилирующиеся в нативный код языки никуда не уйдут, у них огромная кодовая база и сообщество. Может, Rust что-то сможет предложить, время покажет.
И вообще, сами их дизайнеры не используют возможности движка, выходит, а больше им никто не пользуется. Я разве что Prey могу вспомнить из того, что делали сторонние разработчики, ну и отчасти Wolfenstein, но это всё же Id'шная франшиза. Тогда как на UE3/4 сделана невообразимая масса игр от кучи различных студий, а теперь ещё и инди подтянулись. И учитывая тенденции по уходу в опенсорс, Id останется либо сидеть на своём стогу сена и стагнировать, либо присоединяться. Сомневаюсь, что появится много желающих лицензировать Id tech, когда вон тут бесплатно раздают намного более технологичный, кроссплатформенный и обвешанный экосистемой UE4 со смехотворными отчислениями. Ну понятно, что 5% с определённой суммы могут перестать быть смешными, однако ж вряд ли Id/Zenimax сумеют по совокупности сделать более интересное предложение.
Я в саму игру не играл (в новый DOOM), так что оцениваю чисто по скриншотам и видео. А в DOOM 3 были крутые динамические тени от всех предметов, пусть и чернущие, ну и normal mapping. На фоне других игр это выглядело совершенно потрясно. А ещё там были интерактивные интерфейсы, вписанные в мир, т.е. жать кнопки на сенсорных экранах можно было не открывая модальный интерфейс, а двигая головой. Жаль, что не очень это прижилось.
Странно, технология такая крутая, а картинка… не ощущается некстгена. Всё такое же металло-пластиковое, как и в DOOM 3. Сейчас даже в Unity шейдеры (читай: материалы) лучше, чего уж говорить про UE4. А Id, похоже, решили вложиться в технологии оптимизированного рендера (чтобы быстро было и с глубиной резкости), а не в реалистичные материалы и освещение, тогда как у конкурентов упор на всякие subsurface scattering и прочий physics-based lighting с почти-почти-уже-честным global illumination. Вот эта их мегатекстура как технология хороша и даже революционна, но игроки разве оценили её? Дизайнерам, возможно, по душе пришлось, но и только. А вау-эффекта со времён D3 у меня лично не возникало от их игр/движков. Печально.
Ну понятно, что не за один день и за один рубль. Я имею в виду, что технически тут преград нет, раз алгоритмы уже разработаны, а организационные и экономические проблемы, конечно, очень большие.
Ну, применяемые алгоритмы нельзя будет использовать, но это ведь не значит, что ЭЦП как концепция умрёт. Есть алгоритмы, которые устойчивы против квантовых компьютеров: https://ru.wikipedia.org/wiki/Постквантовая_криптография
Хотел бы отметить, что видео на тему языков программирования имеет ограниченное применение. Во-первых, это носитель последовательного доступа, нельзя прокрутить видео и составить впечатление о полезности информации, прежде чем тратить на полный просмотр время. С текстом это делается без проблем. Во-вторых, из видео нельзя скопировать и запустить пример кода. В-третьих, содержимое видео не индексируется пока что поисковиками, так что найти его по запомнившемуся фрагменту не выйдет. К видео предъявляется больше требований по части качества (звуковое и графическое оформление, дикция, читаемость текста и т. д.). Ну и много ещё можно вспомнить нюансов, всё же программирование состоит из текста, а не образов, и единственный вид полезного видео на эту тему, что я могу представить, это запись лекции из зала с вопросами и ответами, но и то обычно оно сопровождается текстовым материалом или презентацией.
По-моему, лучше вылизать одну статью, чем сделать десяток видео на ту же тему. Но это только моё мнение, конечно.
Ну если действие применяется для объектов каких-то пользовательских классов, скорее всего, оператор перегружен. Хорошая IDE позволяет находить правильную перегрузку, если одной документации мало. А в целом, это как специя: применяй дозированно и только в нужных местах, будет вкусно; засыпь всё толстым слоем, потому что это же так прикольно и семантично (на взгляд автора), ну и отправится блюдо в мусорку.
Я вообще не очень понимаю, как можно возвращать ссылку на локальную переменную, хоть она и rvalue (в первом случае), это ведь UB, не? Автор создаёт новый объект класса Vector3 и возвращает его по ссылке, но т.к. это автоматическая переменная, она тут же будет удалена при завершении функции, и ссылка в общем случае будет невалидной. По значению возвращать можно без проблем, конечно, тут ещё и копирования не будет за счёт copy elision.
Вообще, перегрузка оператора присвоения — это нетривиальная тема, в отличие от большинства других операторов, т.к. мало просто скопировать данные, нужно ещё и старое значение переменной корректно очистить. На SO очень хорошо описан по шагам путь к элегантной идиоме copy-and-swap: http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom
Теоретически, через DHT-подобную структуру можно. Происходит поиск нескольких узлов, которые находятся «близко» (по XOR-метрике) к вашему уникальному ID, который выводится, скажем, из логина-пароля. На эти узлы периодически отсылается шифрованный пакет данных вместе с его версией (просто увеличивающееся число), шифруется он мастер-ключом, который зашифрован вашим паролем, и подписывается секретным ключом авторизации, а публичный высылается в комплекте. При сохранении первой версии узел сохраняет у себя пару ID+PubKey и потом позволяет обновлять данные только при верной подписи пакета для этого публичного ключа.
Понятно, что люди приходят и уходят, но браузер запущен в течение дня почти постоянно, да и число узлов можно подобрать, чтобы хранилось с нужной степенью надёжности. Тем более, что близость к ID означает, фактически, детерминированный рандом, так что люди будут из разных часовых поясов.
В итоге, все будут хранить немного чужих данных, но так как они зашифрованы (даже не паролем, а ключом), это не является проблемой. Для большей надёжности можно хранить эти ключи отдельно от данных под другим ID (который вычисляется из логина + некая соль), так что они попадут на другие машины. При синхронизации сначала запрашивается шифрованный ключ, расшифровывается паролем (операция однократная для новой инсталляции), потом аналогично выкачиваются данные с нескольких близких узлов, выбирается самая новая версия, проверяется подпись, потом всё это расшифровывается и синхронизируется.
Плюсы очевидны — не нужно облако, система (почти) неограниченно масштабируется, надёжна настолько, насколько защищён сам пользователь, отказоустойчива (нужны эксперименты). Минусы также известны пользователям торрента, это долгий поиск цели, необходимость проброса портов (можно обойти с помощью мастернод-релеев и UDP hole punching), также возможна ситуация, когда в сети нет ни одного узла с вашими данными. Но если хотя бы раз в час посылать обновления, эту вероятность можно свести к минимуму.
Надо как минимум протоколы на множестве участков подделать — завышая явку относительно реальной, чтобы было место куда вбрасывать липовые хэши
Вот я и не пойму, что им мешает так делать. Ведь что вброс, что завышение, всё одно преступления, которые как-то не принято замечать (председатель комиссии сбега́ет от наблюдателей в неизвестном направлении с документами, и ему за это ничего не будет). Почему этим не пользуются, это проще же?
Технически задача обеспечения криптографической достоверности выборов интересная, но на тему защиты от вбросов я ничего не встречал. Возможно, потому что эта задача и не решаема техническими методами, т.к. отличить фальшивого избирателя от реального можно только организационными методами.
Я не вижу принципиальной сложности сделать честный показ информации по этому ID и «нужную» сумму голосов. Вы же не можете все-все ID проверить и сумму подсчитать самостоятельно. И я не вижу вообще решения этой проблемы в протоколах проверяемого голосования. Как только число участников становится достаточно большим (от тысяч ста, наверно), суммами можно манипулировать как угодно.
В C++17 внесён, можно уже не ждать. Если категорически нужна совместимость со старым рантаймом, можно статически слинковаться с libstdc++. В любом случае, вряд ли копирование в std::string стало бы внезапно бутылочным горлом в этой функции, а профайлер прогонять всяко надо время от времени. Читабельность и надёжность кода же повысится в разы.
Про memcpy я немного погорячился, он попадается в методе обработки крэша, так что там может быть и оправдано. Всё-таки низкоуровневая логика сама по себе.
Если писать без автоформатирования, то да, возможно. Я привык часто жать Ctrl+Shift+F, чтобы код выглядел красиво, в этом случае выражение прыгнуло бы к return и стало бы самоочевидно. Ошибка с пропущенной запятой точно так же стала бы заметна.
А ещё я совершенно не понимаю, зачем в проекте на C++ использовать сишные strcmp и memcpy, которые известны букетами ошибок. Если даже аргумент приходит в (const) char *, безопаснее сначала сделать из него std::string и после этого сравнивать с чем угодно без глупых подсчётов числа букв.
По запрещённым символам да, это я проглядел. Но что делать со слишком длинными именами, тем более, если префикс допустимой длины будет совпадать? Как в DOS будете сокращать и дописывать ~1, ~2 и.т.д.? Тогда надо будет вести какой-то реестр соответствия имён, наверно.
А компилирующиеся в нативный код языки никуда не уйдут, у них огромная кодовая база и сообщество. Может, Rust что-то сможет предложить, время покажет.
Просто перевыпустят ключи на новых алгоритмах.
По-моему, лучше вылизать одну статью, чем сделать десяток видео на ту же тему. Но это только моё мнение, конечно.
Вообще, перегрузка оператора присвоения — это нетривиальная тема, в отличие от большинства других операторов, т.к. мало просто скопировать данные, нужно ещё и старое значение переменной корректно очистить. На SO очень хорошо описан по шагам путь к элегантной идиоме copy-and-swap: http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom
Понятно, что люди приходят и уходят, но браузер запущен в течение дня почти постоянно, да и число узлов можно подобрать, чтобы хранилось с нужной степенью надёжности. Тем более, что близость к ID означает, фактически, детерминированный рандом, так что люди будут из разных часовых поясов.
В итоге, все будут хранить немного чужих данных, но так как они зашифрованы (даже не паролем, а ключом), это не является проблемой. Для большей надёжности можно хранить эти ключи отдельно от данных под другим ID (который вычисляется из логина + некая соль), так что они попадут на другие машины. При синхронизации сначала запрашивается шифрованный ключ, расшифровывается паролем (операция однократная для новой инсталляции), потом аналогично выкачиваются данные с нескольких близких узлов, выбирается самая новая версия, проверяется подпись, потом всё это расшифровывается и синхронизируется.
Плюсы очевидны — не нужно облако, система (почти) неограниченно масштабируется, надёжна настолько, насколько защищён сам пользователь, отказоустойчива (нужны эксперименты). Минусы также известны пользователям торрента, это долгий поиск цели, необходимость проброса портов (можно обойти с помощью мастернод-релеев и UDP hole punching), также возможна ситуация, когда в сети нет ни одного узла с вашими данными. Но если хотя бы раз в час посылать обновления, эту вероятность можно свести к минимуму.
Вот я и не пойму, что им мешает так делать. Ведь что вброс, что завышение, всё одно преступления, которые как-то не принято замечать (председатель комиссии сбега́ет от наблюдателей в неизвестном направлении с документами, и ему за это ничего не будет). Почему этим не пользуются, это проще же?
Технически задача обеспечения криптографической достоверности выборов интересная, но на тему защиты от вбросов я ничего не встречал. Возможно, потому что эта задача и не решаема техническими методами, т.к. отличить фальшивого избирателя от реального можно только организационными методами.
Про memcpy я немного погорячился, он попадается в методе обработки крэша, так что там может быть и оправдано. Всё-таки низкоуровневая логика сама по себе.
А ещё я совершенно не понимаю, зачем в проекте на C++ использовать сишные strcmp и memcpy, которые известны букетами ошибок. Если даже аргумент приходит в (const) char *, безопаснее сначала сделать из него std::string и после этого сравнивать с чем угодно без глупых подсчётов числа букв.