Re[11]: Антипаттерн, противоположный Primitive Obsession
От: T4r4sB Россия  
Дата: 22.03.23 17:08
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Хотят получать странные числа в unsafe_i8 — пусть получают


Да даже незачем называть этот тип unsafe_i8, можно назвать его looped_i8.

К>А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде


Тогда возникает вопрос, какой тип должен быть у Integer<1..2> + Integer<3..4>? И допустимо ли их сложение?
Число по здравому смыслу это должен быть Integer<4..6>, но из-за ограничений платформы на деле получается, что в Расте
Integer<0..255> + Integer<0..255> имеет тип Integer<0..255> а вовсе не Integer<0..510> как должно быть.

К>Где-то это важно для производительности, где-то напротив, важно сказать "компилятор, ну ты сам за меня реши, что лучше на какой платформе".


В целом подход сей с кастом всего и вся к инту мне кажется каким-то неконсистентным, тут я солгасен.

TB>>Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.


К>Так с самого начала и отбросили. А если где-то кому-то надо сверхдлинное время — вот пусть ровно там для себя и вводит.

К>Зачем всех заставлять-то?

Мне всегда казалось, что правило, которое выводится прямой логикой, всегда намного легче для понимания и усвоения, чем правило, которое необходимо зубрить. По-моему, это очевидно, что для получения секунд из наносекунд надо поделить на 10**9
ции, потому что в разных случаях может быть по-разному.

К>Насчёт легче или нет — это именно спекуляции.

К>Но в одном случае ты делаешь линейную интерполяцию с неправильным коэффициентом (хотел 0.7 или 0.5, рука дрогнула, подставил 0.6), а в другом — создаёшь неверную сущность, хотя для какой-нибудь фрактальной геометрии, возможно, она и пригодится.

Дык я в любом случае из-за опечатки имею неверный результат. И мне ничуть не легче от того, что он "немного по-другому" неверный.
"Раньше люди добрее были. Никого не убивали. А если и убивали, то как-то по-доброму что ли".

К>Если тебя бесит, что в симметричной формуле линейной интерполяции появляется внутренняя асимметрия, — одна из точек становится важнее другой, — ну спрячь формулу в функцию.


Меня бесит, что для задачи
auto half_of_center = center * 0.5;
for (auto& p: points) {
  p = p * 0.5 + half_of_center ;
}

мне придётся делать лишнее сложение во внутреннем цикле в случае использования "типобезопасной" библиотеки. И это я вспомнил лишь самую простую формулу.

К>Я про библиотеки, используемые в промышленной робототехнике, — в ROS.


Лично я такие не использовал, но кто пользовался из моих знакомых — отзывы что разделение точек и векторов это бесполезный геморрой для программиста, не дающий никакой пользы.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.