массив байт в файл?

← →
Dysan © (2004-04-28 17:53) [0]

Мастера не подскажите как быстро записать массив байт в файл?

← →
Skier © (2004-04-28 17:53) [1]

через TFileStream

← →
Smithson © (2004-04-28 17:54) [2]

type TByteArray = Array[7.16] of byte;
var F: File of TByteArray;

Write + F1

← →
WebErr © (2004-04-28 17:55) [3]

File, BlockWrite + F1
Рекомендую Rewrite(F,1);

← →
WebErr © (2004-04-28 17:57) [4]

> Skier © (28.04.04 17:53) [1]

Сие не так быстро к сожалению.

← →
han_malign © (2004-04-28 18:15) [5]

procedure fLogBuf(FName : String; var Buf; BufSize : Integer); var fh : THandle; bw : LongWord; begin if BufSize <= 0 then Exit; fh := CreateFile(PChar(FName), GENERIC_WRITE, FILE_SHARE_READ, nil, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); if fh <> INVALID_HANDLE_VALUE then begin SetFilePointer(fh, 0, nil, FILE_END); WriteFile(fh, Buf, BufSize, bw, nil); CloseHandle(fh); end; end;
- с дописыванием в конец

← →
Dysan © (2004-04-28 18:37) [6]

что то не получаеться.
т.е. нет, получаеться переписать байт в байт.
но я переписываю exe файл хранящийся в базе, ввиде коллекции байтов.
обычным перебором этих байт и записываением их по очереди, все получаеться!
а вот
CreateFile(PChar(FName), GENERIC_WRITE ...
и BlockWrite
пишут не exe файл ! :(

← →
Anatoly Podgoretsky © (2004-04-28 18:40) [7]

WebErr © (28.04.04 17:57) [4]
Назови быстрее, но только достоверно, а не кажется.

Dysan © (28.04.04 18:37) [6]
CreateFile и BlockWrite несовместимы.

← →
Dysan © (2004-04-28 18:46) [8]

а я и не говорил что они совместыми должны быть
это два разных способа выше предложенных
так вот ни один почему то не пишет то что надо!!!!

← →
WebErr © (2004-04-28 18:47) [9]

> Anatoly Podgoretsky © (28.04.04 18:40) [7]

F: File; ... Rewrite(F, SomeNum); ... BlockWrite(...);
Это быстрейшее, но не самое рациональное в многопоточной системе.

← →
Anatoly Podgoretsky © (2004-04-28 18:51) [10]

Я просил не предположение, а обоснование, с результатами измерений и методикой измерения.

← →
WebErr © (2004-04-28 18:54) [11]

> Anatoly Podgoretsky © (28.04.04 18:51) [10]

Сами и измеряйте, Фома Неверующий...
В TP 7.0. быстрее выполняется, чем на D7 - это факт, но чтобы медленнее чем threads, с их Create/Terminate и прочим...

← →
Anatoly Podgoretsky © (2004-04-28 18:56) [12]

В TP 7.0. нет TFileStream
Зачем ты приплел сюда threads, с Create/Terminate
Ты больше не кури

← →
Amoeba © (2004-04-29 16:15) [13]

> В TP 7.0. нет TFileStream

Есть в прилагающейся к нему библиотеке TurboVision

← →
Goida © (2004-04-29 16:17) [14]

Тогда определитесь: высокоуровневый доступ или низкоуровневый доступ нужен.

← →
WebErr © (2004-04-29 16:28) [15]

> Anatoly Podgoretsky © (28.04.04 18:56) [12]

Протрезвев я понял, что stream использует thread.
При крутом процессоре с MiltyThreading"ом все затраты на создание потока, удаление его и действия с ним сводятся к минимуму - остаются одни достоинства, вывод, если бабушка сидит в аптеке на Win95 и использует Intel 386, то ей может не помочь streams с treads"ами - факт. Так что это весьма спорный вопрос!

← →
Digitman © (2004-04-29 16:37) [16]

> WebErr © (29.04.04 16:28) [15]
>
> Протрезвев я понял, что stream использует thread.
> При крутом процессоре с MiltyThreading"ом все затраты на
> создание потока, удаление его и действия с ним сводятся
> к минимуму - остаются одни достоинства, вывод, если бабушка
> сидит в аптеке на Win95 и использует Intel 386, то ей может
> не помочь streams с treads"ами - факт. Так что это весьма
> спорный вопрос!

бред какой-то ...

каша полная в голове

← →
WebErr © (2004-04-29 16:43) [17]

> Digitman © (29.04.04 16:37) [16]

Sorry за непонятное изложение...
Завтра схожу к такой бабушке, если время будет, и принесу результаты вычислений на её компутере.
Ну вот опять: Stream vs Teletype.

← →
Юрий Зотов © (2004-04-29 16:44) [18]

Stream - поток. Thread - тоже поток. Cледовательно, "stream использует thread".

А может, просто еще не до конца протрезвел.

← →
Digitman © (2004-04-29 16:48) [19]

> WebErr © (29.04.04 16:43) [17]

это ты перед автором извиняйся, что чушь несешь заведомо и дезинформируешь его ..

трэд - кодовый поток (объект системы)
стрим - поток данных (прикладной объект)

ничего общего эти два понятия между собой не имеют

← →
Digitman © (2004-04-29 16:51) [20]

> WebErr

зато весьма горазд демагогию разводить про приватные и защищенные идентификаторы

уж не казал бы ты наизнанку при всем честном народе свое дилетантство !

← →
WebErr © (2004-04-29 16:52) [21]

Sorry... попутал...

← →
WebErr © (2004-04-29 16:53) [22]

> Digitman © (29.04.04 16:51) [20]

Уж чья бы корова мычала... 8)

← →
WebErr © (2004-04-29 17:05) [23]

> Юрий Зотов © (29.04.04 16:44) [18]
> Stream - поток. Thread - тоже поток. Cледовательно, "stream
> использует thread".

Нет, не поэтому. Просто я решил, что если каждый stream использует thread, то это логично. Но я посмотрел исходники TStream и понял, как жестоко я ошибался. Даже память там "вручную" выделяется под буффер.

← →
Goida © (2004-04-29 17:16) [24]

У меня появился такой вопрос:
Сколько происходит обращений на запись к диску, если файл мы открыли с помощью reset(f,700) и записываем с помощью blockwrite столько же байт?

← →
default © (2004-04-29 17:26) [25]

Goida © (29.04.04 17:16) [24]
фиг знает,(надо только его найти) по идее это должна решать обслуга ОС
подумай если оп-ой памяти не хватает чтобы загрузить все данные в оп-ую память потом разом выгрузить на диск, то придёся загр-ить в оп-ую память кусок(размером n * RecSize, n зависит от того сколько оп-ой памяти можно исполь-ать) затем выгр-ить на диск и так до победы

← →
Vit@ly © (2004-04-29 17:28) [26]

Скорее Rewrite(f, ...)

← →
panov © (2004-04-29 17:31) [27]

Чем TFileStream-то не устраивает?

← →
Anatoly Podgoretsky © (2004-04-29 17:35) [28]

Goida © (29.04.04 17:16) [24]
Это решает система, но минимум два при стандартном форматировании.

Goida © (29.04.04 17:16)

> Сколько происходит обращений на запись к диску, если файл
> мы открыли с помощью reset(f,700) и записываем с помощью
> blockwrite столько же байт?

От нуля до заведомо неизвестного количества

1.> От нуля до заведомо неизвестного количества

2.> Это решает система, но минимум два при стандартном форматировании

Это для многозадачной ОС. А как для Дос дело обстояло? Подозреваю, что 2й вариант?

Goida © (29.04.04 17:16) [24]
если тебя очень беспокоит число обращений к диску, то записывай на диск как тебе нужно сам
пиши в оп-ую память данные(сколько? - зависит от её своб-ого размера чтоб оптим-ать запись на диск)потом скидывай пинудительно данные на диск что-то вроде FlushBuffer есть в распоряжении...

> А как для Дос дело обстояло? Подозреваю, что 2й вариант?

А как обстояло для CP/M-80 не интересует ?

Для ДОС - то же самое. Все зависит от кэша системы (SmartDrv или еще что-то)

> default

:) Тогда уж лучше с помощью асма и 13 прерывания... Или нет?

> default © (29.04.04 17:39) [31]

> если тебя очень беспокоит число обращений к диску

Меня это интересует тольлко теоретически. Просто если думать о скорости, тогда надо и обращений к диску добиваться минимальных...

> Просто если думать о скорости, тогда надо и обращений к
> диску добиваться минимальных...

Не надо

> Игорь Шевченко

Странно... Почему? Ведь от этого зависит скорость.

> Игорь Шевченко

Если так, то да... Но вообще, от этого зависит ведь скорость.

> Но вообще, от этого зависит ведь скорость.

Тут два варианта - либо нужно записать некий объем информации на диск, либо не нужно :)

массив байт в файл? Найти похожие ветки