TStream

← →
Sour (2001-12-23 20:32) [0]

Что такое TStream и его потомки. И зачем все они нужны. Про Tthread знаю, а про Stream нет.

← →
Al Creator (2001-12-23 21:19) [1]

А что тут может быть неясеого? Stream - поток, даёт возможность разделить, теретически, выполняемые задачи программы и делать их парралельно, а в реальности - одно делается, всё остальное тормозит. Вообще-то зачем они нужны я сказать не могу, мой брат пытался их применить, но в конце-концов забил на это дело. Реально всегда можно без него обойтись, но может быть и пригодятся, хотя мне такого не выпало счастья...

← →
Suntechnic (2001-12-23 22:13) [2]

> Al Creator © (23.12.01 21:19)
Этика форума предполагает молчание, если предмет обсуждение представляется настолько далёким...

> Sour © (23.12.01 20:32)
О TStream можно уже судить по его названию. Это базовый класс потока байтов связанный с каким либо логическим или виртуальным устройством. Например поток связанный с памятью или с файлом на диске или с тем, с чем ты посчитаешь нужным(для этого надо будет написать свой класс потока, отнаследовавшись от базового TStream). Рассказать зачем это надо тяжело на пальцах, пока ты сам не сталкнёшься с подобными задачами. TStream просто позволяет нам перейти на уровень абстракции и не задумываться над деталями реализации.
Типичный пример: Задача сохранить в БД поле типа BLOB(Binary Large Object). Длина BLOB полей может достигать 2GB. Сам подумай что должна принимать ф-ция сохранения BLOB объекта в качестве параметра? Массив? Использование 2GB массива выглядит проблематично... Писать по частям? Тогда необходима реализация либо callback ф-ций, либо вызов дополнительных ф-ций, но это просто неудобно да и сам подход не очень гибкий...
Подумав минут 10 над подобной задачей ты сам убидишься в необходимости существования таких вещей как потоки.

← →
Sour (2001-12-23 22:49) [3]

>Suntechnic
Спасибо за ответ. Но похвольте задать встечный вопрос. Типичная задача: Сохранение чего-либо не большого, много меньшего 2 Gb, в файл, целесообразно реализация потоком?

← →
Вадим (2001-12-23 23:27) [4]

Если при этом прога сильно тормозит, то да, если не тормозит, то нет :)

← →
SerGa (2001-12-24 00:10) [5]

> Вадим
А ты уверен, что Sour понимает смайлики?

← →
Sour (2001-12-24 03:59) [6]

>SerGa
Ваш потрясающий вооюражения юмор, думаю был оценен всеми участниками. Вам бы в КВН играть...

← →
Sour (2001-12-24 03:59) [7]

>SerGa
Ваш потрясающий воображения юмор, думаю был оценен всеми участниками. Вам бы в КВН играть...

← →
Suntechnic (2001-12-24 04:54) [8]

>Sour © (23.12.01 22:49)
>Сохранение чего-либо не большого, много меньшего 2 Gb, в файл, целесообразно реализация потоком?

Понимаешь в чём вся суть... написать можно чего угодно и как угодно... например структурный поход в программировании работает иногда даже быстрее ООП, но почему то все стараются его избежать... дело абсолютно не в размерах, дело в подходе. Если ты хочешь написать что то действительно гибкое и расширяемое то тебе надо мыслить именно этими мерками... Приведу тебе тогда другой пример использования потока, где размер не играет никакой роли.
Представь себе ты решаешь задачу обмена данными через сокеты(чат например). Имеется объект сообщение, который помимо текстовой информации может нести в себе ещё и ID отсылаемого и ID получателя, а также картинки и т.д. и т.п. На самом деле размер такого сообщения редко когда превысит 1Kb. Так вот один из подходов предполагает написание ф-ции которая будет принимать параметрами информацию о сокете и об объекте и посылать эту информацию адресату. Вроде всё красиво. Но завтра приходит заказчик и говорит я хочу эти сообщения ещё и в файл писать... а после завтра говорит я ещё хочу пересылать эти сообщения между процессами на одной машине... в итоге появляется 3 ф-ции: SendMessageToSocket, SaveMessageToFile, SendMessageToProcess в каждой из них будут происходить одни и те же действия: объект будет "раскладываться" по-байтно и отсылаться. А ещё через день придёт опять заказчик и скажет я хочу переслать ещё "пару байт" и ты вынужден будешь переписать все эти методы по отсылке(и столько же по приёму объекта)... Но возможно другое архитектурное решение. Где все необходимые "объекты передачи"(сокет, файл и т.д.) будут "уметь" работать с одним базовым объектом "Поток". Ведь всё равно всё придёт к необходимости отсылки цепочки байт. Поэтому пишем у нашего объекта "Message" два метода "SaveToStream", "LoadFromStream". Проще говоря объект сам знает как себя записать и как себя считать из потока. В результате если тебя кто-нибудь попросит пререслать ещё пару "лишних" байт ты просто переписываешь два метода "SaveToStream", "LoadFromStream" вместо 6. Более того ты можешь присвоить "версию" потоку. Грубо говоря один поток умеет пересылать картинки, а другой нет. И анализ опять же будет происходить в методах "SaveToStream", "LoadFromStream".

...вообщем много я тут наговорил. Повторяю ещё раз: написать можно и так и так. В результате конечный пользователь всё равно ничего не увидит :). Но дело в подходе. Если ты присмотришься поблжиже к VCL, она именно так и устроена и мне этот подход ближе, а ты сам выбирай...

← →
Александр С. (2001-12-24 10:18) [9]

>Sour Бросил по почте статью, с примером TFileStream.
Думаю поможет разобраться.

TStream Найти похожие ветки