This is a proposal for a single, standard environment variable that plainly and unambiguously expresses LACK OF CONSENT by a user of that software to any of the following:
ad tracking
usage reporting, anonymous or not
automatic update phone-home
crash reporting
non-essential-to-functionality requests of any kind to the creator of the software or other tracking services
не вижу в вашем примере ни ошибки в данных ни проблемы с типами. Вам лишь нужно объявить тип, который определяет свои арифметические операции, операции перевода в другую валюту. Они вполне могут возвращать ошибку - какую, исключение, код возврата или что угодно другое - это уже вам выбирать что лучше подходит.
Более того, это настолько хорошо зарекомендовало себя на практике, что в C++26 будет т.н. hardering для стандартной библиотеки.
насколько я знаю, std::vector::at не имеет ничего общего к hardening. Hardening это как раз ассерт в std::vector::operator[], а не исключение в at.
Зато я использую регулярно
Зачем вы его используете? В какой ситуации?
И что делать Ване? Ведь ошибку допустил не он.
Ваня должен декларировать интерфейс - возвращает элемент если индекс корректный и, например, UB если неккоретный. Но исключение тоже выглядит как валидный вариант (std::vector::at). Так же выглядит и возврат std::optional. Это лишь вопрос реализации.
Значает ли “ваше понимание”, что в RELEASE данные на входе в std::vector::at проверять не нужно?
В at нужно, потому что в этом его смысл - таким его придумали и стандартизировали. В operator[] - не нужно. Или, если точнее, человек который компилирует/пишет код может принять решение что делать в случае assert - C++26 контракты позволяют выбрать вариант поведения. Того же эффекта можно добиться и реализацией своих ассертов.
то зачастую программисты просто подавляют такие предупреждения static_cast-ом без реальных проверок.
Ну если мы пришли к тому что не верим в добросовестность своих же коллег, то нас уже ничто не защитит против *(int*)0xDEADBEEF
… что код можно протестировать и найти/устранить все допущенные ошибки в ходе этого процесса. Грубо говоря “пиши правильно и ошибок у тебя не будет”.
Нет, скорее придерживаюсь взгляда, грубо говоря, “пиши правильно и ошибок у тебя не будет, а если будут - сделаешь хотфикс".
Но я не уверен что это верно. Не уверен что так можно создавать надежный софт. Я довольно неопытен в разработке ПО.
А метод std::vector::at использует исключения для чего?
это нужно спрашивать у людей который его предложили в стандарт. Я его ни разу не использовал и плохо представляю ситуацию где это нужно.
А получение методом std::vector::at неверного индекса – это исключительная ситуация или где?
в моем понимании это должен быть ассерт (т.е. ошибка программиста), что и делает std::vector::operator[]. Но кто-то может использовать это и как исключительную ситуацию, если для него это подходящее поведение.
то конвертация из знакового в беззнаковый проблему не решает от слова совсем.
по-моему отлично решает. С беззнаковым вам компилятор говорит - иди проверь что у тебя правда беззнаковый и конвертируй. Т.е. программист будет обязан это сделать. Со знаковым он просто забудет об этом или будет уверен что не допустил ошибку в предыдущем коде и передаст как есть. Т.е. по сути контроль ошибки переходит из конструктора в код вызывающий его.
По-моему вы используете исключения для обработки ошибок. Они нужны не для этого. Исключения нужны, извиняюсь, для исключительных ситуаций. Обычно это что-то связанное с IO. В вашем же примере вы их используете чтобы проверить “правильные ли данные мне передали”. Это должно быть обработкой ошибки, раз вы не доверяете тому кто ваам их передает. А еще лучше - используйте систему типов для предотвращения возможности таких ошибок, например unsigned.
так какой у вас аргумент против отладчика? то что сервер высоконагруженный? так себе довод.
Вы рассматривали rr - record repeat дебаггер? Можно однин раз записать то как воспроизводится ошибка, а потом дебажить идентичное исполнение, даже адреса будут такие же. Например, если где-то портятся данные, можно поставить бряк на момент когда они испорчены, поставить watch/бряк на момент записи в них и запустить reverse continue - в итоге последовательно пройтись по моментам когда туда были записаны некорректные данные.
Не считаю что логи бесполезны. Логи нужны и автор статьи этого не отрицал. Он говорил про printf-дебаггинг.
Но то что дебаггер подходит только для простых случаев… большое заблуждение
Не понимаю почему проблемы с ощущением своей ценности на работе у вас появились сейчас - когда пришел ИИ. В условиях компании, которую вы описали, что до ИИ что после я бы ощущал себя печатными станком который просто выполняет задачи.
похоже вы и @Sazonov немного о разном. Коммит в git и правда определяет конкретное состояние рабочей директории. В этом вы правы. Но как git внутренне хранит это? Об этом и говорит @Sazonov - git не хранит 5 копий рабочей директории на 5 коммитом. Он хранит только дельты между ними
Пять процентов ошибок. Звучит как отличный KPI, если подумать. Мой предсказатель веток в жизни (он же интуиция) работает сильно хуже.
а вы на одних и тех же данные сравниваете? человек отлично видит паттерны вроде 110110110. Предсказатель ветвлений это удивительно, но интуиция человека порой кажется просто волшебством
В этом‑то и парадокс: если вам надо описать задачу исполнителю, вы должны обладать некоторой долей экспертности в его сфере, чтобы грамотно донести задачу и получить желаемый результат.
Не совсем так. Вам не нужно уметь программировать чтобы сказать "я хочу чтобы при нажатии на эту кнопку делалось то-то и то-то". Грубо говоря - вам нужна экспертность только в предметной области (но не в программировании, если конечно оно само не является предметной областью). Далее вы описываете исполнителю (программисту) что вы хотите получить, а он уже подумает как это сделать.
Разница как будто в том, что ИИ сейчас подхалимничает. Программист может прямо сказать - это сейчас трудновыполнимо или на это понадобится столько то времени. А ИИ просто начнет делать выписывая тысячи строк кода в пустоту просто потому что вы попросили. ИИ вряд ли скажет - такое требование не ложится в архитектуру приложения, нужно подобрать другое решение. Но это, думаю, изменится в будущем.
Мое последнее предложение не было направлено конкретно вам. Скорее мои ощущения на общие настроения по этой теме. Так что извиняюсь, если приняли на свой счет.
Если не очевидно: проблема в частоте этих перечисленных приёмов
Это не очевидно. Вы сказали что статья была отредактирована после вашего коммента. Возможно поэтому мне и не бросилось ничего в глаза при прочтении.
Чем вам вообще человеческий стиль не нравится? Или вы из числа тех, кто его стесняется?
Отнюдь, просто то что вы называете "машинным стилем" для меня обычный человеческий текст. Я имею ввиду - если это плохо написано, то и человек так же пишет. Короче, это на тему качества текста в общем, а ИИ тут не причем.
PS. Заметил что вы редактор. Возможно у вас есть биас на эту тему. Наверняка вам в тексте намного легче угадываются паттерны, которые вы описали в прошлом комменте. Мне, как обычному читателю, это все не так очевидно.
За примерами можете обратиться к художественной литературе
Сегодня читал Азимова. И у него как раз встречаются повторения, что комментатор выше определил как "машинный стиль"
Да, представьте, люди умеют красивые тексты!
Да, ладно. А теперь подумайте, будет ли кто-то выписывать целую тираду если человек напишет в "машинном стиле" - вряд ли. Мой комментарий к тому что и человек и ИИ присущ "машинный стиль", но факт его наличия используют для доказательства что статья написана ИИ -> дискредитации статьи т.к. она написана ИИ (не конкретно @atomlib, я про настроения в общем).
не только третьим лицам:
https://git.eeqj.de/sneak/consoledonottrack.com/src/branch/master/index.markdown
не вижу в вашем примере ни ошибки в данных ни проблемы с типами. Вам лишь нужно объявить тип, который определяет свои арифметические операции, операции перевода в другую валюту. Они вполне могут возвращать ошибку - какую, исключение, код возврата или что угодно другое - это уже вам выбирать что лучше подходит.
насколько я знаю,
std::vector::atне имеет ничего общего к hardening. Hardening это как раз ассерт вstd::vector::operator[], а не исключение вat.Зачем вы его используете? В какой ситуации?
Ваня должен декларировать интерфейс - возвращает элемент если индекс корректный и, например, UB если неккоретный. Но исключение тоже выглядит как валидный вариант (
std::vector::at). Так же выглядит и возвратstd::optional. Это лишь вопрос реализации.В
atнужно, потому что в этом его смысл - таким его придумали и стандартизировали. Вoperator[]- не нужно. Или, если точнее, человек который компилирует/пишет код может принять решение что делать в случае assert - C++26 контракты позволяют выбрать вариант поведения. Того же эффекта можно добиться и реализацией своих ассертов.Ну если мы пришли к тому что не верим в добросовестность своих же коллег, то нас уже ничто не защитит против
*(int*)0xDEADBEEFНет, скорее придерживаюсь взгляда, грубо говоря, “пиши правильно и ошибок у тебя не будет, а если будут - сделаешь хотфикс".
Но я не уверен что это верно. Не уверен что так можно создавать надежный софт. Я довольно неопытен в разработке ПО.
а что работает?
Иммутабельность коммитов это не упущение, а намеренно принятое решение. Погуглите зачем это нужно.
Насчёт второго id, который не меняется, - по-моему jj так делает
это нужно спрашивать у людей который его предложили в стандарт. Я его ни разу не использовал и плохо представляю ситуацию где это нужно.
в моем понимании это должен быть ассерт (т.е. ошибка программиста), что и делает
std::vector::operator[]. Но кто-то может использовать это и как исключительную ситуацию, если для него это подходящее поведение.по-моему отлично решает. С беззнаковым вам компилятор говорит - иди проверь что у тебя правда беззнаковый и конвертируй. Т.е. программист будет обязан это сделать. Со знаковым он просто забудет об этом или будет уверен что не допустил ошибку в предыдущем коде и передаст как есть. Т.е. по сути контроль ошибки переходит из конструктора в код вызывающий его.
По-моему вы используете исключения для обработки ошибок. Они нужны не для этого. Исключения нужны, извиняюсь, для исключительных ситуаций. Обычно это что-то связанное с IO. В вашем же примере вы их используете чтобы проверить “правильные ли данные мне передали”. Это должно быть обработкой ошибки, раз вы не доверяете тому кто ваам их передает. А еще лучше - используйте систему типов для предотвращения возможности таких ошибок, например unsigned.
так какой у вас аргумент против отладчика? то что сервер высоконагруженный? так себе довод.
Вы рассматривали rr - record repeat дебаггер? Можно однин раз записать то как воспроизводится ошибка, а потом дебажить идентичное исполнение, даже адреса будут такие же. Например, если где-то портятся данные, можно поставить бряк на момент когда они испорчены, поставить watch/бряк на момент записи в них и запустить reverse continue - в итоге последовательно пройтись по моментам когда туда были записаны некорректные данные.
Не считаю что логи бесполезны. Логи нужны и автор статьи этого не отрицал. Он говорил про printf-дебаггинг.
Но то что дебаггер подходит только для простых случаев… большое заблуждение
Не понимаю почему проблемы с ощущением своей ценности на работе у вас появились сейчас - когда пришел ИИ. В условиях компании, которую вы описали, что до ИИ что после я бы ощущал себя печатными станком который просто выполняет задачи.
похоже вы и @Sazonov немного о разном. Коммит в git и правда определяет конкретное состояние рабочей директории. В этом вы правы. Но как git внутренне хранит это? Об этом и говорит @Sazonov - git не хранит 5 копий рабочей директории на 5 коммитом. Он хранит только дельты между ними
а можно по подробнее об этом? хотелось бы узнать что-то новое и понять не допускаю ли таких ошибок
нет там никаких котиков :/
а вы на одних и тех же данные сравниваете?
человек отлично видит паттерны вроде 110110110.
Предсказатель ветвлений это удивительно, но интуиция человека порой кажется просто волшебством
может потому что подавляющее число людей и правда просто работают с таблицами? А самое сложное что они писали это:
Я думаю половина людей даже ни разу не использовали ЕСЛИ, не говоря уже об остальном.
Не совсем так. Вам не нужно уметь программировать чтобы сказать "я хочу чтобы при нажатии на эту кнопку делалось то-то и то-то". Грубо говоря - вам нужна экспертность только в предметной области (но не в программировании, если конечно оно само не является предметной областью). Далее вы описываете исполнителю (программисту) что вы хотите получить, а он уже подумает как это сделать.
Разница как будто в том, что ИИ сейчас подхалимничает. Программист может прямо сказать - это сейчас трудновыполнимо или на это понадобится столько то времени. А ИИ просто начнет делать выписывая тысячи строк кода в пустоту просто потому что вы попросили. ИИ вряд ли скажет - такое требование не ложится в архитектуру приложения, нужно подобрать другое решение. Но это, думаю, изменится в будущем.
Мое последнее предложение не было направлено конкретно вам. Скорее мои ощущения на общие настроения по этой теме. Так что извиняюсь, если приняли на свой счет.
Это не очевидно. Вы сказали что статья была отредактирована после вашего коммента. Возможно поэтому мне и не бросилось ничего в глаза при прочтении.
Отнюдь, просто то что вы называете "машинным стилем" для меня обычный человеческий текст. Я имею ввиду - если это плохо написано, то и человек так же пишет. Короче, это на тему качества текста в общем, а ИИ тут не причем.
PS. Заметил что вы редактор. Возможно у вас есть биас на эту тему. Наверняка вам в тексте намного легче угадываются паттерны, которые вы описали в прошлом комменте. Мне, как обычному читателю, это все не так очевидно.
Сегодня читал Азимова. И у него как раз встречаются повторения, что комментатор выше определил как "машинный стиль"
Да, ладно. А теперь подумайте, будет ли кто-то выписывать целую тираду если человек напишет в "машинном стиле" - вряд ли. Мой комментарий к тому что и человек и ИИ присущ "машинный стиль", но факт его наличия используют для доказательства что статья написана ИИ -> дискредитации статьи т.к. она написана ИИ (не конкретно @atomlib, я про настроения в общем).
а вы уверены что люди могут написать красиво?
Не вижу смысла докапываться до "это ИИ" "это человек". Важно что написано, а не как.
А половина ваших претензий... для меня вообще не машинный стиль, а то как я сам бы написал.
Короче, вместо того чтобы обсудить содержание, обсуждаем форму, и оцениваем качество тоже по форме...
смотрите, а теперь экранировать не нужно)
самый очевидный практический пример - флаги компилятору.
А вообще, тут претензия должна быть не к экранированию, а к тому что в баше все есть строки. Будь там тип Path, то проблемы не было бы
а вторым какое дело до спроса?
они ковают потому что без этого не могут - потому что делают это не ради спроса
это был сарказм...
Я имел ввиду что большая часть инструментов уже недоступна.
Из LLM - ChatGPT, Claude, Gemini уже недоступны без плясок.