OR
А что с ними не так?..
Вроде всё ок
Вроде всё ок
Да вроде уже ничего, но раньше было веселее.
Size: a a a
2020 September 17
OR
Но нет гарантии, что не осталось весельчаков.
OR
Поэтому привычка указывать radix всегда
T
С ним регексп сложнее...
OR
С ним регексп сложнее...
🤷
OR
Тогда можно забить до встречи с проблемой, если потенциальный ущерб не существенен. Вероятность наткнуться вроде бы небольшая.
KC
обьяснил бы суть проблемы, вместо пугалок)
OR
parseInt("0101") до определённого момента отдавал 65T
На js или java?
KC
parseInt("0101") до определённого момента отдавал 65до какого? и в каком движке?
OR
На js, везде, до es5 вроде как
OR
Но так как cljs по умолчанию компилируется в es5, то и проблемы этой быть не должно.
KC
Но так как cljs по умолчанию компилируется в es5, то и проблемы этой быть не должно.
es5 это вариант спецификации, то как будет себя вести
parseInt(‘015’) зависит от имплементацииOR
В целом да, я потому и написал, что нет гарантии.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Octal_interpretations_with_no_radix
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Octal_interpretations_with_no_radix
OR
Но так как cljs по умолчанию компилируется в es5, то и проблемы этой быть не должно.
Здесь я, кажется, наврал.
ST
done
(defn parseInt [^String s]
#?(:clj (Integer/parseInt s)
:cljs (js/parseInt s)))
(defn try-parse-int [s]
(some->> s str (re-matches #"[-+]?\d+") parseInt))накладные расходы сомнительные
(Integer/parseInt "10") #_"17 ns"
(try-parse-int "10") #_"130 ns"
T
Преждевременная оптимизация))
T
У меня есть боттлнеки куда хуже в программе, так что лучше такое, чем баги
Потом ускорять буду
Потом ускорять буду
ST
Преждевременная оптимизация))
в java и в cljs есть функции типа isDigit, если уж на то пошло
простое регекспы довольно увесистый интсрумент
простое регекспы довольно увесистый интсрумент
T
Они небось тоже себя ведут непредсказуемо