Comments 21
Класс интересен и может оказаться весьма полезным, да и реализация грамотная. Но вот единственное что лично меня коробит — это некий стиль пустых catch в каждом методе. Например, «заныкивать» IOException из din.read не очень правильно, ИМХО, его надо пропускать наверх, вплоть до методов nextXXX и выше. Хотя, конечно, всё зависит от целей, но для класса какого-никакого общего предназначения это по всем канонам правильнее.
+3
Скрывать исключения без обработки — плохо по определению
+2
Вы правы в случае общего предназначения, но я использовал класс для задач в online judge, а там это было ни к чему. Я думаю что каждый человек, который захочет использовать данный класс сможет самостоятельно определить действия при исключении.
+2
>>С этой целью я написал класс, который побитово *считывает данные из потока* и преобразует их в числа или строки. Как оказалось этот класс работает в несколько раз быстрее, чем *printf()* в языке С++.
Мне одному эта часть показалась странной?
Мне одному эта часть показалась странной?
+3
ты погляди как много последнее время статей, связаных с java. Аж глаз радуется…
+4
UFO just landed and posted this here
Я с вашего позволения потроллю немного.
"… чем scanf() в языке С++"
google -> «какой-то форум» -> копипаст ->
«На счет того что лучше использовать stdout, stdin или cout, cin, я для себя так решил.
Если пишу на С++(.cpp) то и пишу в стиле С++. Т.е. пользуюсь тем что дает именно С++: потоками cout, cin; связками try, throw, catch; inline; все что можно, упаковываю в объекты и по максимому пытаюсь использовать библиотеку STL. И не позволяю себе использовать что-то типа такого: printf, longjmp и все то что преcуще C.
Если пишу на С(.с) то и пишу на С.»
"… чем scanf() в языке С++"
google -> «какой-то форум» -> копипаст ->
«На счет того что лучше использовать stdout, stdin или cout, cin, я для себя так решил.
Если пишу на С++(.cpp) то и пишу в стиле С++. Т.е. пользуюсь тем что дает именно С++: потоками cout, cin; связками try, throw, catch; inline; все что можно, упаковываю в объекты и по максимому пытаюсь использовать библиотеку STL. И не позволяю себе использовать что-то типа такого: printf, longjmp и все то что преcуще C.
Если пишу на С(.с) то и пишу на С.»
-2
Я ведь упоминал, что использую это только в judge, люди которые пишут там на С++ не пользуются cin-ом, throw-ом и catch-ем. А не написал я про С потому что в С scanf() работает чуть медленнее чем в С++. Все это только для сравнений, Вы не так понимаете.
-1
Наверное. Но, я продолжу.
«люди которые пишут там на С++ не пользуются cin-ом...» -> «люди которые пишут там не пользуются C++»
Я к тому, что scanf — «библиотечная» функция из стандарта C, а не C++ (нафиг совместимость).
wikipedia -> C++ -> копипаст ->
«Стандартная библиотека C++ также развивалась вместе с ним. Первым добавлением к стандартной библиотеке C++ стали потоки ввода/вывода, обеспечивающие средства для замены традиционных функций Си printf и scanf. Позднее самым значительным развитием стандартной библиотеки стало включение в неё Стандартной библиотеки шаблонов.»
«люди которые пишут там на С++ не пользуются cin-ом...» -> «люди которые пишут там не пользуются C++»
Я к тому, что scanf — «библиотечная» функция из стандарта C, а не C++ (нафиг совместимость).
wikipedia -> C++ -> копипаст ->
«Стандартная библиотека C++ также развивалась вместе с ним. Первым добавлением к стандартной библиотеке C++ стали потоки ввода/вывода, обеспечивающие средства для замены традиционных функций Си printf и scanf. Позднее самым значительным развитием стандартной библиотеки стало включение в неё Стандартной библиотеки шаблонов.»
-3
> побитово
Может всётаки побайтово?
Может всётаки побайтово?
0
Лично мне кажется, что этот код прекрасная иллюстрация того, что олимпиадное программирование и промышленное сильное отличаются. Написать такой код в живой программе не уважать себя, коллег и пользователей.
Важную роль в программировании играет рассмотрение разных «неправильных» случаев ввода и корректная их обработка. Вы же на это просто забиваете, потому что олипиадные входные данные всегда отформатированы корректно.
Важную роль в программировании играет рассмотрение разных «неправильных» случаев ввода и корректная их обработка. Вы же на это просто забиваете, потому что олипиадные входные данные всегда отформатированы корректно.
+3
на контесте нет времени писать такой шаблон. в реале пишется совсем другой
+1
На контесте он и не нужен, это для споджа.
0
я совсем другое имел в виду. Не так уж и много задач, которые не решаются из-за медленного чтения в Java(честно говоря, я не встречал ни одну). Обычно хватает стандартного StringTokenizer'а
+1
в смысле BufferedReader+StringTokenizer
+1
Попробуйте эту www.spoj.pl/problems/KUTH/ сдать с Tokenizerом
0
Sign up to leave a comment.
Быстрый ввод в Java