[fpc-devel] Benchmark for FreePascal

Michael Van Canneyt michael at freepascal.org
Mon Dec 12 11:04:44 CET 2005



On Mon, 12 Dec 2005, darekM wrote:

> Michael Van Canneyt napisa(a):
>
>> 
>> 
>> On Sun, 11 Dec 2005, darekM wrote:
>> 
>>> Michael Van Canneyt napisa(a):
>>> Why not descend. Why not exceed tFileStream, its natural. I want read text 
>>> file in the same way like binary file.
>> 
>> 
>> Because then you must also descend THandlestream, TPipeStream,
>> TIOStream, TDecompressionStream, TMemorystream, TDecodestream
>> etc etc etc.
>> 
>> Streams are more than just for files.
>
>
> Why must, for me my tTextStream is for readin text file, of course we may 
> implemented readln in tBufStream

Pipes, Compressed Streams, IO, Decode and so on can also contain text.
Your implementation requires that we re-implement your solution in all
of these classes if we want to have the 'readln()' functionality
available.

>>> While complicated, when it only 2 procedure should be added. Form me 
>>> tTextStream should be used to fast and simple read text file (or 
>>> application input stream) and no others, no allocate nor reallocate 
>>> buffer. only simple read (and write).
>> 
>> 
>> It's not so simple.
>
> It is.I've implemented it. Of course if we want to make universal bufStream 
> then take it more work.

And that is what is needed.

>>>> 3. There is already a buffered stream (TBufStream, unit bufstream), I 
>>>> suggest you enhance that.
>>>> 
>>> Sorry, i don;t know about it. Its simple to implemented it.
>>> 
>>> But why it is in separated unit, nobody know about it (or to few). F.e. 
>>> Lazarus has own implementation of buffering.
>>> If we want to make faster programs, object like my should be in core unit, 
>>> then everybody use them, in other case every make own implementation.
>> 
>> 
>> Maybe, but then we should put all streams in Classes, and we're not going 
>> to
>> do that.
>> 
>> 
> But tBufStream is Owner of stream, for me is separated idea

That is optional behaviour, and disabled by default.

Michael.



More information about the fpc-devel mailing list