Особенно учитывая что там Qt 5.6 и обновления до 5.15 (не говоря уже о 6) в ближайшее десятилетие ожидать не приходится. Ну хоть обновили GCC с 4.8, а то совсем грустно было :)
Радиация, температура (днём на Луне пздц как жарко, ночью пздц как холодно), перегрузки и вибрация при запуске. Вероятно хорошую камеру которая на это рассчитана сделать можно но хз какой у нее будет вес по сравнению с плохой. Ну и приоритет у них на научные приборы - камера работающая в видимом диапазоне для науки не очень полезна. Если у тебя ограниченный бюджет то зачем тратиться на разработку камеры для красивых картинок в Инстаграм если можно потратиться на научные приборы? А красивые картинки можно и с какой-нибудь инфракрасной камеры сделать и раскрасить, все равно никто не поймет разницы (NASA так испокон веку делает).
Хз насчёт sdkmanager но для сборки приложений уже некоторое время требуется java 17. Даже если sdkmanager это пока не требует то он точно может работать с 17 без проблем. Да и она сейчас последний lts.
Смотря что значит "по умолчанию") Строки изнутри в UTF-16 кодировке (но понятное дело что получить строку можно из данных в любой кодировке которая может конвертироваться в UTF-16). На консоль выводятся байты в системной "легаси" консольной кодировке (Console.OutputEncoding в .NET). По умолчанию это не UTF-8 а до-юникодная DOS кодировка (зависит от языка, на русском это CP866). Можно самому заменить на UTF-8 но тогда другая сторона (например IDE) тоже должна ожидать именно UTF-8, как-то об этом договориться "на лету" нельзя. Многие программы могут работать только с системной кодировкой, другие только с UTF-8.
Возможно имелось в виду что винда не может выводить в консоль utf-8 текст без плясок с бубном (до этого автор упоминал проблемы с кодировкой при выводе на консоль). Но в случае передачи строки в C# можно использовать UTF-8, C# умеет с ней работать.
На сайтах можно сделать точно такую же монетизацию что и в приложениях (то что многие боятся это делать потому что сайты были раньше и без монетизации уже другая история). Идея на то и идея что ее невозможно навязать технически. WWW был свободен отнюдь не потому что его нельзя сделать несвободным.
Согласен, я имел в виду что современные асинхронные подходы сами по себе не решают подобных проблем с производительностью. Если ты запускаешь 10 тысяч мелких асинхронных операций из ui треда которые потом возвращаются в обратно в ui тред то не имеет значения какой подход используется - самописанные очереди сообщений, async/await, джавовские экзекуторы - это приведет к тем же проблемам.
Асинхронные вызовы точно также приведут к обмену сообщениями между потоками (если команды на чтение файлов приходят из ui треда) - просто это будет происходить "под капотом". Никакой магии в них нет.
Особенно учитывая что там Qt 5.6 и обновления до 5.15 (не говоря уже о 6) в ближайшее десятилетие ожидать не приходится. Ну хоть обновили GCC с 4.8, а то совсем грустно было :)
Причем реестр это как-раз dconf, а не выпиленный gconf. gconf хранил конфигурацию в XML, dconf делает это в своем бинарном формате
Или можно компилировать с `-std=c2x` :)
Моим первым смартфоном был Xperia S. До сих пор с ужасом как он тупил :) И это был флагман.
В линуксе ещё ни одного драйвера на расте нет, пока мержатся только биндинги к внутренним API ядра.
Радиация, температура (днём на Луне пздц как жарко, ночью пздц как холодно), перегрузки и вибрация при запуске. Вероятно хорошую камеру которая на это рассчитана сделать можно но хз какой у нее будет вес по сравнению с плохой. Ну и приоритет у них на научные приборы - камера работающая в видимом диапазоне для науки не очень полезна. Если у тебя ограниченный бюджет то зачем тратиться на разработку камеры для красивых картинок в Инстаграм если можно потратиться на научные приборы? А красивые картинки можно и с какой-нибудь инфракрасной камеры сделать и раскрасить, все равно никто не поймет разницы (NASA так испокон веку делает).
25 вышла из строя во время орбитального маневра, ещё до посадки.
Пробежался еще раз по proposal'у (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2300r7.html). Есть scheduler который создает отдельный тред и работает только с ним, но тред пула нет:
> 10. A specific thread pool implementation is omitted, as per LEWG direction.
Там вроде как будут только базовые абстракции, конкретных реализаций экзекуторов (в том числе тредпула) не будет.
del (хз как удалить коммент)
У рефлексии насколько я помню "выгорел" автор. Так что если кто-то другой не возьмётся, она так и будет висеть в вакууме. Пока желающих нет.
Хз насчёт sdkmanager но для сборки приложений уже некоторое время требуется java 17. Даже если sdkmanager это пока не требует то он точно может работать с 17 без проблем. Да и она сейчас последний lts.
Для разработки опенсорсных проектов жетбрейнс выдают лицензию бесплатно (не только на идею но и на другие платные ide).
Смотря что значит "по умолчанию")
Строки изнутри в UTF-16 кодировке (но понятное дело что получить строку можно из данных в любой кодировке которая может конвертироваться в UTF-16).
На консоль выводятся байты в системной "легаси" консольной кодировке (Console.OutputEncoding в .NET). По умолчанию это не UTF-8 а до-юникодная DOS кодировка (зависит от языка, на русском это CP866). Можно самому заменить на UTF-8 но тогда другая сторона (например IDE) тоже должна ожидать именно UTF-8, как-то об этом договориться "на лету" нельзя. Многие программы могут работать только с системной кодировкой, другие только с UTF-8.
Возможно имелось в виду что винда не может выводить в консоль utf-8 текст без плясок с бубном (до этого автор упоминал проблемы с кодировкой при выводе на консоль). Но в случае передачи строки в C# можно использовать UTF-8, C# умеет с ней работать.
У span как раз-таки, в отличие от контейнеров, проверок выхода за границы нет - функция at() отсутствует.
На сайтах можно сделать точно такую же монетизацию что и в приложениях (то что многие боятся это делать потому что сайты были раньше и без монетизации уже другая история). Идея на то и идея что ее невозможно навязать технически. WWW был свободен отнюдь не потому что его нельзя сделать несвободным.
Согласен, я имел в виду что современные асинхронные подходы сами по себе не решают подобных проблем с производительностью. Если ты запускаешь 10 тысяч мелких асинхронных операций из ui треда которые потом возвращаются в обратно в ui тред то не имеет значения какой подход используется - самописанные очереди сообщений, async/await, джавовские экзекуторы - это приведет к тем же проблемам.
Асинхронные вызовы точно также приведут к обмену сообщениями между потоками (если команды на чтение файлов приходят из ui треда) - просто это будет происходить "под капотом". Никакой магии в них нет.
Странно, у меня при компиляции с C++11 (GCC 6.3.1) это все равно int.
А вообще, что им мешало сделать так:
Заодно это решило бы проблему невозможности в некоторых случаях вызова конструктора копирования при использовании универсальной™ инициализации.