int* написать проще, чем std::shared_ptr<int>. Поэтому опасность удобнее и лаконичнее безопасности. Это проблема
Я рассуждаю следующим образом. Что мы могли бы сделать с языком, если наша задача предоставить сообществу разработчиков удобный, эффективный и безопасный инструмент?
Сломать обратную совместимость и сделать так, что int* — это и есть std::shared_ptr<int>, а для небезопасного указателя сделать std::unsafe_ptr<int>. Тогда получится, что безопасно писать удобнее, а небезопасно — неудобнее. Профит. Минус: мы тотально уничтожили обратную совместимость, да ещё и запутали разработчиков.
Сохранить обратную совместимость, но сделать так, что новый безопасный указатель проигрывает конкуренцию по эргономике небезопасному указателю - это то, что сделано сейчас. Вот это вот std::shared_ptr<int> - это неудобная дичь.
Сохранить обратную совместимость, но сделать так что новый указатель выигрывает конкуренцию по эргономике небезопасному указателю. Это будет стимулировать разработчиков использовать его. Это идеальный вариант. Проблема в том, что сложно придумать что-то лаконичнее, чем звёздочка *. Я понятия не имею, что это может быть.
Сохранить обратную совместимость, но сделать так что новый указатель не проигрывает конкуренцию по эргономике небезопасному указателю. Это не будет стимулировать разработчиков использовать его, но и не будет отталкивать. Как? Это уже дискусионный вопрос. Самое главное, что должно быть обязательно — эта форма не должна быть менее удобной, чем *. В рамках мозгового штурма можно накидать предлагаемые варианты:
int`
int@
int^ (занят C++ CLI)
int+
int$
int_ptr (добавление постфикса _ptr к любому типу делает его безопасным указателем)
Ничего не добавлять, но обязать встраивать в компилятор ИИ‑анализатор, который будет палить потенциальные неочевидные места, где int* выстрелит тебе в ногу и выкидывать варнинги — то, что сейчас кажется безумием, в будущем будет нормой.
Ещё что-нибудь, что не будет требовать писать жирные::__монструозные<констр>(укции) const.
Да, лезть в синтаксис с неочевидной фигнёй, наверное, не круто. А звёздочка — она разве очевидная? Она привычная, но не очевидная. Звёздочка есть часть синтаксиса, и она состоит из одного символа. Конкурировать по эргономике с ней может только то, что не сложнее. Поэтому, как бы неприятно это не было, это может быть только ещё один какой‑то символ. Да, это не так очевидно для тех, кто видит это в первый раз. Но C++ — это не про низкий порог вхождения, наверное. Хотя может я ошибаюсь.
Я не думаю, что моё предложение прям хорошее, и сам в нём не особо уверен, это просто размышления. Это субъективщина.
Обращаю внимание: утверждение о том, что текущая реализация плоха, и утверждение о том, как это, по моему субъективному мнению, можно было бы сделать лучше — это два разных утверждения. И даже если моё предложение неудачно — из ложности второго утверждения не следует ложность первого. Логика.
Мне часто приходится писать на C++, хотя да — это далеко не основной язык, которым я пользуюсь. В основном я хожу туда за числодробилками и/или 3D‑графикой.
Можно подумать за пределами c++ разделяемое владение никому не нужно (или наоборот, всем нужно только и исключительно оно, поэтому shared_ptr там опущено и принимается по умолчанию), как и блокировки.
Это частности, на примере которых я объясняю непродуманность и неудобность нововведений языка.
Я не говорю «частное владение нужно» или «частное владение не нужно», я не говорю «блокировки нужны» или «блокировки не нужны».
Я говорю, что в язык C++ блокировки были вставлены бездумно и неудобно, я говорю, что разделяемое владение было сделано бездумно и неудобно. И почти всё новое, что они туда засунули, они засунули бездумно и неудобно.
Ещё раз, само то, что засунули — хорошо, то каким именно способом засунули — плохо.
Вот и не хотят. Вот и не пишут. Вот и получается небезопасно. Об этом и речь. Надо чтобы вероятность захотеть написать безопасно была выше, чем вероятность захотеть написать небезопасно.
Более‑менее неплохой пример — то, как это сделано в C#. Я могу писать только безопасно. Если я хочу писать опасно, я сначала должен зайти, поставить галочку
потом написать
unsafe
{
}
И только внутри мне позволят творить опасные опасности. А для __makeref и __refvalue вообще не показываются автокомплиты. Небезопасному коду мешает и семантика языка, и компилятор языка, и среда разработки. А безопасный код пишется проще.
А в C++ наоборот: если я хочу писать опасно, я просто пишу * и &. Если же я хочу писать безопасно, мне надо std::shared_ptr constexpr const const std::lock_guard.
Я не говорю что такой подход идеальный, просто в нём вектор удобства повернут в нужную сторону — удобнее писать безопасно, чем небезопасно.
Речь то не про конкретно приведение типов, а про то, что почти всё новое в C++ сделано неудобно. С каждым разом от тебя хотят всё больше и больше __всяких:::::::слов, <std::букв> и constexpr [[std::вырвиглазных]]:::<<<<конструкций___t>>> constexpr, апеллируя к Безопасности с большой красивой буквы std::Б.
30 лет развития C++ - это когда вместо std::string doit(std::string param); нужно писать [[nodiscard]] constexpr auto doit(std::string_view param) noexcept -> std::string;
Это что вообще за дичь? Зачем так делать? Зачем они пытаются догнать брейнфак? Им там скучно?
Конечно, можно обточить напильником любую дичь и сделать из неё конфетку. Но проблема как раз в том, что без напильника эта дичь — дичь.
И опять же противоречие, в одном месте - нужно чтобы небезопасный код было писать сложнее, в другом месте reinterpret_cast (самое небезопасное что можно придумать) - а давайте покороче!
Моя претензия как раз и состоит в том, что в этом языке покороче является противоположностью безопаснее. Так быть не должно. Должно быть (покороче и безопаснее) или (подлиннее и небезопаснее).
Про Rust я ничего не писал, Вы сами его упомянули. Я на нём не пишу и отношусь к нему нейтрально никак. Появится мой личный опыт работы с ним — будут сравнивать.
И в этом качестве я конкурента С++ ни одного не знаю, shared_ptr отлично выражает то что происходит в коде, также как и reinterpret_cast, читаешь код и всё однозначно и понятно.
К удобству. Писать (T) и * проще, чем std::reinterpreprepret_cast<T>( ) и std::shared_ptr<T>( ). Общий смысл такой:
В C++ есть старые инструменты, позволяющие писать небезопасный код
В C++ также есть новые инструменты, позволяющие писать безопасный код
Большинство новых инструментов сделаны вырвиглазными, многословными, многобуквенными и неудобными. Да, ими можно пользоваться. Но удобными они от этого не становятся
Многословная многобуквенность. Очень напоминает бюрократию из человеческого мира, где на каждый чих нужна справка. Вот тут тоже — захотел чихнуть, пиши громоздкую конструкцию с квадроточиями, подчёркиваниями и длинными словами. А всё что писалось буквально одним символом — это теперь ересь, так делать нельзя. Спасибо что хоть перед фигурными скобками std::{ не надо писать std::}
Это (добавление новых возможностей для безопасности) надо было сделать — да. Это C++, он профессиональный язык для серьёзных штук, а не какой‑нибудь там питон — снова да. Но, всё равно, это надо было сделать удобнее. Даже в int32_t не обошлось без земли! Ну зачем так делать?
Эргономика есть не только у кружек, дрелей, и приложений. У языка она тоже есть. Человек, создающий сложные серьёзные штуки, может страдать от сложности задачи, но он не должен страдать от инструмента, с помощью которого он эти задачи решает.
Вот перейти надо трассу. Можно просто перелезть через отбойник и быстро перебежать. А вон справа вон, безопасный мост. Вы идёте до него 100 метров, пристёгиваетесь к перилам, поднимаетесь по 8 лестничным пролётам. Затем отстёгиваетесь, наверху, у вас проверяют паспорт, проверяют знание стихотворений Лермонтова наизусть, потом вы идете первую половину моста, вас останавливают, досматривают, спрашивают цель перехода и собираетесь ли вы потом идти обратно, вам дают ключ, потом проходите вторую половину моста, проходите тест на трезвость (а вдруг вы упадёте) открываете калитку, пристёгиваетесь к перилам, спускаетесь по лестинце 8 пролётов, отстёгиваетесь от перил, проходите 100 метров обратно. Безопасно? Безопасно. И чего все возмущаются, глупости какие‑то...
Можно писать, а можно и не писать. Речь об этом. Причём безопасность сделана как будто специально менее удобной, чем опасность (хм).
Даже вот эти вот std::super_protected_reinterpret___usable_cast_blablabla<T> и std::shared_super_puper_usable_ptr<T>. Возможно кто то считает, что так писать удобнее, чем (T) и *, но я вот не считаю, что это удобнее. Это жесть и кошмар. Зачем так делать непонятно, могли бы позаботиться ещё и об удобстве и простоте.
А вот фишка с постфиксами (что можно писать 500ms или 10s) — это весьма хорошая ложка мёда. Вот как надо делать — удобно и лаконично.
Теперь осталось запихнуть это в ПО, которое умеет в численное моделирование жидкостей/газов, и, моделируя кровоток, дыхание, сокращение тканей и биохимические реакции в них, а также сокращение всех мышц, генетическим алгоритмом вывести метод, который позволяет определить теплоёмкость и теплоотдачу в данный момент времени, а также другие факторы, направленные на поглощение или отдачу тепла.
Потом можно напрячь ИИ для того, чтобы он вывел в человекочитаемом виде формулу H(x,y,z,t), которая считает вектор характеристик головы для точки x,y,z и времени t, чтобы потом её можно было просто проинтегрировать и посчитать все нужные параметры.
Ещё можно интегрировать эти вычисления прямо на ДНК всех клеток головы с помощью редактирования генома CRISPR, чтобы голова могла сама автоматически считать собственные тепловые характеристики распределёнными вычислениями прямо на месте.
Тем же CRISPR можно сделать всем клеткам головы хвостики как у сперматозоидов/бактерий, только с содержанием меди и/или железа и длинные (1–2 мм), чтобы они выполняли функцию антенны и с помощью них клетки передавали информацию с длиной волны ~150 ГГц — это, скорее всего, 6G или выше. Клетки внутри передают информацию тем клеткам, которые ближе к поверхности, по цепочке, а клетки на поверхности машут хвостиками и передают информацию. Разумеется, формирование и модуляцию также нужно будет встроить в клетки.
И кстати давным давно есть кондиционеры работают при наружной температуре -21 градус у меня как раз такие
На тепло или на холод? Я тоже смотрю в сторону таких, но кроме арктических Mitsubishi ничего толком найти не могу. В идеале это если оно может в -30 работать на обогрев, т. е. наружный блок в -30 может холодить.
Я здесь вижу перекладывание ответственности на пользователей. «Ты же сам согласился, принять нажал, значит мы тут ни при чём. Читать надо было. Мы специально на каждый клик показывали 8 сообщений по 100 экранов чтобы ты точно всё прочитал и детально понял нашу позицию. А теперь нагнись, сними штаны и принимай наши новые привила конфеденциальности.»
Обмазывание проблемы бюрократической глазурью не есть её решение. По факту данные будут продолжать собирать и хранить как попало, потому что физически это почти невозможно проконтролировать, а вот пользователи будут страдать ещё больше, как в плане удобства пользования, так и, внезапно, в плане прав — по факту их станет меньше, а не больше.
Да, я понимаю, что задумка хорошая, но на практике она выродится в такую реализацию, где сильная сторона ещё больше выиграет, а слабая — ещё больше проиграет.
Голова почти водяная, у воды теплоёмкость 4200 кДж/м3, ЕМНИП. Исходя из объёма головы и мощности передатчика, а также потери при передаче ИК через воздух, альбедо головы в инфракрасном диапазоне (какой% излучения поглотится, а не отразится обратно), а также из расчёта диаграммы направленности (какой% всего излучения попадает именно в голову), можно примерно посчитать, на сколько наноградусов может максимально повыситься температура за час пребывания под данным излучением :) И это при условии, что человек никак не охлаждается об воздух, не потеет и не теряет тепло через вторичное ИК излучение.
А так в целом, если отвлечься от дискуссий про воздействие ЭМ на организм, сам по себе проект очень крутой — респект автору. Как говорится, задолго до того, как Li‑Fi стало мейнстримом.
Я правильно понял, что, как и в случае с сookies, всё сведётся к ещё одной надоедливой плашке на сайтах и в приложениях, а слежка по‑прежнему будет усиливаться, как и утечки собранных данных? Или я не понимаю и это другое?
И какое же у ЭМ на тех частотах и мощностях, которые используются для передачи данных, воздействие на организм? Кроме теплового, воздействие которого ничтожно мало.
Снять пейзаж или документ будет можно, но как быть с динамичными сценами, например, шустрым ребенком? В такой ситуации камера в обычном смартфоне не всегда справляется. Качество снимка на черно‑белом экране опять же не оценить.
Тут могут (но это не точно) помочь всякие умные интеллектуальные режимы съёмки, которые угадают, что именно хочет пользователь. К примеру, камера делает снимки непрерывно, и после того, как нажат спуск, камера из ближайших снятых ищет наиболее удачные. Удачность определяется через ИИ.
Но это превозмогание какое‑то. Тут мне близка позиция Леонида Каганова: любой интерфейс должен летать под руками пользователя, а не заставлять человека ждать, пока что‑то там отрисуется на экране. Конечно, для электронных книг задумчивость e‑ink полностью простительна.
Именно! Превозмогание приводит к тому, что от листания лент не генерируется удовольствие → вероятность залипнуть меньше.
Насколько я понял, сама концепция устройства подразумевает, что раз человек не может в самоконтроль, мы сделаем его менее удобным, так, чтобы от его использования человек не получал кайф, и, как следствие, использовал только когда надо, а не всё время. То есть оно должно решать задачу, но не должно быть слишком удобным и прикольным. Смысл этого устройства — не быть прикольным. Это как еда в армии, которая не должна быть вкусной (но и отвратительной тоже не должна быть), чтобы её ели только для утоления голода, а не потому, что её поглощение приносит удовольствие.
Со своей стороны, я считаю, что защита от залипания должна быть в черепной коробке, а не в устройстве. Человек должен уметь контролировать своё внимание, в противном случае ему ничего не поможет. Тем не менее, для тех, кто ниасилил, это устройство может быть каким‑то решением.
интерфейс должен летать под руками пользователя, а не заставлять человека ждать, пока что-то там отрисуется на экране
Всеми руками за. В реальной жизни предметы не тормозят когда их перемещаешь, интерфейс должен делать так же. По этой же причине первые айфоны/айпады были на качественно другом уровне по сравнению с первыми устройствами на андройде. Сейчас андройд эту болячку победил, но лет 10 назад без боли на скорость интерфейса андройд‑устройств смотреть было невозможно.
У e‑ink все плохо с отзывчивостью: более 200 мс против 1-10 мс у AMOLED и LCD. Цветные e‑ink существуют, но они еще более тормознутые (полное обновление идет 1,5 с) и в этом проекте экран черно-белый
Если там хотя бы 5 кадров в секунду, то камерой уже можно пользоваться. Это будет неудобно, это будет бесить, но пользоваться можно будет. Касательно браузера и всего остального — 5 кадров в секунду хватит, чтобы что‑то загуглить, но не хватит, чтобы залипать в тиктоки, листать бесконечные ленты и, что, в целом, соответствует задумке. У меня есть электронная книга, и я пробовал гуглить на ней. Тормозит, но пользоваться можно.
В целом einkи постепенно убыстряются — первые жк тоже были медленными. Другое дело, что, имхо, если человек не может в самоконтроль, то подобные ограничения его вряд ли спасут. Тем не менее, жаль, если проект окажется скамом.
Вот, речь как раз про то, что сейчас это не рационально — а когда наступит момент, когда рационально?
Сейчас, например, встроить в лампочку электронно‑счётную машину с арифметическим сопроцессором, постоянным запоминающим устройством, оперативным запоминающим устройством, цифроаналоговыми преобразователями, микроволновым радиоприёмником и микроволновым радиопередатчиком, просто, чтобы ей управлять — это рационально (без сарказма).
Вероятно, это станет проще, когда такая нейросеть будет полностью оптической и пассивной, и выжигаться на производстве за 0.1 мс лазером в самом стекле из которого сделан дисплей, т. е. прохождение света через сложные световоды внутри стекла дисплея и будет являться обработкой нейросетью (в рамках эксперимента такое уже делали с распознаванием цифр).
Это то понятно, речь именно про то, что это будет проще, чем писать код, вычисляющий
На БЭСМ тоже можно было делать какую‑нибудь очередную автоматизацию полива цветов, но это тогда не было проще, чем с помощью аналоговых вычислений. А сейчас — проще.
Скажем так. Оно умеет рисовать + вероятность нести дичь понижена
int* написать проще, чем std::shared_ptr<int>. Поэтому опасность удобнее и лаконичнее безопасности. Это проблема
Я рассуждаю следующим образом. Что мы могли бы сделать с языком, если наша задача предоставить сообществу разработчиков удобный, эффективный и безопасный инструмент?
Сломать обратную совместимость и сделать так, что int* — это и есть std::shared_ptr<int>, а для небезопасного указателя сделать std::unsafe_ptr<int>. Тогда получится, что безопасно писать удобнее, а небезопасно — неудобнее. Профит. Минус: мы тотально уничтожили обратную совместимость, да ещё и запутали разработчиков.
Сохранить обратную совместимость, но сделать так, что новый безопасный указатель проигрывает конкуренцию по эргономике небезопасному указателю - это то, что сделано сейчас. Вот это вот std::shared_ptr<int> - это неудобная дичь.
Сохранить обратную совместимость, но сделать так что новый указатель выигрывает конкуренцию по эргономике небезопасному указателю. Это будет стимулировать разработчиков использовать его. Это идеальный вариант. Проблема в том, что сложно придумать что-то лаконичнее, чем звёздочка *. Я понятия не имею, что это может быть.
Сохранить обратную совместимость, но сделать так что новый указатель не проигрывает конкуренцию по эргономике небезопасному указателю. Это не будет стимулировать разработчиков использовать его, но и не будет отталкивать. Как? Это уже дискусионный вопрос. Самое главное, что должно быть обязательно — эта форма не должна быть менее удобной, чем *. В рамках мозгового штурма можно накидать предлагаемые варианты:
int`
int@
int^ (занят C++ CLI)
int+
int$
int_ptr (добавление постфикса _ptr к любому типу делает его безопасным указателем)
Ничего не добавлять, но обязать встраивать в компилятор ИИ‑анализатор, который будет палить потенциальные неочевидные места, где int* выстрелит тебе в ногу и выкидывать варнинги — то, что сейчас кажется безумием, в будущем будет нормой.
Ещё что-нибудь, что не будет требовать писать жирные::__монструозные<констр>(укции) const.
Да, лезть в синтаксис с неочевидной фигнёй, наверное, не круто. А звёздочка — она разве очевидная? Она привычная, но не очевидная. Звёздочка есть часть синтаксиса, и она состоит из одного символа. Конкурировать по эргономике с ней может только то, что не сложнее. Поэтому, как бы неприятно это не было, это может быть только ещё один какой‑то символ. Да, это не так очевидно для тех, кто видит это в первый раз. Но C++ — это не про низкий порог вхождения, наверное. Хотя может я ошибаюсь.
Я не думаю, что моё предложение прям хорошее, и сам в нём не особо уверен, это просто размышления. Это субъективщина.
Обращаю внимание: утверждение о том, что текущая реализация плоха, и утверждение о том, как это, по моему субъективному мнению, можно было бы сделать лучше — это два разных утверждения. И даже если моё предложение неудачно — из ложности второго утверждения не следует ложность первого. Логика.
Мне часто приходится писать на C++, хотя да — это далеко не основной язык, которым я пользуюсь. В основном я хожу туда за числодробилками и/или 3D‑графикой.
Это частности, на примере которых я объясняю непродуманность и неудобность нововведений языка.
Я не говорю «частное владение нужно» или «частное владение не нужно», я не говорю «блокировки нужны» или «блокировки не нужны».
Я говорю, что в язык C++ блокировки были вставлены бездумно и неудобно, я говорю, что разделяемое владение было сделано бездумно и неудобно. И почти всё новое, что они туда засунули, они засунули бездумно и неудобно.
Ещё раз, само то, что засунули — хорошо, то каким именно способом засунули — плохо.
Вот и не хотят. Вот и не пишут. Вот и получается небезопасно. Об этом и речь. Надо чтобы вероятность захотеть написать безопасно была выше, чем вероятность захотеть написать небезопасно.
Более‑менее неплохой пример — то, как это сделано в C#. Я могу писать только безопасно. Если я хочу писать опасно, я сначала должен зайти, поставить галочку
потом написать
И только внутри мне позволят творить опасные опасности. А для
__makerefи__refvalueвообще не показываются автокомплиты. Небезопасному коду мешает и семантика языка, и компилятор языка, и среда разработки. А безопасный код пишется проще.А в C++ наоборот: если я хочу писать опасно, я просто пишу * и &. Если же я хочу писать безопасно, мне надо std::shared_ptr constexpr const const std::lock_guard.
Я не говорю что такой подход идеальный, просто в нём вектор удобства повернут в нужную сторону — удобнее писать безопасно, чем небезопасно.
Речь то не про конкретно приведение типов, а про то, что почти всё новое в C++ сделано неудобно. С каждым разом от тебя хотят всё больше и больше __всяких:::::::слов, <std::букв> и constexpr [[std::вырвиглазных]]:::<<<<конструкций___t>>> constexpr, апеллируя к Безопасности с большой красивой буквы std::Б.
Ниже unC0Rr привёл отличный пример:
Это что вообще за дичь? Зачем так делать? Зачем они пытаются догнать брейнфак? Им там скучно?
C++ хороший, не закапывайте C++, пожалуйста.
Конечно, можно обточить напильником любую дичь и сделать из неё конфетку. Но проблема как раз в том, что без напильника эта дичь — дичь.
Моя претензия как раз и состоит в том, что в этом языке покороче является противоположностью безопаснее. Так быть не должно. Должно быть (покороче и безопаснее) или (подлиннее и небезопаснее).
Про Rust я ничего не писал, Вы сами его упомянули. Я на нём не пишу и отношусь к нему нейтрально никак. Появится мой личный опыт работы с ним — будут сравнивать.
Ч — std::reinterpert_cast<std::word>(std::shared_ptr<std::sarcasm>(std::читаемость_t))
К удобству. Писать (T) и * проще, чем std::reinterpreprepret_cast<T>( ) и std::shared_ptr<T>( ). Общий смысл такой:
В C++ есть старые инструменты, позволяющие писать небезопасный код
В C++ также есть новые инструменты, позволяющие писать безопасный код
Большинство новых инструментов сделаны вырвиглазными, многословными, многобуквенными и неудобными. Да, ими можно пользоваться. Но удобными они от этого не становятся
Многословная многобуквенность. Очень напоминает бюрократию из человеческого мира, где на каждый чих нужна справка. Вот тут тоже — захотел чихнуть, пиши громоздкую конструкцию с квадроточиями, подчёркиваниями и длинными словами. А всё что писалось буквально одним символом — это теперь ересь, так делать нельзя. Спасибо что хоть перед фигурными скобками std::{ не надо писать std::}
Это (добавление новых возможностей для безопасности) надо было сделать — да. Это C++, он профессиональный язык для серьёзных штук, а не какой‑нибудь там питон — снова да. Но, всё равно, это надо было сделать удобнее. Даже в int32_t не обошлось без земли! Ну зачем так делать?
Эргономика есть не только у кружек, дрелей, и приложений. У языка она тоже есть. Человек, создающий сложные серьёзные штуки, может страдать от сложности задачи, но он не должен страдать от инструмента, с помощью которого он эти задачи решает.
Вот перейти надо трассу. Можно просто перелезть через отбойник и быстро перебежать. А вон справа вон, безопасный мост. Вы идёте до него 100 метров, пристёгиваетесь к перилам, поднимаетесь по 8 лестничным пролётам. Затем отстёгиваетесь, наверху, у вас проверяют паспорт, проверяют знание стихотворений Лермонтова наизусть, потом вы идете первую половину моста, вас останавливают, досматривают, спрашивают цель перехода и собираетесь ли вы потом идти обратно, вам дают ключ, потом проходите вторую половину моста, проходите тест на трезвость (а вдруг вы упадёте) открываете калитку, пристёгиваетесь к перилам, спускаетесь по лестинце 8 пролётов, отстёгиваетесь от перил, проходите 100 метров обратно. Безопасно? Безопасно. И чего все возмущаются, глупости какие‑то...
Можно писать, а можно и не писать. Речь об этом. Причём безопасность сделана как будто специально менее удобной, чем опасность (хм).
Даже вот эти вот std::super_protected_reinterpret___usable_cast_blablabla<T> и std::shared_super_puper_usable_ptr<T>. Возможно кто то считает, что так писать удобнее, чем (T) и *, но я вот не считаю, что это удобнее. Это жесть и кошмар. Зачем так делать непонятно, могли бы позаботиться ещё и об удобстве и простоте.
А вот фишка с постфиксами (что можно писать 500ms или 10s) — это весьма хорошая ложка мёда. Вот как надо делать — удобно и лаконично.
Теперь осталось запихнуть это в ПО, которое умеет в численное моделирование жидкостей/газов, и, моделируя кровоток, дыхание, сокращение тканей и биохимические реакции в них, а также сокращение всех мышц, генетическим алгоритмом вывести метод, который позволяет определить теплоёмкость и теплоотдачу в данный момент времени, а также другие факторы, направленные на поглощение или отдачу тепла.
Потом можно напрячь ИИ для того, чтобы он вывел в человекочитаемом виде формулу H(x,y,z,t), которая считает вектор характеристик головы для точки x,y,z и времени t, чтобы потом её можно было просто проинтегрировать и посчитать все нужные параметры.
Ещё можно интегрировать эти вычисления прямо на ДНК всех клеток головы с помощью редактирования генома CRISPR, чтобы голова могла сама автоматически считать собственные тепловые характеристики распределёнными вычислениями прямо на месте.
Тем же CRISPR можно сделать всем клеткам головы хвостики как у сперматозоидов/бактерий, только с содержанием меди и/или железа и длинные (1–2 мм), чтобы они выполняли функцию антенны и с помощью них клетки передавали информацию с длиной волны ~150 ГГц — это, скорее всего, 6G или выше. Клетки внутри передают информацию тем клеткам, которые ближе к поверхности, по цепочке, а клетки на поверхности машут хвостиками и передают информацию. Разумеется, формирование и модуляцию также нужно будет встроить в клетки.
А ещё эти хвостики будут пушисто лосниться.
На тепло или на холод? Я тоже смотрю в сторону таких, но кроме арктических Mitsubishi ничего толком найти не могу. В идеале это если оно может в -30 работать на обогрев, т. е. наружный блок в -30 может холодить.
Я здесь вижу перекладывание ответственности на пользователей. «Ты же сам согласился, принять нажал, значит мы тут ни при чём. Читать надо было. Мы специально на каждый клик показывали 8 сообщений по 100 экранов чтобы ты точно всё прочитал и детально понял нашу позицию. А теперь нагнись, сними штаны и принимай наши новые привила конфеденциальности.»
Обмазывание проблемы бюрократической глазурью не есть её решение. По факту данные будут продолжать собирать и хранить как попало, потому что физически это почти невозможно проконтролировать, а вот пользователи будут страдать ещё больше, как в плане удобства пользования, так и, внезапно, в плане прав — по факту их станет меньше, а не больше.
Да, я понимаю, что задумка хорошая, но на практике она выродится в такую реализацию, где сильная сторона ещё больше выиграет, а слабая — ещё больше проиграет.
У них же там жарко, кондиционеры везде, неужели они не умеют в режим подогрева?
Голова почти водяная, у воды теплоёмкость 4200 кДж/м3, ЕМНИП. Исходя из объёма головы и мощности передатчика, а также потери при передаче ИК через воздух, альбедо головы в инфракрасном диапазоне (какой% излучения поглотится, а не отразится обратно), а также из расчёта диаграммы направленности (какой% всего излучения попадает именно в голову), можно примерно посчитать, на сколько наноградусов может максимально повыситься температура за час пребывания под данным излучением :) И это при условии, что человек никак не охлаждается об воздух, не потеет и не теряет тепло через вторичное ИК излучение.
А так в целом, если отвлечься от дискуссий про воздействие ЭМ на организм, сам по себе проект очень крутой — респект автору. Как говорится, задолго до того, как Li‑Fi стало мейнстримом.
Я правильно понял, что, как и в случае с сookies, всё сведётся к ещё одной надоедливой плашке на сайтах и в приложениях, а слежка по‑прежнему будет усиливаться, как и утечки собранных данных? Или я не понимаю и это другое?
И какое же у ЭМ на тех частотах и мощностях, которые используются для передачи данных, воздействие на организм? Кроме теплового, воздействие которого ничтожно мало.
Тут могут (но это не точно) помочь всякие умные интеллектуальные режимы съёмки, которые угадают, что именно хочет пользователь. К примеру, камера делает снимки непрерывно, и после того, как нажат спуск, камера из ближайших снятых ищет наиболее удачные. Удачность определяется через ИИ.
Именно! Превозмогание приводит к тому, что от листания лент не генерируется удовольствие → вероятность залипнуть меньше.
Насколько я понял, сама концепция устройства подразумевает, что раз человек не может в самоконтроль, мы сделаем его менее удобным, так, чтобы от его использования человек не получал кайф, и, как следствие, использовал только когда надо, а не всё время. То есть оно должно решать задачу, но не должно быть слишком удобным и прикольным. Смысл этого устройства — не быть прикольным. Это как еда в армии, которая не должна быть вкусной (но и отвратительной тоже не должна быть), чтобы её ели только для утоления голода, а не потому, что её поглощение приносит удовольствие.
Со своей стороны, я считаю, что защита от залипания должна быть в черепной коробке, а не в устройстве. Человек должен уметь контролировать своё внимание, в противном случае ему ничего не поможет. Тем не менее, для тех, кто ниасилил, это устройство может быть каким‑то решением.
Всеми руками за. В реальной жизни предметы не тормозят когда их перемещаешь, интерфейс должен делать так же. По этой же причине первые айфоны/айпады были на качественно другом уровне по сравнению с первыми устройствами на андройде. Сейчас андройд эту болячку победил, но лет 10 назад без боли на скорость интерфейса андройд‑устройств смотреть было невозможно.
Если там хотя бы 5 кадров в секунду, то камерой уже можно пользоваться. Это будет неудобно, это будет бесить, но пользоваться можно будет. Касательно браузера и всего остального — 5 кадров в секунду хватит, чтобы что‑то загуглить, но не хватит, чтобы залипать в тиктоки, листать бесконечные ленты и, что, в целом, соответствует задумке. У меня есть электронная книга, и я пробовал гуглить на ней. Тормозит, но пользоваться можно.
В целом einkи постепенно убыстряются — первые жк тоже были медленными. Другое дело, что, имхо, если человек не может в самоконтроль, то подобные ограничения его вряд ли спасут. Тем не менее, жаль, если проект окажется скамом.
Во‑первых, цветные e‑ink тоже существуют
Во‑вторых, картинка e‑ink отличается от картинки OLED и LCD
Вот, речь как раз про то, что сейчас это не рационально — а когда наступит момент, когда рационально?
Сейчас, например, встроить в лампочку электронно‑счётную машину с арифметическим сопроцессором, постоянным запоминающим устройством, оперативным запоминающим устройством, цифроаналоговыми преобразователями, микроволновым радиоприёмником и микроволновым радиопередатчиком, просто, чтобы ей управлять — это рационально (без сарказма).
Вероятно, это станет проще, когда такая нейросеть будет полностью оптической и пассивной, и выжигаться на производстве за 0.1 мс лазером в самом стекле из которого сделан дисплей, т. е. прохождение света через сложные световоды внутри стекла дисплея и будет являться обработкой нейросетью (в рамках эксперимента такое уже делали с распознаванием цифр).
Это то понятно, речь именно про то, что это будет проще, чем писать код, вычисляющий
На БЭСМ тоже можно было делать какую‑нибудь очередную автоматизацию полива цветов, но это тогда не было проще, чем с помощью аналоговых вычислений. А сейчас — проще.