А метод 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, я про настроения в общем).
А можете привести пример когда условно булеан 10 раз меняется туда и обратно. Вы в статье писали что благодаря Virtual DOM в DOM пойдет только измененное состояние. Т.е. в случае булеана может ничего не пойти, если он вернулся в конце в изначальное состояние. Случай вроде валидный и показывает зачем нужен Virtual DOM. Но где на практике такое бывает? - что одни и те же данные меняются очень часто? Это явно не кнопка
а можете в двух словах написать зачем нужен Virtual DOM? Или дать ссылку на годный ресурс?
Я из статьи понял: при любом ивенте ходить сразу в DOM дорого, поэтому создадим себе "копию" (Virtual) этого DOM и будем ее иногда пушить в реальный. В принципе звучит логично, но автор то говорит "браузеры умные и не будут перерисовывать при каждом изменении DOM", то говорит что "писать в DOM по поводу и без всё-таки дорого".
В итоге люди придумали скопировать состояние и пытаться его синхронизировать, что по моему опыту только добавляет багов.
это нужно спрашивать у людей который его предложили в стандарт. Я его ни разу не использовал и плохо представляю ситуацию где это нужно.
в моем понимании это должен быть ассерт (т.е. ошибка программиста), что и делает
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 уже недоступны без плясок.
в один день?
вы из 2021 это пишете?
А можете привести пример когда условно булеан 10 раз меняется туда и обратно.
Вы в статье писали что благодаря Virtual DOM в DOM пойдет только измененное состояние. Т.е. в случае булеана может ничего не пойти, если он вернулся в конце в изначальное состояние. Случай вроде валидный и показывает зачем нужен Virtual DOM.
Но где на практике такое бывает? - что одни и те же данные меняются очень часто? Это явно не кнопка
а можете в двух словах написать зачем нужен Virtual DOM? Или дать ссылку на годный ресурс?
Я из статьи понял: при любом ивенте ходить сразу в DOM дорого, поэтому создадим себе "копию" (Virtual) этого DOM и будем ее иногда пушить в реальный.
В принципе звучит логично, но автор то говорит "браузеры умные и не будут перерисовывать при каждом изменении DOM", то говорит что "писать в DOM по поводу и без всё-таки дорого".
В итоге люди придумали скопировать состояние и пытаться его синхронизировать, что по моему опыту только добавляет багов.
хм, видимо упустил этот момент.
Но название статьи как будто вводит в заблуждение)