[off] краткость Java-ы
int a = atoi("456");
long a = atol("456");
$a=intval($a);
кратко, но не понятно
Не нравится прекрасная и совершенная Java - этот выдающийся язык сегодняшнего и завтрашнего дня? Вы просто не умеете её готовить. 
new Long("456")
, ход мыслей был из C#
С появлением boxing-unboxing-а подобные тройные повторения мгновенно вызывают подозрения. Руки просто сами тянутся рефакторить.
a=`atol($a)`
Очередной беспочвенный наезд на прекрасную и совершенную Java - этот выдающийся язык сегодняшнего и завтрашнего дняSaying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Рассказывают, что древние греки примерно так и рассуждали.
new Long(Long.parseLong("456";ну это капец запись конечно...) записал бы так еще :
new Long Long) Long.parseLong("456"; -тогда точно с ума сойти можно
>int a = atoi("456");
"Опять двойка" (с)
"Опять двойка" (с)
"Опять двойка" (с)Поддерживаю, atol неадекватно на ошибки парсинга реагирует, ее какие-то убогие программисты придумали. Правильно пользоваться strtol, но ее уже в одну строчку на запишешь, да здравствует краткость Си!
>Правильно пользоваться strtol, но ее уже в одну строчку на запишешь, да здравствует краткость Си!
Ну для джавовского / C# варианта (они же кидают экеспшены?) тоже по-хорошему обработчик исключений нужен. Тоже +несколько строк.
Я так вообще люблю boost::lexical_cast (правда, медленный он страшно, цуко)
Ну для джавовского / C# варианта (они же кидают экеспшены?) тоже по-хорошему обработчик исключений нужен. Тоже +несколько строк.
Я так вообще люблю boost::lexical_cast (правда, медленный он страшно, цуко)
Ну конечно не так коротко...
VAR x: LONGINT; res: INTEGER;
...
Strings.StringToLInt("456", x, res); ASSERT(res = 0);
VAR x: LONGINT; res: INTEGER;
...
Strings.StringToLInt("456", x, res); ASSERT(res = 0);
> Ну для джавовского / C# варианта (они же кидают экеспшены?) тоже
> по-хорошему обработчик исключений нужен.
Многие программы на Java, которые я видел, успешно обходились без отдельного обработчика на каждый чих. Такие программы просто срут исключениями в stderr, и всё.
Ко многим программам на C и C++ это тоже относится, особенно к k* и g*
> по-хорошему обработчик исключений нужен.
Многие программы на Java, которые я видел, успешно обходились без отдельного обработчика на каждый чих. Такие программы просто срут исключениями в stderr, и всё.
Ко многим программам на C и C++ это тоже относится, особенно к k* и g*
>Многие программы на Java, которые я видел, успешно обходились без отдельного обработчика >на каждый чих. Такие программы просто срут исключениями в stderr, и всё.
То есть я типо ввожу в поле "Сумма, $:" значение "Хуй", и программа вместо того, чтоб вежливо попросить чо-нить другое, крашится / снимает с моего счота случайную сумму денег / ...?
То есть я типо ввожу в поле "Сумма, $:" значение "Хуй", и программа вместо того, чтоб вежливо попросить чо-нить другое, крашится / снимает с моего счота случайную сумму денег / ...?
Ну ты нажмёшь Ok или аналог, она напишет 2 страницы дампа стека в stderr, а в GUI ничего не изменится, примерно так обычно.
Я так вообще люблю boost::lexical_cast (правда, медленный он страшно, цуко)Туда достаточно приписать десяток специализаций и все с ним станет в порядке. Если в целом идея здравая, то производительность всегда можно спасти
в 5ой джава и так сойдет:
Long l = Long.parseLong("1"); Всё-таки три раза "Long"
да, ты прав, больше не буду прогать на джава
>Туда достаточно приписать десяток специализаций и все с ним станет в порядке. Если в целом идея здравая, то производительность всегда можно спасти
Угу. Я в конце концов так и сделал для нужных мне случаев.
Угу. Я в конце концов так и сделал для нужных мне случаев.
+1
> Ну ты нажмёшь Ok или аналог, она напишет 2 страницы дампа стека в stderr, а в GUI ничего не изменится, примерно так обычно.
Что еще делать с непредвиденными ошибками?
Что еще делать с непредвиденными ошибками?
дотнетовых структур джава не хватает, а то иногда нужно особенно эффективно данные в памяти размещать
Это очень даже предвиденная ошибка.
То, что преобразование строки в число может привести к ошибке, компилятору известно во время компиляции, а человеку - и того раньше.
Просто поленились обработчик написать.
Кроме того, ИМХО GUI-приложение не должно писать в stderr ничего, кроме случаев действительно непредвиденных ошибок, после которых восстановление невозможно.
То, что преобразование строки в число может привести к ошибке, компилятору известно во время компиляции, а человеку - и того раньше.
Просто поленились обработчик написать.
Кроме того, ИМХО GUI-приложение не должно писать в stderr ничего, кроме случаев действительно непредвиденных ошибок, после которых восстановление невозможно.
Не очень понятно, что мешает JVM
особенно эффективно данные в памяти размещать
такую ее родили -- для данных есть только примитивные типы и классы
пока приходилось сталкиваться с проблемой когда нужен массив пар или троек интов, приходилось запихивать последовательно в массив интов
пока приходилось сталкиваться с проблемой когда нужен массив пар или троек интов, приходилось запихивать последовательно в массив интов
> Это очень даже предвиденная ошибка.
> То, что преобразование строки в число может привести к ошибке, компилятору известно во время компиляции, а человеку - и того раньше.
Что нам даст - если мы ее предвидим - перехватим и что-то напишем?
Прога станет лучше работать?
Станет дешевле разработка?
ps
Имхо - важно только одно - программа должна себя корректно вести при наличии ошибок, а вылизывание поведения программы во время ошибок - это уже бантики - причем сложность этих бантиков экспонециально больше, чем основная работа программы.
> То, что преобразование строки в число может привести к ошибке, компилятору известно во время компиляции, а человеку - и того раньше.
Что нам даст - если мы ее предвидим - перехватим и что-то напишем?
Прога станет лучше работать?
Станет дешевле разработка?
ps
Имхо - важно только одно - программа должна себя корректно вести при наличии ошибок, а вылизывание поведения программы во время ошибок - это уже бантики - причем сложность этих бантиков экспонециально больше, чем основная работа программы.
new Long(Long.parseLong("456";посмотри исходник конструктора Long(String .. там как раз вызывается parseLong... так что написанный мною код выглядит вполне логично, просто не заметил, что возможна более короткая запись
--------------------------------------------------------------------------------
ну это капец запись конечно...) записал бы так еще :
new Long Long) Long.parseLong("456"; -тогда точно с ума сойти можно
т.е. мое мнение - что выгоднее большую часть ошибок - считать непредвиденными.
супер 
не пиши больше на Джаве
не надо. так всем спокойнее будет.
мой тебе дружеский совет.
не надо. так всем спокойнее будет.
мой тебе дружеский совет.
посмотри исходник конструктора Long(String .. там как раз вызывается parseLong... так что написанный мною код выглядит вполне логично, просто не заметил, что возможна более короткая записьСамо собой. Но напрашивается встречное предложение: посмотри исходник parseLong(...) и сделай как там. Зачем тебе дурацкая короткая запись?
Само собой. Но напрашивается встречное предложение: посмотри исходник parseLong(...) и сделай как там. Зачем тебе дурацкая короткая запись?это от долгого использования Java-ы такая логика?
т.е. мое мнение - что выгоднее большую часть ошибок - считать непредвиденными.согласен
в меморис!
Оставить комментарий
6yrop
new Long(Long.parseLong("456";так и заикой можно стать Long, Long, Long
а на C#
long.Parse("456");