Нет необходимости в бесконечных циклах, достаточно взять счетчик миллисекунд и отфильтровать его через функцию, например через sin. Тригонометрические или другие функцию вычислимые из ряда можно заменить на этот самый ряд и упростить его.
CSS Zen Garden запущен в мае 2003 года и там уже все на дивах, собственно с него я и учился. Но на каждый чих искать отдельный параметр, да еще с тучей альтернатив работающих не на каждом браузере одинаково, та еще головная боль.
В свое время я бы с удовольствием обучался простеньким примерам а-ля демосцена, но в то время даже шейдеров не было. А сейчас можно содрать страницу с shadertoy и уже учить objective C - это всегда наглядная математика, это интересно, это доступно всем и везде бесплатно, это останется на всю жизнь с человеком в какой бы он потом редактор не зашел.
Из всего того что у вас в списке есть, можно только остановится на верстке сайтов и то - это подразумевает знание тегов. Как много нужно знать в GLSL чтобы воспользоваться готовым редактором в браузере и тонной примеров?
С первыми реализациями СИ тоже было не все так гладко. Непарные pop/push (кстати говоря тоже от макрасофака) и ассемблерные вставки в больших количествах, много чего еще.
Вполне возможно что такого рода возмущения были при переходе например с ассемблера на С++. Можно даже аналогию провести, ведь пишем мы очень много мега буковок, которые превращаются в килобайты. Конечно люди с переходом от опкода на более высокоуровневый язык переставали понимать, что такое регистры флаги и прочие магические символы в виде команд, схемотехника и так далее. Ну и теперь мы имеем то что имеем. Чем это не новая абстракция более высокого уровня в своем зачатке?
Проверка на ноль в мире float/double не работает ± всегда.
Проверка на ноль работает всегда! Это компьютер. В первую очередь нужно уяснить для себя, что вы подразумеваете под этой проверкой на ноль. И когда требуется проверить именно на содержание нуля, а не бесконечно малого числа - это всегда работает.
Вторая проблема это когда вы задаете этот самый фиксированный EPS, то автоматически отсекаете возможный диапазон решений на более малый числах, когда текущая порядковая точность это позволяет. В этом и суть плавающего числа. А если вам нужен EPS, то подозреваю вам не плавающие числа нужны, а числа с фиксированной точкой.
Опять вы путаете теплое с мягким и вводите в заблуждение других. Вопрос был про "Выделить массив байт" и "А вот когда указатель p был сформирован внутри компилируемой программы", где по вашему якобы помогает start_lifetime_as. И любому знающему человеку должно быть понятно в чем разница между разными парами "выделить"/"удалить" память, поскольку это разные менеджеры/системы памяти. Что собственно и делает start_lifetime_as, отключая у неявного объекта деструктор и конструктор. Поэтому ни какое ваше "кастануть его в указатель на структуру и обратиться к полю - UB" неверно ни для одного стандарта, до тех пор пока вы явно или неявно не вызвали деструктор или конструктор и не начали оперировать с таким объектом стандартными методами.
А вот и нет. Выделить массив байт, кастануть его в указатель на структуру и обратиться к полю — это UB в плюсах независимо ни от каких выравниваний и прочего.
Во первых, а вои и да:
Since C++20, certain functions in the C++ standard library such as malloc, bit_cast, and memcpy are defined to implicitly create objects [P0593R6]. As a result, the following code is no longer undefined behaviour:
struct X { int a, b; };
X* make_x() {
X* p = (X*)malloc(sizeof(struct X)); // implicitly creates an object of type X
p->a = 1;
p->b = 2;
return p;
}
Хотя опять же это все определенные условия, при которых это можно было делать и раньше. Но
Во вторых, это утверждение по прежнему равнозначно для обоих примеров.
С чего бы тут была проблема из-за временного буфера?
Немного ошибся с переводом, но тем не менее читайте описание start_lifetime_as и того что оно на самом деле делает, а не то что вы предполагаете (ссылка у меня выше и в статье). Это то, из-за чего нельзя сначала сделать malloc, а потом delete. (чего нормальному человеку в голову не придет) Собственно это и есть те условия, обходя которые можно уйти от UB.
А вот когда указатель p был сформирован внутри компилируемой программы — тут-то UB и вылезает на свет, угрожая покорёжить программу на этапе оптимизации.
Вы понимаете что здесь точно также можно сказать что "Разумеется, если фактическое расположение и выравнивание полей соответствует ожидаемому — то reinterpret_cast работает без всякого UB." ? Кроме того также выделение памяти под объект выполнено соответствующими средствами С++. В результате эти примеры равнозначны.
И именно здесь start_lifetime_as очень даже спасает.
Видно что проблема здесь опять не в reinterpret_cast, а в том что buffer временный. Что из примера в статье выше это ни как не видно. И тут тоже можно обойтись исправлением без start_lifetime_as, копирования и UB.
Считается UB, мнения постоянно делятся и из-за этого родилось, то что родилось. Все неопределенное поведение тут завязано только на отправителе или источнике указателя p, и к текущему коду никакого отношения не имеет. Как например, если этот указатель был получен из другого языка или компилятора где char 2 байта или имеет специфическое выравнивание. То есть вся проблема из-за расплывчатого описания стандарта. В этом смысле start_lifetime_as тоже мало чем поможет. А сама пометка неопределенного поведения подразумевает что угодно. Конкретно здесь несоответственное расположение данных полям структуры SomeStruct и тому что объект, который будет использоваться как SomeStruct, на самом деле им не был.
То есть можно сделать вывод, что start_lifetime_as просто затычка, чтобы люди закончили по этому поводу спорить. Но это же ни чего не меняет. По сути тот же const SomeStruct* str = (const SomeStruct*)p. из С, который по своей природе в этом плане тоже не определен.
Из примера видно что данные получены не внутри компилированной программы. Соответственно start_lifetime_as никак не помогает. Тем более это набор байт, а не другая структура, что в принципе не дает для start_lifetime_as ни какой информации о исходном типе.
А почему не со второго? Или вы думаете, что человек с кратковременным инсультом или скачущим давлением, имея за своими плечами годы опыта не превратиться в одночасье в ничего не понимающего человека?
И потом что вы подразумеваете под своим понятием "любой код"? Он что должен на слух данные с модема читать? С вашими якобы правильными выводами попахивает троллингом.
Как я уже сказал в рамках фирм в которых я работал это вполне рабочее высказывание, мало того является одним и перефразированных мною правил. Не надо забывать что они не работают без гита и документированных постановок задач, где вполне себе доступным языком описывается все внесенные в код правки начиная с 90-x. Но даже с этим приходиться рефакторить код годами.
А вы приводите примеры из фирм, которые обычно на моих глазах закрывались после ухода этого самого "незаменимого".
И тем не менее это вполне себе идеал к которому нужно стремиться, или найти того или то что поможет в этом вопросе, не начальнику, а самому программисту, благо ресурсы для этого доступны большинству прямо на рабочем месте.
Приведу в пример работу одного из отделов Касперского, где код анализируют по бинарникам и в поставленные сроки нужно проанализировать работу опкода для написания отчета, чтобы судья или следователь смог вынести приговор или задержать злоумышленника. И тут очевидно отмаза "нет документации" не прокатит, и растянуть сроки не получиться, поскольку по дедлайну человека просто отпустят за неимением доказательств из-за вашей некомпетентности. А завтра отпущенный позвонит вам и расскажет что вы ему должны за его нервы. Или за то что выполнили задачу будете потом еще угрозы получать.
Проходное тестовое задание на час - нужно расписать работу приложения по бинарнику и определить если там вирус. А банальный кейлогер там может быть, даже если в байткоде сервиса обновления какого-нибудь кодека или плейера нет его тела. Работа выполняется на удаленном рабочем столе отдельного компьютера либо из дома, либо в офисе. При том что первое задание вам дается на неделю для проверки как говориться на "робота".
А вам станет легче, если в коде будет комментарий на подобии: "Начальник был самодур или пьян и решил проверить сможем ли мы добавить такое правило, и я его добавил, удачи!"
Или просто предыдущий работник решил под конец нагадить и с тех пор не появилось квалифицированного работника, который мог бы в этом разобраться и убрать даже с присутствующими комментариями.
А если он вам в тумбочку нагадил... и тд и тп. Причем тут комментарии и документация?
Незаменимых конечно же нет, но нужно не забывать про теорию вероятности и сводить все риски к минимуму. И комментарии тут только предлог и критерий, а никак не рычаг устранение проблемы, потому что код иногда из бинарников восстанавливать приходиться. И приветы передавать не только соседу по кабинету, но и разработчикам OS и фреймворков, чтоб они пофиксили свои костыли, включая недописанные драйвера от закрытых операционных систем оригинальных устройств.
Как я уже сказал если в фирме нет ни гита ни жиры и разработчик ушел не оставив самого когда это не проблема комментариев не надо путать теплое с мягким.
Моя уверенность идет от того, что я как раз таки работаю с огромными онлайн проектами уже больше 20 лет, по заранее оговоренным правилам, где названия функций и имена переменных говорят сами за себя, да в разных проектах они разные. А те примеры, которые вы описываете, это повседневные задачи. И если вам оставили в наследство настолько непрофессиональный код, что банально не соблюдены личные правила его написания и нет ни каких критериев, по которым он проектировался или в отладчике что-то потерялось, то это беда не относится к комментированию кода. На моей же практике даже школьники, пишущие код буквально на русском языке, придерживаются хоть каких-то принципов, поняв которые можно легко сориентироваться в тексте.
Нужно комментировать участки кода, по которому могут возникнуть вопросы.
Код по которому возникают вопросы и прочая магия - это всегда код вне компетенции читающего.
А если вы надеетесь что ваша задача ограничится прочтением описания и вкостыливание туда своего решения, когда предыдущий разработчик не позаботился о расширяемости когда - то это только ухудшить его читабельность.
Если компания хочет чтобы в штате были только новички не желающие развиваться, то ей действительно придется вкладываться. А без комментариев ты сам захочешь написать или переписать код, чтобы как минимум самому в следующий раз было понятно что в нем - это стимул и мотивация. А если вам так сложно разобрать код над которым работает команда, что у вас уходит дополнительное время, то возможно вы чего-то не знаете. Большой объем кода даже с комментариями разбирать сложно. А если есть общее представление и вы можете масштабировать свое представление об алгоритмах в проекте (какие должны присутствовать и каким не место в отдельном участке), то вы быстрее находите в коде то, что может выглядеть не ахти и исправить это. Комментарии при этом только увеличивают объем текста для чтения.
Как бы то не было, "хитрый" или "неизбежный" нечитабельный код прочтет тренированный человек без особых затрат и с этим все равно приходиться иметь дело, а привыкший на каждом шагу видеть описание логики будет только возмущаться и тратить свое время. Кроме того человек разобравшийся в алгоритме может его улучшить, научится чему-то, или более правильно его использовать, а прочитавший описание может просто на него забить и пойти дальше городить, часто, уже написанный код.
В наше время разработчики меняют компании как перчатки.
Поэтому компании должны быть готовы к тому, что любой разработчик может уйти в любой момент. Жужжание в уши и повышение зарплаты на 3% больше не работают. Хотя не факт, что они работали и раньше.
Повесить у себя в резюме что-ли? А то в уши кладу, что человек который не держится на работе это очень плохо, а оказывается это уже норма.
Не писать документацию.
Писать дрянной код
Единолично владеть некой основной частью системы
Все это аннулируются работником должной квалификации. Некоторые фирмы специально учат работников разбирать код без комментариев и отказываются от их написания. А появление дрянного кода в принципе неизбежно в большом коллективе и "стартапах". В остальном знание шаблонов, алгоритмов а соответствующей API базы поможет как при написании так и при чтении кода.
Это выдуманый критерий из их головы, я такого не говорил.
По крайней мере вы утверждаете что их нельзя назвать вещественными, поскольку часть из них (как иррациональные) в них не входят. По той же аналогии их нельзя назвать и рациональными, поскольку также не включают в себя часть рациональных.
Нет необходимости в бесконечных циклах, достаточно взять счетчик миллисекунд и отфильтровать его через функцию, например через sin. Тригонометрические или другие функцию вычислимые из ряда можно заменить на этот самый ряд и упростить его.
CSS Zen Garden запущен в мае 2003 года и там уже все на дивах, собственно с него я и учился. Но на каждый чих искать отдельный параметр, да еще с тучей альтернатив работающих не на каждом браузере одинаково, та еще головная боль.
В свое время я бы с удовольствием обучался простеньким примерам а-ля демосцена, но в то время даже шейдеров не было. А сейчас можно содрать страницу с shadertoy и уже учить objective C - это всегда наглядная математика, это интересно, это доступно всем и везде бесплатно, это останется на всю жизнь с человеком в какой бы он потом редактор не зашел.
Из всего того что у вас в списке есть, можно только остановится на верстке сайтов и то - это подразумевает знание тегов. Как много нужно знать в GLSL чтобы воспользоваться готовым редактором в браузере и тонной примеров?
С первыми реализациями СИ тоже было не все так гладко. Непарные pop/push (кстати говоря тоже от макрасофака) и ассемблерные вставки в больших количествах, много чего еще.
Вполне возможно что такого рода возмущения были при переходе например с ассемблера на С++. Можно даже аналогию провести, ведь пишем мы очень много мега буковок, которые превращаются в килобайты. Конечно люди с переходом от опкода на более высокоуровневый язык переставали понимать, что такое регистры флаги и прочие магические символы в виде команд, схемотехника и так далее. Ну и теперь мы имеем то что имеем. Чем это не новая абстракция более высокого уровня в своем зачатке?
Проверка на ноль работает всегда! Это компьютер. В первую очередь нужно уяснить для себя, что вы подразумеваете под этой проверкой на ноль. И когда требуется проверить именно на содержание нуля, а не бесконечно малого числа - это всегда работает.
Вторая проблема это когда вы задаете этот самый фиксированный EPS, то автоматически отсекаете возможный диапазон решений на более малый числах, когда текущая порядковая точность это позволяет. В этом и суть плавающего числа. А если вам нужен EPS, то подозреваю вам не плавающие числа нужны, а числа с фиксированной точкой.
Все бы ничего, но есть два дополнения:
квадратичная кривая Безье = lerp(lerp(p0,p1,t),lerp(p1,p2,t),t)
кубическая кривая Безье = lerp(lerp(lerp(p0,p1,t),lerp(p1,p2,t),t),lerp(lerp(p1,p2,t),lerp(p2,p3,t),t),t)
https://www.desmos.com/calculator/hfqqnck5g4?lang=ru
Ну и остальное = lerp(p0,p1,F(t))
Не будем забывать, что граф можно описать как списки вершин и соединений между ними.
М-да, теперь тетрис в килобайты не написать - буст нужен!
Опять вы путаете теплое с мягким и вводите в заблуждение других. Вопрос был про "Выделить массив байт" и "А вот когда указатель p был сформирован внутри компилируемой программы", где по вашему якобы помогает start_lifetime_as. И любому знающему человеку должно быть понятно в чем разница между разными парами "выделить"/"удалить" память, поскольку это разные менеджеры/системы памяти. Что собственно и делает start_lifetime_as, отключая у неявного объекта деструктор и конструктор. Поэтому ни какое ваше "кастануть его в указатель на структуру и обратиться к полю - UB" неверно ни для одного стандарта, до тех пор пока вы явно или неявно не вызвали деструктор или конструктор и не начали оперировать с таким объектом стандартными методами.
Во первых, а вои и да:
Хотя опять же это все определенные условия, при которых это можно было делать и раньше. Но
Во вторых, это утверждение по прежнему равнозначно для обоих примеров.
Немного ошибся с переводом, но тем не менее читайте описание start_lifetime_as и того что оно на самом деле делает, а не то что вы предполагаете (ссылка у меня выше и в статье). Это то, из-за чего нельзя сначала сделать malloc, а потом delete. (чего нормальному человеку в голову не придет) Собственно это и есть те условия, обходя которые можно уйти от UB.
Вы понимаете что здесь точно также можно сказать что "Разумеется, если фактическое расположение и выравнивание полей соответствует ожидаемому — то reinterpret_cast работает без всякого UB." ? Кроме того также выделение памяти под объект выполнено соответствующими средствами С++. В результате эти примеры равнозначны.
По вашему описанию выглядит как static_cast.
А из примера:
Видно что проблема здесь опять не в reinterpret_cast, а в том что buffer временный. Что из примера в статье выше это ни как не видно. И тут тоже можно обойтись исправлением без start_lifetime_as, копирования и UB.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2590r2.pdf
Почему-то ощущение что это какой-то костыль.
На счет того, что какой-нибудь:
Считается UB, мнения постоянно делятся и из-за этого родилось, то что родилось.
Все неопределенное поведение тут завязано только на отправителе или источнике указателя p, и к текущему коду никакого отношения не имеет. Как например, если этот указатель был получен из другого языка или компилятора где char 2 байта или имеет специфическое выравнивание. То есть вся проблема из-за расплывчатого описания стандарта. В этом смысле start_lifetime_as тоже мало чем поможет. А сама пометка неопределенного поведения подразумевает что угодно. Конкретно здесь несоответственное расположение данных полям структуры SomeStruct и тому что объект, который будет использоваться как SomeStruct, на самом деле им не был.
То есть можно сделать вывод, что start_lifetime_as просто затычка, чтобы люди закончили по этому поводу спорить. Но это же ни чего не меняет. По сути тот же const SomeStruct* str = (const SomeStruct*)p. из С, который по своей природе в этом плане тоже не определен.
Из примера видно что данные получены не внутри компилированной программы. Соответственно start_lifetime_as никак не помогает. Тем более это набор байт, а не другая структура, что в принципе не дает для start_lifetime_as ни какой информации о исходном типе.
А почему не со второго? Или вы думаете, что человек с кратковременным инсультом или скачущим давлением, имея за своими плечами годы опыта не превратиться в одночасье в ничего не понимающего человека?
И потом что вы подразумеваете под своим понятием "любой код"? Он что должен на слух данные с модема читать? С вашими якобы правильными выводами попахивает троллингом.
Как я уже сказал в рамках фирм в которых я работал это вполне рабочее высказывание, мало того является одним и перефразированных мною правил. Не надо забывать что они не работают без гита и документированных постановок задач, где вполне себе доступным языком описывается все внесенные в код правки начиная с 90-x. Но даже с этим приходиться рефакторить код годами.
А вы приводите примеры из фирм, которые обычно на моих глазах закрывались после ухода этого самого "незаменимого".
И тем не менее это вполне себе идеал к которому нужно стремиться, или найти того или то что поможет в этом вопросе, не начальнику, а самому программисту, благо ресурсы для этого доступны большинству прямо на рабочем месте.
Приведу в пример работу одного из отделов Касперского, где код анализируют по бинарникам и в поставленные сроки нужно проанализировать работу опкода для написания отчета, чтобы судья или следователь смог вынести приговор или задержать злоумышленника. И тут очевидно отмаза "нет документации" не прокатит, и растянуть сроки не получиться, поскольку по дедлайну человека просто отпустят за неимением доказательств из-за вашей некомпетентности. А завтра отпущенный позвонит вам и расскажет что вы ему должны за его нервы. Или за то что выполнили задачу будете потом еще угрозы получать.
Проходное тестовое задание на час - нужно расписать работу приложения по бинарнику и определить если там вирус. А банальный кейлогер там может быть, даже если в байткоде сервиса обновления какого-нибудь кодека или плейера нет его тела. Работа выполняется на удаленном рабочем столе отдельного компьютера либо из дома, либо в офисе. При том что первое задание вам дается на неделю для проверки как говориться на "робота".
А вам станет легче, если в коде будет комментарий на подобии:
"Начальник был самодур или пьян и решил проверить сможем ли мы добавить такое правило, и я его добавил, удачи!"
Или просто предыдущий работник решил под конец нагадить и с тех пор не появилось квалифицированного работника, который мог бы в этом разобраться и убрать даже с присутствующими комментариями.
А если он вам в тумбочку нагадил... и тд и тп. Причем тут комментарии и документация?
Незаменимых конечно же нет, но нужно не забывать про теорию вероятности и сводить все риски к минимуму. И комментарии тут только предлог и критерий, а никак не рычаг устранение проблемы, потому что код иногда из бинарников восстанавливать приходиться. И приветы передавать не только соседу по кабинету, но и разработчикам OS и фреймворков, чтоб они пофиксили свои костыли, включая недописанные драйвера от закрытых операционных систем оригинальных устройств.
Как я уже сказал если в фирме нет ни гита ни жиры и разработчик ушел не оставив самого когда это не проблема комментариев не надо путать теплое с мягким.
Моя уверенность идет от того, что я как раз таки работаю с огромными онлайн проектами уже больше 20 лет, по заранее оговоренным правилам, где названия функций и имена переменных говорят сами за себя, да в разных проектах они разные. А те примеры, которые вы описываете, это повседневные задачи. И если вам оставили в наследство настолько непрофессиональный код, что банально не соблюдены личные правила его написания и нет ни каких критериев, по которым он проектировался или в отладчике что-то потерялось, то это беда не относится к комментированию кода. На моей же практике даже школьники, пишущие код буквально на русском языке, придерживаются хоть каких-то принципов, поняв которые можно легко сориентироваться в тексте.
Код по которому возникают вопросы и прочая магия - это всегда код вне компетенции читающего.
А если вы надеетесь что ваша задача ограничится прочтением описания и вкостыливание туда своего решения, когда предыдущий разработчик не позаботился о расширяемости когда - то это только ухудшить его читабельность.
Если компания хочет чтобы в штате были только новички не желающие развиваться, то ей действительно придется вкладываться. А без комментариев ты сам захочешь написать или переписать код, чтобы как минимум самому в следующий раз было понятно что в нем - это стимул и мотивация. А если вам так сложно разобрать код над которым работает команда, что у вас уходит дополнительное время, то возможно вы чего-то не знаете. Большой объем кода даже с комментариями разбирать сложно. А если есть общее представление и вы можете масштабировать свое представление об алгоритмах в проекте (какие должны присутствовать и каким не место в отдельном участке), то вы быстрее находите в коде то, что может выглядеть не ахти и исправить это. Комментарии при этом только увеличивают объем текста для чтения.
Как бы то не было, "хитрый" или "неизбежный" нечитабельный код прочтет тренированный человек без особых затрат и с этим все равно приходиться иметь дело, а привыкший на каждом шагу видеть описание логики будет только возмущаться и тратить свое время. Кроме того человек разобравшийся в алгоритме может его улучшить, научится чему-то, или более правильно его использовать, а прочитавший описание может просто на него забить и пойти дальше городить, часто, уже написанный код.
Повесить у себя в резюме что-ли? А то в уши кладу, что человек который не держится на работе это очень плохо, а оказывается это уже норма.
Все это аннулируются работником должной квалификации. Некоторые фирмы специально учат работников разбирать код без комментариев и отказываются от их написания. А появление дрянного кода в принципе неизбежно в большом коллективе и "стартапах". В остальном знание шаблонов, алгоритмов а соответствующей API базы поможет как при написании так и при чтении кода.
Ищем 10 отличий.
По крайней мере вы утверждаете что их нельзя назвать вещественными, поскольку часть из них (как иррациональные) в них не входят. По той же аналогии их нельзя назвать и рациональными, поскольку также не включают в себя часть рациональных.