- 1
public virtual int ReadByte()
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+132
public virtual int ReadByte()
Тут в соседнем треде появилась такая тема:
http://msdn.microsoft.com/ru-ru/library/system.io.stream.readbyte.aspx
http://govnokod.ru/12311#comment164854
21.12.1212
Возвращаемое значение
[qoute]Тип: System.Int32
Байт без знака, приведенный к Int32, или значение -1, если достигнут конец потока.[/qoute]
Другой вопрос, что писал без IDE и есть ошибки.
>while (bt = stream.ReadByte() > 0)
Зато ты лентяй и сразу ошибся. Вот что я называю нихрена непродуманным интерфейсом, что приводит к таким банальным глупым ошибкам.
Конкретно этот код даже не скомпилируется, выдаёт ошибку "Cannot implicitly convert type 'bool' to 'int'" (строгая типизация, это вам не сишка )
И из того, что я привёл этот пример ещё не следует, что я его использую.
Это раз.
Во-вторых, используешь сишный side-effect инкрементов и присваиваний, тогда yoda-style твой лучший друг.
В-третьих, читать по байту - мелковато.
В-четвертых, есть LINQ.
3. Scumbag
The dirt under the fingernails of progress as some may say. Scumbags, also known as scummies are immoral and have no sense of right or wrong in the world due to poor parenting.
Avoid scummies at all costs.
Scummie: Hey do you have a skeet AssParallel?
Person: fuck off, LINQscumbfag.
Лол.
В Питоне другая философия, там даже из цикла выход осуществляется через исключение.
Ты не поверишь:
Другой вопрос, что в Stream такого свойства нет. А почему так сделано... Ну, возможно, для облегчения реализации интерфейса. Да и в общем случае не всегда можно узнать, достигнут ли конец данных, не фактически прочитав байт.
И что вы можете гарантировать в сокете?
Очевидно же.
Пока буфер вновь не наполнится хотя байтом или не закроется сокет.
Просто я привык, что блокирующий у нас read()
Или я что-то упустил?
В первой я читаю файл, и хочу знать когда он закончится - этот случай и имелся в виду в шарпе.
А другая ситуация - я читаю из файла определенную структуру, вызывая всякие-там getInt, getFloat, getDouble и т.п. И вот тут конец файла до окончания структуры это именно исключительная ситуация. И именно ее я хотел показать как пример об удобстве исключений в соседнем треде.
Но зачем городить такое говно, что они сделали?
Supported in: 4.5, 4, 3.5, 3.0, 2.0
А Stream был изначально (с 1.0)
http://docs.oracle.com/javase/1.4.2/docs/api/java/io/InputStream.html#read%28%29
public abstract int read()
Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned.
fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error.
#define EOF (-1)
http://docs.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html
>getc() reads the next character from stream and returns
Прикол в том что для чара байта и даже джвух может не хватить. А если мы будем будем читать в нативный 16-битный int, то...
> EOFException - if this input stream has reached the end.
Конца Светы что-ли ждут?
Разлогинило ;(
А пароль, в который раз, забыл сохранить на рабочей машине.
> В нормальных компиляторах (аля гцц) плата за экцепшн берется только при его вбросе и раскрутке [...]
Производительность - да. Но есть еще проблема с размером кода.
На текущем C++ модуле с которым я работаю и который активно пользуется исключениями, 75% кода (центральных функций) приходится именно на обработку исключений. Другими словами, этот тот код который никогда в нормальном случае и даже не будет затронут.
Самая центральная функция: ~5К асма на саму логику против ~15К асма (после последнего `ret`а) на обработку исключений. Если сильно в эти 15К всматриваться, то можно реально разглядеть что тут есть кусок кода соответствующий каждому месту функции которое может бросать исключения. Подавляющая часть этого кода: вызов деструкторов для временных/локальных объектов.
И это я здесь говорю про код. Exception handling tables по старой памяти так много места не занимают - да и в любом случае IIRC они лежат в своем собственном сегменте и сегмент кода не засоряют.
ЗЫ Я сомневаюсь что C# может это сделать намного лучше.
Я уже говорил и повторю еще раз: нужно ключевое слово, оператор, флаг или там аннотация, чтобы включать и выключать исключения на блоке кода.
Чтобы превратить "ой упало, вот вам стектрейс" в "кровь-кишки-молча-распидорасило-внутреннее-состояние-проги-и-об-этом-узнали-через-год"?
Разве что добавить на функции и блоки атрибут типа nothrow, показывающий, что она не может вбросить никаких исключений, даже RuntimeException. И разрешать из таких функций вызывать только меченные... Тогда будет гарантия, что хуйню не напишешь. P.S. К сожалению любой блок, в котором есть new, пометить как nothrow уже не получится ;(
Моё мнение такое если и уж делали checked exceptions, то надо было сделать их настраиваемыми как опция компилятора ignore/warn/error. Вместо того чтобы тупо запрещать коду компилится.
Хороший пример - переполнение. При расчетах оно нужно и хорошо бы его вовсе не замечать, но обычно же лучше включать проверку.
>"распидорасило-внутреннее-состояние-проги-и-об-этом-узнали-через-год"
В жабе если run() в треде кидалось исключение (куда ему дальше идти? тоже игнорится) то стектрейс писался в System.err.
Несколько версий спустя туда добавили возможность задать default handler для таких вот неуловимых ошибок.
Так что разрулить можно.
Почему? Ааа, жаба...
if'ы есть часть нормального кода. обработка исколючений - 99% кода генирится самим компилером и никакого отношения к остальному коду или логике не имеет.
"Я уже говорил и повторю еще раз: нужно ключевое слово, оператор, флаг или там аннотация, чтобы включать и выключать исключения на блоке кода."
это достаточно просто: не пользуйся ОО побрякушками в куске кода - временными объектами на стэке, статически аллоцироваными объектами внутри подконтекста - и у него не будет никаких специальных довесков для обработки исключений.
еще раз повторю - "Подавляющая часть этого кода: вызов деструкторов для временных/локальных объектов." другими словами этот авто-сгенерированый код как бы никакого непосредственного отношения к исключениям не имеет, он имеет непосредственное отношение к коду функции. но этот код нужен только исключительно для обработки исключений, что бы гарантировать что даже в этом случае объекты/етц ведут себя согласно С++ стандартам.
Сишный аналог - каждая операция обернута в try, с кетчем который вызывает единый, заданный кодером обработчик ошибок.
>этот код нужен только исключительно для обработки исключений, что бы гарантировать что объекты ведут себя согласно С++ стандартам.
За удобство в любом случае придется чем-то заплатить, будь то скорость и/или размер программы. Не спорю.
Вот кстати не всегда... Ифы, проверяющие коды возврата, закрывающие всякие ресурсы и освобождающие память это как раз обработка исключений. Только она, к сожалению, не генерируется компилятором, а пишется руками.
> согласно С++ стандартам
Согласно здравому смыслу. Иначе приходится городить конструкции с goto в конец и закрыванием всех файлов. А готофобам и того хуже...