А вы представляете насколько это будет медленно? И как в таком случае сдедать чтение частями? Не забывайте что у меня на обработке файлы по несколько гиг. Вы уж извените но ваш метод не только намного медленнее, но и на порядок сложнее, да и еще не учитывает тонкости которые описаны в статье. Да и еще забыл, онгда пользователь захочет остановить процесс досрочно, как быть в этом случае?
Извените, но где я нарушил интерфейс? В МСДН четко написано: конец потока, если Read возратила нуль. А если делать как вы говорите «правильно», то это наделать еще множество новых ошибок и потратить много времени на отладку. И кто вам сказал что вы поступаете правильно?
Подождите, вы предлагаете вместо объекта сформированного утилитой xsd писать свой, который перекидывает данные куда надо, правильно? Но в таком случае он должен полностью копировать структуру созданного, а это несколько тысяч строк кода! Проще уже в сам конечный объект внести правки. И где тут универсальность?
Подождите, вы предлагаете вместо объекта сформированного утилитой xsd писать свой, который перекидывает данные куда надо, правильно? Но в таком случае он должен полностью копировать структуру созданного, а это несколько тысяч строк кода! Проще уже в сам конечный объект внести правки. И где тут универсальность?
У вас есть сформированная каким-то образом строка «Это строка которую я сформировал», если в буфере не хватает места для нее, то ее нужно делить и запоминать где поделили, и потом на следующем цикле ложить остаток. Но в реальности намного проще, отдать то что уже положено, и уже на следующем цикле ложить всю строку. В своем коде я столкнулся с таким случаем и бало проще было поступить именно так.
Вы видать никогда не имели дело с сокетами, там то заполние буфера не предсказуемо, может заполнится полностью, а может частично.
>>Что значит «для вашего удобства не полностью заполняете буфер»?
например, если вы ложите в буфер какой-то неделимый блок данных, и если не хватает места в буфере, то всегда проще отдать уже то, что есть, и уже на следующем цикле, когда в буфере будет достаточно места, ложить эти данные. Иначе при условии заполнения буфера полностью, может сильно усложнится код
В том то и дело что массив не всегда может быть заполнен до конца, но в случае с файлами такое поведение вполне нормально, но проблемы начнутся тогда когда вы будете читать не из файла. Хотя сами классы затачивались для чтения только из файлов.
Вот вам гепотетический случай, вы имеете либу которая читает данные из потока, этот поток формируете и заполняете вы, и для своего удобства не всегда полностью заполняете буфер. Предствьте как вы намучаетесь, если либа будет считать поток исчерпан только по тому, что не полностью заполнен буфер. Это вообще грубейшая ошибка. В моем случае десириализатор ведет себя правильно, когда простое чтение текстовых файлов не совсем верно.
Я уже говорил, что лучше тем что я контролирую поток данных, и на ходу правлю ошибки в нем, т. е. у меня полный контроль за данными. В вашем случае, такой контроль очень слабый, мало того нужно еще разбираться в каком месте нужно править да и еще носить кучу дублированного кода.
А я говорю еще про случаи когда исходный код недоступен, что бывает чаще всего.
Если бы я не понимал ООП, то не смог бы реализовать это. Я прекрасно понимаю, что делаю все на низком уровне, но так проще и универсальнее, тем более что не всегда есть возможности менять либы.
Причем тут абстракции? И что плохого в контроле за потоком? Многие программы так делают, и ничего страшного.
В вашем случае нужно еще заниматься изучением чужого кода, когда проще написать небольшое дополнение и забыть.
>Я бы в этом случае тягал бы xml файлы через мок(практически)-типы, написать генератор >для описанного в топике случая — 30-50 строк кода.
А если изменится структура, опять писать? В моем случае ничего вообще не нужно делать, в части чтения
Рейтинг плохой из-за нехорошего кода, сам способ тут не причем.
Я и не говорю, что код хороший, и вообще не думал его вылаживать. Вообще речь шла о методе, а реализация получилась не очень красивой, но сами подумайте можно ли сразу реализовать с ходу красивый код, иногда приходится переписывать, что я позже и сделаю
1) Что плохого в том что я подменяю в потоке данные?
2) Зло в том, что в библиотеке еще нужно разобраться и найти места где нужно менять, плюс к этому нужно еще лишнии ненужные мегабайты потом тягать с собой и держать при этом сами правки. А тут всего лишь написал одну функцию и контролируешь весь процесс, и если надо, легко правишь нужные места. Вообще либы правятся в случае грубых ошибок в них, а не вслучае если вам не удобно, иначе так придется все платформу Net со своими правками тягать с собой.
3) Какую абстракцию я нарушил? Я воспользовался легальны способом и она работает на ура.
4)Опять двадцать пять, когда столкнетесь с моим случаем, вот перепишите все либы под себя, вот тогда и посмотрите что лучше.
Дальнейший спор бесполезен, я поступил как считаю нужным, и считаю что мой способ лучше и быстрее.
Тогда почему не ведет себя подобным образом сериализатор? А он будет читать до тех пор пока я не возращу 0.
Такое поведение возможно оправдано для StreamReader\Writer в случае когда читаются файлы, но проблемы возникнут, если источником будет нечто другое, которое не может сразу возвращать указанное количество байт.
1) Я не хочу трогать сериализатор, я просто хочу чтобы он получал правильные данные, да и переделывать либу под каждый бздык разных задач слишком трудоемко.
2) Я не спорю, что это плохой код, в реальности будет другой, а библиотеку менять это еще большее зло, так как возникнет куча других проблем, например как потом быть с переделанной либой при установке приложения на другой комп.
3) А зачем это делать, если есть более лучше способ?
4) Почему не к месту? Если бы сериализатор предоставлял бы нужные мне, то я ими бы и воспользовался.
У вас есть сформированная каким-то образом строка «Это строка которую я сформировал», если в буфере не хватает места для нее, то ее нужно делить и запоминать где поделили, и потом на следующем цикле ложить остаток. Но в реальности намного проще, отдать то что уже положено, и уже на следующем цикле ложить всю строку. В своем коде я столкнулся с таким случаем и бало проще было поступить именно так.
>>Что значит «для вашего удобства не полностью заполняете буфер»?
например, если вы ложите в буфер какой-то неделимый блок данных, и если не хватает места в буфере, то всегда проще отдать уже то, что есть, и уже на следующем цикле, когда в буфере будет достаточно места, ложить эти данные. Иначе при условии заполнения буфера полностью, может сильно усложнится код
Вот вам гепотетический случай, вы имеете либу которая читает данные из потока, этот поток формируете и заполняете вы, и для своего удобства не всегда полностью заполняете буфер. Предствьте как вы намучаетесь, если либа будет считать поток исчерпан только по тому, что не полностью заполнен буфер. Это вообще грубейшая ошибка. В моем случае десириализатор ведет себя правильно, когда простое чтение текстовых файлов не совсем верно.
А я говорю еще про случаи когда исходный код недоступен, что бывает чаще всего.
Я уже говорил, что код не очень, но сам метод помоему лучше чем предложенный вами, и при этом не нужно разбираться в чужом коде.
И как быть в вашем случае если исходный код библиотеки недоступен?
В вашем случае нужно еще заниматься изучением чужого кода, когда проще написать небольшое дополнение и забыть.
>Я бы в этом случае тягал бы xml файлы через мок(практически)-типы, написать генератор >для описанного в топике случая — 30-50 строк кода.
А если изменится структура, опять писать? В моем случае ничего вообще не нужно делать, в части чтения
Рейтинг плохой из-за нехорошего кода, сам способ тут не причем.
2) Зло в том, что в библиотеке еще нужно разобраться и найти места где нужно менять, плюс к этому нужно еще лишнии ненужные мегабайты потом тягать с собой и держать при этом сами правки. А тут всего лишь написал одну функцию и контролируешь весь процесс, и если надо, легко правишь нужные места. Вообще либы правятся в случае грубых ошибок в них, а не вслучае если вам не удобно, иначе так придется все платформу Net со своими правками тягать с собой.
3) Какую абстракцию я нарушил? Я воспользовался легальны способом и она работает на ура.
4)Опять двадцать пять, когда столкнетесь с моим случаем, вот перепишите все либы под себя, вот тогда и посмотрите что лучше.
Дальнейший спор бесполезен, я поступил как считаю нужным, и считаю что мой способ лучше и быстрее.
Такое поведение возможно оправдано для StreamReader\Writer в случае когда читаются файлы, но проблемы возникнут, если источником будет нечто другое, которое не может сразу возвращать указанное количество байт.
2) Я не спорю, что это плохой код, в реальности будет другой, а библиотеку менять это еще большее зло, так как возникнет куча других проблем, например как потом быть с переделанной либой при установке приложения на другой комп.
3) А зачем это делать, если есть более лучше способ?
4) Почему не к месту? Если бы сериализатор предоставлял бы нужные мне, то я ими бы и воспользовался.