Здорово что тут получилось избавиться от аллокации. Но главный минус этой реализации, пользователю требуется подумать о времени жизни объектов. Если расширить функционал до использования с лямбдами, то станет очевидно, что такая реализация не так широко применима. Сам сейчас экспериментирую с разными подходами по теме.
Может достаточно определить заранее будут одинаковые объекты в программе/игре и при удалении очередного объекта не удалять его, а просто пометить удалённым? Придёт другой объект и займёт уже подготовленную память, да, данные перезаписать придётся, но зато "тормошить" память постоянно не надо.
А разве для этого как раз и не делают кастомные аллокаторы с пуллами памяти? На выделял на кучу объектов, те которые надо освободили, но не освободили на самом деле, а только пометили, а потом переиспользовали. Но конструторы и деструкторы вызывваются по настаяшему, а конкретные классы даже не подозревают каким образом для них добывают память.
> оно не зависло навсегда и не тормозило при наличии хотя бы 2 юзеров
А есть какое-то сравнение с питоновскими либами? Или тут в принципе бенчмаркать бессмысленно так-как очень быстро упремся в скорострельность серверов телеграмма?
У меня в универе в ВКР была часть с проектированием линейного привода станка. Как раз использовал линейный двигатель. Подробностей не вспомню, но линейный я тогда не выбрал, так как на больших длинах есть проблема с провисанием стержня. Её пытаются решить компромисными путями, размыкают цилиндр и делают П образные катушки. А ещё с плоскими двигателями есть проблема, с тем, что две части пытаются оттолкнуться друг от друга.
А для выбора функций нельзя сделать чекбоксы для каждой и при отключении удалять функционал из браузера вообще, а при включении снова ставить. Хотя тогда это будут просто расширения. Точно, а почему вы все эти календари, почты, и переводчик не сделали обычными расширениями?
Я про гонку не понял.
Мы там вроде как не ждем окончания горутин. Логично, что пока мы читаем читаем из одной переменной, горутина поменяет значение и значение в синглтоне изменится.
Но если мы просто дождемся окончания всех горутин, то значение будет одинаковое.
Как мьютекс тут влияет вообще?
Любил темные темы, пока не столкнулся с проблемой. На работе днем солнце высвечивает монитор и нифига не видно. Приходится использовать светлую тему.
Еще заметил, что с темной темой легче засыпается при чтении скучной документации.
А вот еще не понятно. Раз в 20 минут данные, это не слишком редко, а если датчик умрет вы через сколько узнаете, что что-то не так? За это время на там все не замерзнет/перегреется?
У меня в транспорте, как правило, стоять нормально проблема, а вы говорите читать. Руки заняты тем, чтобы удержаться самому, на телефон конечностей не остается. Сегодня к обычной давке добавилось еще и то, что кто-то решил помыть полы накануне заморозков. И это я еду еще не в самый час пик, когда нет пробок. В автобусе около 40 минут в один конец, но это как правило худшие 2 раза по 40 минут в день.
Мне кажется тут скорее будет вариант, что такие люди и сами не захотят размножаться. В целом тренд на старение наций уже стал замечаться в европе. Старые поколения долгожителей могут просто не захотеть чрезмерно размножаться.
Ну например если мы знаем что элементов может быть не больше чем N, но не знаем сколько именно, и динамические аллокации делать не хочется.
Здорово что тут получилось избавиться от аллокации. Но главный минус этой реализации, пользователю требуется подумать о времени жизни объектов. Если расширить функционал до использования с лямбдами, то станет очевидно, что такая реализация не так широко применима.
Сам сейчас экспериментирую с разными подходами по теме.
А разве для этого как раз и не делают кастомные аллокаторы с пуллами памяти? На выделял на кучу объектов, те которые надо освободили, но не освободили на самом деле, а только пометили, а потом переиспользовали. Но конструторы и деструкторы вызывваются по настаяшему, а конкретные классы даже не подозревают каким образом для них добывают память.
А я теперь хочу статью про другие тонкости, например деградацию move-семантики.
Да. Переходя по ссылку нужно научится закрывать глаза на пафоc.
А вот вы про
А есть какое-то сравнение с питоновскими либами? Или тут в принципе бенчмаркать бессмысленно так-как очень быстро упремся в скорострельность серверов телеграмма?
А я не понял почему strelen() не выкидывается. Это по стандарту так?
Проверил что дает бесконечный цикл.
https://godbolt.org/z/KcPvfWcnT
У меня в универе в ВКР была часть с проектированием линейного привода станка. Как раз использовал линейный двигатель. Подробностей не вспомню, но линейный я тогда не выбрал, так как на больших длинах есть проблема с провисанием стержня. Её пытаются решить компромисными путями, размыкают цилиндр и делают П образные катушки. А ещё с плоскими двигателями есть проблема, с тем, что две части пытаются оттолкнуться друг от друга.
Спасибо, буду знать
Мы там вроде как не ждем окончания горутин. Логично, что пока мы читаем читаем из одной переменной, горутина поменяет значение и значение в синглтоне изменится.
Но если мы просто дождемся окончания всех горутин, то значение будет одинаковое.
Как мьютекс тут влияет вообще?
Еще заметил, что с темной темой легче засыпается при чтении скучной документации.
Это значит вам крупно повезло. Не подскажите какой город, может мне пора дислокацию сменить?