Здесь ничего и близко нет к тому, о чем я вам говорю.
А как называется переход от «язык позволяет выражать такие-то вещи [невозможность делить на ноль]» к «а чего тогда на нём не пишут $X, где эти вещи не являются определяющим фактором»?
Чем это отличается от перехода от «язык позволяет выражать такие-то вещи [более легко оптимизируемые программы]» к «а чего тогда на нём не пишут $Y, где эти вещи не являются определяющим фактором»?
Здесь есть несколько неявных пресуппозиций, конечно, но я уверен, у вас получится назвать, с какой именно вы несогласны, если вы скажете, что принципиальные отличия таки есть.
Сперва вы говорили про то, что C/C++ один большой unsafe, после чего перешли к более безопасным языкам.
Как там говорили великие? А, во:
Здесь ничего и близко нет к тому, о чем я вам говорю. Как по мне, так это какое-то говно, к которому я не имею никакого отношения от слова совсем. Но вы что-то за меня додумываете и потом с этим же додуманным старательно сражаетесь, да еще и приписывая подмены мне.
Впрочем, да, если брать исходный комментарий не только в том месте, к которому вы «ответили», то да, сравнение C++ с другими языками там есть. Правда, на том же расте пишут и ОС, и браузеры. Сколько там нового кода в андроиде на плюсах, а сколько — на расте?
Тогда может не надо обвинять собеседника в собственных грехах? Вы делаете подмены, вы же от меня просите объяснить вам не прибегая к подменам.
Я вам показываю аналогией, как ваш «аргумент» выглядит в другом контексте. В каком месте это мой грех, если моя цель — перенести структуру вашего «аргумента» на, надеюсь, понятный вам контекст?
Но судя по тому, что некорректность вы таки увидели, половина дела сделана. Осталась вторая половина — чтобы вы увидели то же самое в ваших исходных словах.
Где-то здесь. Где вы заговорили про более другие языки.
Я сравнил этот более другой язык с хаскелем (на котором был предыдущий пример), потому что в хаскеле система типов недостаточно выразительна.
Перевод темы с “бекенда веб-сайтов” на “плюсы быстрее рубей или питона” вообще еще “не подмена” или же уже “подмена”?
Подмена, конечно. Я же даже N комментариями выше начал с «настолько же», потому что разговор выглядел так: — Другой чувак: UB при делении на ноль универсально. — Я: нет, вот пример. — Вы: а чего тогда на этих языках не пишут ОС и браузеры?
Это вообще ничем не отличается по сути от гипотетического: — Другой чувак: питон так же быстр, как C++. — Вы: нет, вот пример. — Я: а чего тогда на C++ не пишут бекенды?
Плюсы отбивают возможность видеть аналогии, или что?
Нет. Это стандартная отмазка людей, которые не хотят строить цельную модель мира.
Например если мы программируем что-то по микросекундам мы должны корректно совмещать дискретное и непрерывное.
А противоречия здесь в чём?
А указатели изначально противоречивы
Противоречиво только желание относиться к указателям просто как к числам (как это принято в сишной культуре), а потом хотеть писать оптимизирующие компиляторы или достаточно сильный статический анализ (где такое отношение не работает).
компилятор может сказать “проверим реальный адрес, если надо - обработаем первое значение отдельно, дальше гоним SIMD”
Хороший поинт. Но, похоже, ему проще взять тот же MOVUPS и невыровненные аналоги, чем генерировать тяжёлый и потенциально ненужный обработчик головы и хвоста массива.
Ну, может, специфика моих вещей, но в написанном мной коде (а я за соблюдением стандарта слежу почти ОКРно) компилятор такие обработчики не делает.
В x86 есть SIMD инстукции которые требуют выравнивания и кидают аппаратное исключение, если операнд не выровнен.
У подавляющего большинства SIMD-инструкций, требующих выравнивание до #GP, это самое выравнивание — ≥16 байт, что больше естественного выравнивания всех стандартных типов и их агрегатов (если явно не указывать alignas). Поэтому компилятору от (не)выровненности ни холодно, ни жарко — для среднего векторизуемого кода он не может ей воспользоваться. Да и разницы между теми же MOVAPS и MOVUPS нет для процессора, покуда они не переходят границы кэш-линии.
Есть инструкции загрузки/выгрузки MXCSR, которые его на самом деле требуют (а иначе — #GP), но что они у вас делают в hot path?
Ну давайте посмотрим на эти легальные, безопасные инструменты.
Кстати, про эти легальные, безопасные инструменты даже взрослые дядьки пишут, вроде Шона Пэрента в конференциях про то, что std::optional поощряет небезопасные паттерны (operator* — unchecked), или другого шона, Бакстера в P3390R0 (который пишет то ж про std::expected , потому что создатели стандарта сделали ту же ошибку).
Вместо опасных кастов указателей, от которых Хабетс страдает в своем коде, есть std::span
Который может указывать вникуда.
Кстати, непонятно, как это спасает от кастов. Как это спасает от кастов, а?
или встроенные макросы выравнивания.
Щито?
Причём тут макросы (?) выравнивания (??) ?
ckd_add
Угу, «since C++26» (чё там, userver из соседнего треда уже на C++20-то перешёл?), и по удобству синтаксиса bool ckd_add(T *result, T l, T r) почти на уровне обычного плюсика (который на самом деле мог бы просто быть монадическим!)
Концепция Профилей (Profiles): Сейчас в комитете по стандартизации ISO активно обсуждается
активно обсуждается
мемес.про.consideration.watch.png
Внедрение типов-оберток: Вместо изменения базовых типов вроде int или *pointer, комитет добавляет в стандарт безопасные альтернативы (например, std::span, функции безопасной арифметики).
Так типы-обёртки или bool ckd_add(T *result, T l, T r)? C++ — это не функциональный язык, здесь под типами-обёртками понимают обычные типы. Да и в функциональных языках, в принципе, тоже.
UB (неопределенное поведение) в той или иной форме есть во всех языках программирования
Надо ли избегать ремни безопасности потому, что в единичных случаях они делают хуже? Верно ли, что ремни безопасности на самом деле не дают безопасности, потому что иногда люди в них застревают и не успевают выбраться из горящей/тонущей машины?
за исключеним математических (Coq, Agda, итд).
Которые и надо использовать для систем, где надёжность важна.
У меня не так давно была очень смешная бяка в корутинах (там вообще в плюсах очень легко выстрелить себе в ноги), где ни один из этих флагов не помог. Более того, без них падало, а с ними — нет.
Ещё для работы с ними по-нормальному надо пересобирать с ними все зависимости, а это может быть больно.
Так, а в чём в данном случае вина именно С/С++? Какой язык предотвратит невыровненный доступ к памяти?
В safe-подмножествах нормальных языков это сделать невозможно. А «C/C++» — там вся программа один большой unsafe, поэтому пристально смотреть нужно тоже на её всю целиком.
Я даже более страшную вещь скажу, банальное умножение int на int в 99% случаев двух взятых произвольных int'ов вызовет переполнение.
Вопрос в том, является ли это UB.
И это тоже универсально.
UB универсально?
λ> 10 `div` 0
*** Exception: divide by zero
Но можно пойти дальше, в более другие языки!
Main> 10 `safeDiv` 0
Error: Can't find an implementation for IsSucc 0.
(Interactive):1:1--1:15
1 | 10 `safeDiv` 0
^^^^^^^^^^^^^^
Функция деления требует доказательства, что делитель — не ноль. Такого доказательства она не находит (потому что доказательства, что ноль — не ноль, существует), поэтому код просто не компилируется.
Однако если он равен нулю или любому другому определённому числовому значению, то и поведение, с точки зрения стандарта и языка, должно быть определённым: обращение к памяти по заданному им адресу.
Должно.
А на практике — нифига. Use-after-free — UB (хотя адрес — вон он, только что валидный был, а между free и текущей инструкцией ничего в память не писалось, отвечаю!). Алиасинг — UB (хотя адрес — вон он, до сих пор валидный, просто в переменной другого типа).
С pointer provenance уже тоже разобрались? Абсолютно классический пример:
int x = 1, y = 2;
int *p = &x + 1;
int *q = &y;
if (p == q) {
*p = 10; // что тута происходит???
}
Стандартсмены 25 лет (с DR-260, 2001-й год) даже не могут определиться, UB здесь или нет по стандарту сишки. Это уже не UB, это уже мета-UB. Фрактал UB.
Стандарт пишется для того чтобы эти возможности ЛЮБОЙ аппаратной платформы использовались самым эффективным образом, именно поэтому стандарт избегает регламентировать поведение там где это может повлиять на эффективность кода для самых распространенных конструкций программирования.
Тогда это могло бы быть implementation-defined behavior, а не undefined behavior. Стандарт мог бы не регламентировать конкретное поведение, но требовать этой регламентации от каждой конкретной реализации.
Олсо, это автоматически означает, что писать кроссплатформенный код с использованием этих возможностей ЛЮБЫХ аппаратных платформ нельзя. (впрочем, там квантор ∀ всплывает наверх, но я не знаю, как это написать по-русски)
Такой вот портабельный язык Шрёдингера. Или, скорее, язык с принципом неопределённости Гейзенберга: можно либо портабельно, либо производительно, но не вместе. И вы ещё никогда не знаете, писал ли автор соседней либы, TU и функции портабельно или производительно, и вероятность ошибиться больше ħ/2 в естественных единицах.
На конкретной платформе и с определенным компилятором UB фактически невозможно - вы всегда можете проверить какое поведение будет у этого компилятора для любой кодовой конструкции.
Проблема в том, что компиляторы иногда обновляются, и их поведение в обработке UB меняется. Более того, что там компиляторы — даже сам код меняется, а небольшое шевеление кодом может повлиять на то, как именно компилятор решит его соптимизировать и воспользуется ли он здесь UB или нет, потому что оптимизации и UB — это по определению нелокальный процесс.
Более того×2, люди, страдающие от UB, пишут на сях и плюсах программы чуть сложнее хелловорлдов (в отличие от славящих сишку вы-просто-пишите-без-багов-а-с-багами-не-пишите и прочих кекспертов с опеннета и хабра обр. 2026), которые компилируются в чуть больше, чем несколько сотен строк ассемблерного листинга, поэтому «вы всегда можете проверить» нереализуемо на практике даже при фиксированном компиляторе и кодовой базе.
Офигенное предложение, короче, но на практике от него ноль толка.
Это будет просто платформо-зависимый код там где это UB по стандарту. Одна из фундаментальных задач программирования разделять и изолировать платформо-зависимый и платформо-НЕзависимый код, а не жаловаться на UB.
Только язык может этому помогать (например, имея возможность маркировать тот или иной кусок кода, скажем, как unsafe, или там м… ммм… мона… тьфу), а может мешать (потому что поверх конкретного железа наворачивается ещё семантика абстрактной машины языка, за которой ты должен следить сам без гарантий компилятора — угадайте, про какой это язык?).
Казалось бы, если у языка нет стандарта то у него, вроде бы, нет и UB, но на самом деле это значит, что язык для которого нет стандарта, это одно сплошное UB, так как его поведение нигде и никем не определено.
Это ещё одно красиво звучащее, но совершенно неприменимое на практике кекспертное «мнение»: якобы стандарт оказывается полезным.
На практике разработчики компиляторов на плюсах могут ломать поведение в последующих версиях произвольно и тихо (то есть, без ворнингов, ограничиваясь строчкой в ченджлоге — вы же читаете ченджлоги на clang и LLVM? читаете же? я это делаю каждый их релиз, наверняка все остальные программисты на плюсах тоже), покуда поломка подходит под какой-нибудь UB, и говорить «у нас лапки стандарт, идите на три буквы ISO/IEC 14882». Разработчики компиляторов дружественных к пользователю языков себе такого позволить не могут независимо от наличия стандартов.
Про-оружейных юрисдикций довольно мало, а с учётом других факторов совсем грустно получается.
Сценарий, что все эти факторы, скажем так, несколько сравняются в весьма обозримом будущем с каким-нибудь Уругваем, в моей модели мира становится всё более вероятным, увы.
Собсна, Уругвай уже по оружию свободнее Нью-Йорка, например: в нём shall-issue для домашнего хранения, тогда как в NYC оно may-issue (де-юре shall-issue, но там требования уровня «два нотариально заверенных письма с референсами от неродственников и от всех живущих с вами взрослых» и какие-то дикие сроки ожидания, плюс рассмотрение good moral character обрабатывающим заявку госбюрократом, что делает это де-факто may-issue).
Позвольте не согласиться с вами. Да, цена на читалки высока (у нас в семье их 3, 2 в постоянном использовании и одна старенькая про запас). Но высокая цена за качественную модель обясняется её долговечностью: какой из нынешних смартфонов протянет хотя бы 5 лет?
Позволю не согласиться в ответ.
OnePlus 5T у меня протянул до то ли прошлого, то ли позапрошлого года — этак 7 лет ему было, и вполне себе бодрячком, что по аккумулятору, что по отзывчивости. Можно было бы поставить линейку и вообще ещё следующие несколько лет радоваться, если бы я его не уронил.
А вот Onyx Boox Max 2, что ли, купленная в 2019-м, уже в 2023-м перестала заряжаться (техсаппорт по логам сказал, что контроллер заряда накрылся), а ремонтники (единственные на все Штаты) её тупо зажали, но это отдельная история.
Хотя читалку я в среднем заряжал раз в 3-4 недели, а смарт — раз в неделю.
Сейчас у всех потоковых сервисов уже есть Flac, минимум CD качество на всех устройствах.
Когда я пару лет назад потыкал в spotify — гаплесса там не было точно, и, судя по загруженности канала, флака тоже.
И интеграция почти со всеми современными AV ресиверами и стримерами. Плюс умные колонки туда-же.
У меня нет ни одной из этих железок, и я не знаю, зачем они мне нужны.
То есть, хорошо, что они нужны вам, но не для всех это аргумент хоть какого-то уровня важности.
Треки пропадают крайне редко.
Для меня достаточно возможности + экстраполяции опыта других людей + экстраполяции собственного опыта с нетфликсом (когда я им пытался пользоваться по переезде в разные западные страны).
Ещё можете случайно пропасть уже лично вы, выйди из зоны покрытия сервиса при переезде в другую страну, например. Я за 15 лет побывал в трёх странах, и, глядя на праймериз тут, есть неиллюзорный шанс, что это не конец.
Зависимость от интернета? Там есть офлайн режим и можно скачать любую подборку. Можно накачать музыку и 30 дней в онлайн вообще не выходить.
Ну вот я и накачал музыку, просто не через tidal :]
Можно не выходить в онлайн хоть 30 дней, хоть 300, и не думать о том, что ты захочешь слушать следующие 30 дней.
Выбор проигрывателя? Зачем? На смартфоне - это бессмысленно, на ресиверах свой проигрыватель и настройка звука.
На ПК, например.
На смартфоне — на самом деле тоже осмысленно, потому что мне удобно определённое поведение (и его настраиваемость) на уровне «что делать, когда закончился альбом», «как упорядочивать исполнителей», и так далее. Когда я энное время назад потыкал в разные проигрыватели под андроид — ни один из них не поддерживал достаточно близко ту же логику, которую поддерживал обычный rockbox (с которым я в итоге хожу до сих пор, и которая мне привычна этак с 2006-го года).
У меня плеер A&K на древнючем андроиде с маломощным процессором и на нём Tidal прекрасно работает, это к требованию к смартфонному железу.
Обычно «УМВР» говорят линуксоиды вроде меня в тредах про линукс :]
У меня на купленной за 80 баксов мотороле запуск google mail занимает иногда секунд 15-20, а переключение с браузера на google sheets нередко приводит к выгрузке только что открытой страницы из браузера. Я вот что-то не думаю, что у меня тоже всё будет работать, и грузить эту железку ещё и музыкой мне точно не хочется.
Отсутствие динамиков и физической возможности порадовать окружающих своим музыкальным вкусом, если вдруг наушники из джека выдернутся — тоже весьма сильный плюс, к слову.
Качать с торрента вы всё равно качаете альбом, а не подборку того-же Spotify.
А как называется переход от «язык позволяет выражать такие-то вещи [невозможность делить на ноль]» к «а чего тогда на нём не пишут $X, где эти вещи не являются определяющим фактором»?
Чем это отличается от перехода от «язык позволяет выражать такие-то вещи [более легко оптимизируемые программы]» к «а чего тогда на нём не пишут $Y, где эти вещи не являются определяющим фактором»?
Здесь есть несколько неявных пресуппозиций, конечно, но я уверен, у вас получится назвать, с какой именно вы несогласны, если вы скажете, что принципиальные отличия таки есть.
Как там говорили великие? А, во:
Впрочем, да, если брать исходный комментарий не только в том месте, к которому вы «ответили», то да, сравнение C++ с другими языками там есть. Правда, на том же расте пишут и ОС, и браузеры. Сколько там нового кода в андроиде на плюсах, а сколько — на расте?
Я вам показываю аналогией, как ваш «аргумент» выглядит в другом контексте. В каком месте это мой грех, если моя цель — перенести структуру вашего «аргумента» на, надеюсь, понятный вам контекст?
Но судя по тому, что некорректность вы таки увидели, половина дела сделана. Осталась вторая половина — чтобы вы увидели то же самое в ваших исходных словах.
Я сравнил этот более другой язык с хаскелем (на котором был предыдущий пример), потому что в хаскеле система типов недостаточно выразительна.
Подмена, конечно. Я же даже N комментариями выше начал с «настолько же», потому что разговор выглядел так:
— Другой чувак: UB при делении на ноль универсально.
— Я: нет, вот пример.
— Вы: а чего тогда на этих языках не пишут ОС и браузеры?
Это вообще ничем не отличается по сути от гипотетического:
— Другой чувак: питон так же быстр, как C++.
— Вы: нет, вот пример.
— Я: а чего тогда на C++ не пишут бекенды?
Плюсы отбивают возможность видеть аналогии, или что?
Где я в этой ветке сравнивал C++ хоть с чем-то?
Попробуйте объяснять не подменами — может получиться!
Хм, C++-ники никогда не утверждали, что плюсы быстрее рубей или питона?
Или вы не это имели в виду?
Настолько же, насколько плюсы «тупо неэффективны» потому, что для бекенда веб-сайтов чаще всего выбирают не C++.
А противоречия у них в чём, из которых бы мир состоял?
Памятуя о наших прошлых встречах, думаю, у меня с этими тремя состоялся бы более конструктивный разговор, чем у вас, к слову, ну да ладно.
В экономике. Цена ошибки в браузере, ОС или офисном пакете меньше цены разработки на верифицированном языке.
Я так-то и обычные тесты не везде писал так-то, потому что не везде цена написания тестов покрывается их профитом.
Нет. Это стандартная отмазка людей, которые не хотят строить цельную модель мира.
А противоречия здесь в чём?
Противоречиво только желание относиться к указателям просто как к числам (как это принято в сишной культуре), а потом хотеть писать оптимизирующие компиляторы или достаточно сильный статический анализ (где такое отношение не работает).
Но это не аксиома.
Хороший поинт. Но, похоже, ему проще взять тот же MOVUPS и невыровненные аналоги, чем генерировать тяжёлый и потенциально ненужный обработчик головы и хвоста массива.
Ну, может, специфика моих вещей, но в написанном мной коде (а я за соблюдением стандарта слежу почти ОКРно) компилятор такие обработчики не делает.
Общего с тем, что я пишу, только два слова: «на практике», причём чисто синтаксически.
Поэтому вам таки кажется.
У подавляющего большинства SIMD-инструкций, требующих выравнивание до #GP, это самое выравнивание — ≥16 байт, что больше естественного выравнивания всех стандартных типов и их агрегатов (если явно не указывать
alignas). Поэтому компилятору от (не)выровненности ни холодно, ни жарко — для среднего векторизуемого кода он не может ей воспользоваться. Да и разницы между теми же MOVAPS и MOVUPS нет для процессора, покуда они не переходят границы кэш-линии.Есть инструкции загрузки/выгрузки MXCSR, которые его на самом деле требуют (а иначе — #GP), но что они у вас делают в hot path?
Ну давайте посмотрим на эти легальные, безопасные инструменты.
Кстати, про эти легальные, безопасные инструменты даже взрослые дядьки пишут, вроде Шона Пэрента в конференциях про то, что
std::optionalпоощряет небезопасные паттерны (operator*— unchecked), или другого шона, Бакстера в P3390R0 (который пишет то ж проstd::expected, потому что создатели стандарта сделали ту же ошибку).Который может указывать вникуда.
Кстати, непонятно, как это спасает от кастов. Как это спасает от кастов, а?
Щито?
Причём тут макросы (?) выравнивания (??) ?
Угу, «since C++26» (чё там, userver из соседнего треда уже на C++20-то перешёл?), и по удобству синтаксиса
bool ckd_add(T *result, T l, T r)почти на уровне обычного плюсика (который на самом деле мог бы просто быть монадическим!)мемес.про.consideration.watch.png
Так типы-обёртки или
bool ckd_add(T *result, T l, T r)? C++ — это не функциональный язык, здесь под типами-обёртками понимают обычные типы. Да и в функциональных языках, в принципе, тоже.Надо ли избегать ремни безопасности потому, что в единичных случаях они делают хуже? Верно ли, что ремни безопасности на самом деле не дают безопасности, потому что иногда люди в них застревают и не успевают выбраться из горящей/тонущей машины?
Которые и надо использовать для систем, где надёжность важна.
У меня не так давно была очень смешная бяка в корутинах (там вообще в плюсах очень легко выстрелить себе в ноги), где ни один из этих флагов не помог. Более того, без них падало, а с ними — нет.
Ещё для работы с ними по-нормальному надо пересобирать с ними все зависимости, а это может быть больно.
В safe-подмножествах нормальных языков это сделать невозможно. А «C/C++» — там вся программа один большой unsafe, поэтому пристально смотреть нужно тоже на её всю целиком.
Вопрос в том, является ли это UB.
UB универсально?
Но можно пойти дальше, в более другие языки!
Функция деления требует доказательства, что делитель — не ноль. Такого доказательства она не находит (потому что доказательства, что ноль — не ноль, существует), поэтому код просто не компилируется.
Должно.
А на практике — нифига. Use-after-free — UB (хотя адрес — вон он, только что валидный был, а между
freeи текущей инструкцией ничего в память не писалось, отвечаю!). Алиасинг — UB (хотя адрес — вон он, до сих пор валидный, просто в переменной другого типа).С pointer provenance уже тоже разобрались? Абсолютно классический пример:
Стандартсмены 25 лет (с DR-260, 2001-й год) даже не могут определиться, UB здесь или нет по стандарту сишки. Это уже не UB, это уже мета-UB. Фрактал UB.
Это просто дно.
Тогда это могло бы быть implementation-defined behavior, а не undefined behavior. Стандарт мог бы не регламентировать конкретное поведение, но требовать этой регламентации от каждой конкретной реализации.
Олсо, это автоматически означает, что писать кроссплатформенный код с использованием этих возможностей ЛЮБЫХ аппаратных платформ нельзя. (впрочем, там квантор ∀ всплывает наверх, но я не знаю, как это написать по-русски)
Такой вот портабельный язык Шрёдингера. Или, скорее, язык с принципом неопределённости Гейзенберга: можно либо портабельно, либо производительно, но не вместе. И вы ещё никогда не знаете, писал ли автор соседней либы, TU и функции портабельно или производительно, и вероятность ошибиться больше ħ/2 в естественных единицах.
Проблема в том, что компиляторы иногда обновляются, и их поведение в обработке UB меняется. Более того, что там компиляторы — даже сам код меняется, а небольшое шевеление кодом может повлиять на то, как именно компилятор решит его соптимизировать и воспользуется ли он здесь UB или нет, потому что оптимизации и UB — это по определению нелокальный процесс.
Более того×2, люди, страдающие от UB, пишут на сях и плюсах программы чуть сложнее хелловорлдов (в отличие от славящих сишку вы-просто-пишите-без-багов-а-с-багами-не-пишите и прочих кекспертов с опеннета и хабра обр. 2026), которые компилируются в чуть больше, чем несколько сотен строк ассемблерного листинга, поэтому «вы всегда можете проверить» нереализуемо на практике даже при фиксированном компиляторе и кодовой базе.
Офигенное предложение, короче, но на практике от него ноль толка.
Только язык может этому помогать (например, имея возможность маркировать тот или иной кусок кода, скажем, как
unsafe, или там м… ммм… мона… тьфу), а может мешать (потому что поверх конкретного железа наворачивается ещё семантика абстрактной машины языка, за которой ты должен следить сам без гарантий компилятора — угадайте, про какой это язык?).Это ещё одно красиво звучащее, но совершенно неприменимое на практике кекспертное «мнение»: якобы стандарт оказывается полезным.
На практике разработчики компиляторов на плюсах могут ломать поведение в последующих версиях произвольно и тихо (то есть, без ворнингов, ограничиваясь строчкой в ченджлоге — вы же читаете ченджлоги на clang и LLVM? читаете же? я это делаю каждый их релиз, наверняка все остальные программисты на плюсах тоже), покуда поломка подходит под какой-нибудь UB, и говорить «у нас
лапкистандарт, идите натрибуквы ISO/IEC 14882». Разработчики компиляторов дружественных к пользователю языков себе такого позволить не могут независимо от наличия стандартов.Сценарий, что все эти факторы, скажем так, несколько сравняются в весьма обозримом будущем с каким-нибудь Уругваем, в моей модели мира становится всё более вероятным, увы.
Собсна, Уругвай уже по оружию свободнее Нью-Йорка, например: в нём shall-issue для домашнего хранения, тогда как в NYC оно may-issue (де-юре shall-issue, но там требования уровня «два нотариально заверенных письма с референсами от неродственников и от всех живущих с вами взрослых» и какие-то дикие сроки ожидания, плюс рассмотрение good moral character обрабатывающим заявку госбюрократом, что делает это де-факто may-issue).
Позволю не согласиться в ответ.
OnePlus 5T у меня протянул до то ли прошлого, то ли позапрошлого года — этак 7 лет ему было, и вполне себе бодрячком, что по аккумулятору, что по отзывчивости. Можно было бы поставить линейку и вообще ещё следующие несколько лет радоваться, если бы я его не уронил.
А вот Onyx Boox Max 2, что ли, купленная в 2019-м, уже в 2023-м перестала заряжаться (техсаппорт по логам сказал, что контроллер заряда накрылся), а ремонтники (единственные на все Штаты) её тупо зажали, но это отдельная история.
Хотя читалку я в среднем заряжал раз в 3-4 недели, а смарт — раз в неделю.
Когда я пару лет назад потыкал в spotify — гаплесса там не было точно, и, судя по загруженности канала, флака тоже.
У меня нет ни одной из этих железок, и я не знаю, зачем они мне нужны.
То есть, хорошо, что они нужны вам, но не для всех это аргумент хоть какого-то уровня важности.
Для меня достаточно возможности + экстраполяции опыта других людей + экстраполяции собственного опыта с нетфликсом (когда я им пытался пользоваться по переезде в разные западные страны).
Ещё можете случайно пропасть уже лично вы, выйди из зоны покрытия сервиса при переезде в другую страну, например. Я за 15 лет побывал в трёх странах, и, глядя на праймериз тут, есть неиллюзорный шанс, что это не конец.
Ну вот я и накачал музыку, просто не через tidal :]
Можно не выходить в онлайн хоть 30 дней, хоть 300, и не думать о том, что ты захочешь слушать следующие 30 дней.
На ПК, например.
На смартфоне — на самом деле тоже осмысленно, потому что мне удобно определённое поведение (и его настраиваемость) на уровне «что делать, когда закончился альбом», «как упорядочивать исполнителей», и так далее. Когда я энное время назад потыкал в разные проигрыватели под андроид — ни один из них не поддерживал достаточно близко ту же логику, которую поддерживал обычный rockbox (с которым я в итоге хожу до сих пор, и которая мне привычна этак с 2006-го года).
Обычно «УМВР» говорят линуксоиды вроде меня в тредах про линукс :]
У меня на купленной за 80 баксов мотороле запуск google mail занимает иногда секунд 15-20, а переключение с браузера на google sheets нередко приводит к выгрузке только что открытой страницы из браузера. Я вот что-то не думаю, что у меня тоже всё будет работать, и грузить эту железку ещё и музыкой мне точно не хочется.
Отсутствие динамиков и физической возможности порадовать окружающих своим музыкальным вкусом, если вдруг наушники из джека выдернутся — тоже весьма сильный плюс, к слову.
Эээ… ну, да? Я и слушаю альбомами как минимум.