Эх, вспоминаю времена демосцены. К примеру есть вывод RGB изображения, где с использованием стека выводятся пикселы и область цвета заливается одним цветом. Со стеком делал интовый (в рамках одного прерывания) попиксельный сколл текста, с ускорением, цветом и другими фишками. Вот там со стеком наигрался вдоволь. Единственное ограничение было, что отображалось только 6 строк со знакоместа и 2 линии просто затирались.
Но и это не самое интересное, к примеру есть алгоритмы с переключением экранов по ходу луча, без стека тоже не обходилось, ибо куда как быстрее.
Да и вообще стек использовался и при отрисовке спрайтов.
Но при этом стек имел и проблему, ещё хочется проигрывать музыку, но если в демосцене ещё можно обойтись без прерываний, то к примеру для игры уже не так удобно, не всегда всё укладывается в прерывание. И вот в случае работающих прерываний (музыка, курсор и т.д.) и если во время прихода прерывания стек стоит на оперативке со спрайтом, спрайт портится (кладётся адрес возврата), ну и это исправлялось.
А так очистка экрана через стек действительно быстрее: Побайтово — 7 + 6 = 13 тактов на байт, через стек 11 тактов на 2 байта. А учитывая убогую схемотехнику клонов и округление тактов в четную большую сторону, 14 против 6 на байт.
Погонял неделю с Vivaldi, ну что, вернулся назад к Chrome. Решающими факторами были — живой поиск и растягивание браузера на весь экран при нажатии на F12 (у меня экран был поделён между браузером и средой разработки, монитор чрезмерно широкий и так нормально всё влезает).
Подобных туториалов гора. А вот к примеру процедурное создание меша, тот ещё ад, очень интересно было бы прочитать что-то адекватное про это. Особенно учитывая, что надо использовать макросы, дока по которым нереально устаревшая :-)
Что толку экспереминтировать с grid, если нормально не поддерживается тем же IE? А если уж учесть, что якобы полностью поддерживается flex в IE и Safari, но при этом на деле это не так, а grid в IE поддерживается частично, потом так или иначе шаманить и фиксить непонятно откуда всплывшие баги?
Сегодня обновил WebStorm и что удивило, что Jest перестал работать, теперь валится где-то в недрах с ошибкой «RangeError: Maximum call stack size exceeded», так что пришлось откатываться. При этом генерируемая комманда работает из терминала нормально.
В этом году «отлично» показал себя Связной. Они не то чтобы даже фейковые скидки не сделали, они их вообще не сделали. Но разослали спам, довольно хорошо нарушающий закон о рекламе. Якобы все смартфоны по цене 999р, а по факту это платёж в месяц по кредиту. Но пиара было много.
У себя в реализации отнаследовал std::ostream, отнаследовал std::streambuf. std::ostream для удобства использования наследовал, можно был и без этого пережить. В конечном итоге есть некий менеджер который возвращает logstream, с logstreambuf.
Как логгер для проекта на коленке покатит, но для серьезного проекта я бы так делать не стал. Зачем же перегружать оператор << и иметь кучу проблем с этим, может лучше перегрузить std::ostream?
Увы, аркады может мелкие и норм на UE4 делать, но вот сложная логика и скриптинг на C++, лютое зло, учитывая, что документация вечно устаревшая, еще ладно на нормальные функции, но когда суют кругом макросы и документация по ним в большинстве своём вообще неактуальная, то это лютое зло. Да и полностью забить на идиологии разработки на C++. В итоге так и не стал использовать UE4.
За 10 лет смартфоны изменились, но соответсвенно изменились требования к железу, софт стал тормознее и в общем разница не вилика конечная. Всё тоже самое можно было делать на смартах и 10 лет назад. Всё улучшение в фантиках.
Чтобы потом другие разработчики крыли матом автора сего кода? Вы можете дать гарантии, что не понадобится в будущем? А потом возможна очень даже весёлая отладка. А уж в статье, которая рассказывает о наследовании и в которой допущена данная ошибка/упущение, это как-то не очень правильно.
Да гореть в аду тем, кто разработкой на серверах занимается. Зачем этот бардак? Разработка только локально, затем на сервер только развернуть и не более. А если в плане разворачивания/администрирования, то не проще ли написать скрипты на тестовом окружении и затем юзать на боевом?
Или вы за то, чтобы переписывать всё заново, конфигурить каждый сервер индивидуально, выкладывать везде индивидуально. Ну мсье знает толк.
Поюзал помнится blueprints из Unreal. окей, для мелочи жить можно. Но когда я порешил сгенерировать галактику не частицами, а на базе множества билбордов с вершинными шейдерами. чтобы прогонять в 1 draw call на C++, я захотел чего-нить сделать с авторами Unreal Engine с их собственной нотацией C++ на базе дефайнов, полностью забив на стилистику стандартной библиотеки и с убожеской документацией, которая отстаёт на несколько релизов и зачастую вообще неактуальна. Плюс по этим макросам IDE в принципе адекватно не работает, реалньные места ошибок найти не то что бы сложно, а вообще невозможно. То в рамках тогоже Unreal Engine вообще не хочется на C++ ничего делать. При этом знаю очень даже хорошо язык.
А чего непонятного, типичная конструкция от MS — async/await. MS проталкивают давненько и достаточно один раз посмотреть, во что это превращается, так сразу становится понятно. На примере C# очень лего понять.
Но и это не самое интересное, к примеру есть алгоритмы с переключением экранов по ходу луча, без стека тоже не обходилось, ибо куда как быстрее.
Да и вообще стек использовался и при отрисовке спрайтов.
Но при этом стек имел и проблему, ещё хочется проигрывать музыку, но если в демосцене ещё можно обойтись без прерываний, то к примеру для игры уже не так удобно, не всегда всё укладывается в прерывание. И вот в случае работающих прерываний (музыка, курсор и т.д.) и если во время прихода прерывания стек стоит на оперативке со спрайтом, спрайт портится (кладётся адрес возврата), ну и это исправлялось.
А так очистка экрана через стек действительно быстрее: Побайтово — 7 + 6 = 13 тактов на байт, через стек 11 тактов на 2 байта. А учитывая убогую схемотехнику клонов и округление тактов в четную большую сторону, 14 против 6 на байт.
Тут потерялся this. Но это самая безобидная ошибка.
После данной строки необходимо восстановить конструктор в прототипе класса Editor, ибо конструктор прилетит от User.
Или вы за то, чтобы переписывать всё заново, конфигурить каждый сервер индивидуально, выкладывать везде индивидуально. Ну мсье знает толк.