Pull to refresh

Comments 36

UFO just landed and posted this here
И да, до сих пор не понимаю, зачем это.
Разделитель тысяч в больших числах.
10000000 => 10_000_000
Это подходит только для круглых чисел.

У кого-то компилятор по честному вставит посчитанную константу, а у кого-то виртуальные машины и такие константы придется на ходу вычислять.

UFO just landed and posted this here

JS в зависимости от скоупа константы может сделать оптимизацию и вычислить единожды, но скажем, перезагрузка страницы заставит его выполнить вычисление заново ибо контекст снова будет пересоздан. Есть нюансы, но идея я думаю понятна. Его сосед WASM же вычислит число еще на этапе компиляции и ее можно сразу читать.
Питон вычислит единожды при старте контекста и закэширует в .pyc т.е. и в отличие от JS перезапуск контекста не должен приводить к пересчету. PHP, Ruby та же история.
Ну, а в целом да, вычисления констант обычно супер дешевые и это скорее перфекционизм.

главное чтобы был принят единый стандарт в проекте для форматирования чисел. Например индус запишет данное число как 31_53_600 и ему будет норм :)

Даже в голову не пришло, что кто-то может так извратиться

Это в греко-римской культуре мы делим на тысячи: кило, мега, гига, а например японцы делят манами (10000).

Про вычисляемые константы типа числа секунд в году хорошая идея, но вот, например записывать пределы вида миллиард = 100010001000 не очень, имхо. 1_000_000_000 куда читаемей, особенно если это не функция приобразования гигабайт в байты и обратно, а, например, лимиты операций по счету

protected const YEAR_SECONDS = 60 * 60 * 24 * 365;

Все верно… ну а если год високосный? А астрономы и вовсе верят, что средний тропический год — это 31 556 925 с… Так что простое умножение не всегда спасает. Иногда приходится и константы писать…
Впрочем, с астрономами вообще лучше не связываться, у них даже сутки не всегда равны 60*60*24=86 400 с, т.к. Земля не совсем равномерно вращается ;-)

Ну так заведите константу с названием типа LEAP_DIFFERENCE, AVG_TROPICAL_DIFFERENCE и вычисляйте от базового значения 60 х 60 х 24…
Всяко лучше 31566925 как magic number.

Само собой, в коде надо писать мнемонику, а не цифру. Но при инициализации этой константы все равно приходится цифры расписывать. То есть, вопрос о разделителях внутри числа не снимается, а только отодвигается в специальное место…
UFO just landed and posted this here
Ну во-первых, человечество действительно деградирует ;-)
Например, в моей молодости фортран очень медленно работал со строками или с посимвольным выводом на экран (а нам хотелось интерфейс типа Norton Commander-а). Так у нас тогда было нормой некоторые функции на ассемблере переписать. И это практически каждый фортранист в какой-то степени мог. А сейчас вставки на ассемблере хорошо, если каждый сотый напишет. Вот и я уже давно не пишу.
Впрочем, возможно я зря обобщаю на все человечество, и деградация только лично у меня происходит ;-))

Но вообще, когда констант много, то просто для удобства чтения кода гораздо лучше числа писать с разделителями. Чтобы хотя бы в этом месте не терпеть и не напрягаться. В фортране это всегда было доступно (а для кого-то и нормой). Сейчас общая тенденция — чтобы всякие подобные мелкие удобства были доступны в любом языке. Чего в этом плохого? Тем более, что синтаксис в разных языках почти единообразный и даже новичку в языке такая запись понятна?
Ну а не если хочется — так никто не заставляет, можно и не использовать.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here

Во времена вашей молодости и ассемблер наверняка попроще был, не то что современный x86-64 да с расширениями всякими.

Ну C уже довольно взрослый ребенок, не тащит в рот любую бяку которую вокруг себя находит :)

Почему бяку? При написании каких-то длинных констант — вполне себе удобно, добавляет читабельности, особенно когда где-то константа с кучей нулей подряд.

Вы цепляетесь. Я минуты две придумывал слово которое передает иронию но при этом никого сильно не оскорбляет. Я не считаю что разделители бесполезны. Просто стандарт С КРАЙНЕ консервативен. Я не думаю есть ли более консервативный развиваемый сейчас язык. Поэтому туда не добавляют все что «было бы полезно».

А вообще можно малюсенький препроцессор написать для внедрения такой возможности.

Также, пишут, что FORTRAN до версии 77 года вел себя аналогично.

Возможно, я не совсем понял текст по ссылке, но мне непонятно, откуда там взялась цифра Ф-77? Насколько я знаю, по умолчанию фортран до сих пор игнорирует пробелы. Проверил сейчас в компиляторе 2013г (стандарт языка Fortran 2008). И в нем две эти формы записи эквивалентны:
integer :: int_var = 1000000
и
integer :: i nt_v ar = 1 000 000

Возможно, в новых компиляторах есть ключи, позволяющие ограничить такие вольности, но с ходу я что-то ничего не нашел…

А символ подчеркивания в фортране используется, чтобы указать разрядность константы в байтах, например:
13_2! 16-битное целое
-1_8! 64-битное целое

Ну и с системами исчисления все стандартно и лаконично:

int_var=36#3z! присваивает int_var значение 143

Буквы A..Z обозначают цифры от 10 до 35 (соответственно основание может быть не более 36). Ну и упрощенная запись для наиболее частых случаев:

i=B'011'; j='010'B! присваивает i=3, j=2
i=O'011'; j='010'O! присваивает i=9, j=8
i=X'011'; j='010'X; k=Z'0A'! присваивает i=17, j=16, k=15

Даже не знаю, считать ли такую вариативность записи достоинством языка или его недостатком… Если речь идет о клавиатурных комбинациях-синонимах, то вроде бы мы их обычно приветствуем: хочешь, жми Ctrl+C, а хочешь — Ctrl+Ins. А в коде?
В свободной форме нельзя, а в фиксированной можно. И Intel Fortran, и GNU Fortran себя именно так ведут.
Исправил в посте на fixed-form source files, фортран не родной язык для меня.
Да. И это полностью уберет обратную совместимость с предыдущими версиями.
В Python строки вида /_[0-9]+/ тоже имеют свой смысл, что иногда дает трудно обнаруживаемые ошибки в больших массивах использующих подчерк как разделитель.
Sign up to leave a comment.

Articles