Re: Replacement for Text_IO? (was Re: C bug of the day)

[Dale Stanbrough <dstanbro@bigpond.net.au>]

Gautier Write-only wrote:

> Dale Stanbrough:
> 
> > Everyone laments the slowness of Text_IO,
> 
> Who ? Who ?

Are you an owl? I'm sure one "who?" would do.

Ok, it was a bit of hyperbole. -I- don't like the slowness of Text_IO :-)

Robert Dewar at one point noted that the presence of these extra
"features" prevents certain optimisations in the coding from taking
place.

One quote from him...


"Text_IO is convenient for small scale or occasional use for small
 amounts of formatted output (compare it to ACCEPT and DISPLAY use
 in COBOL). It is not the appropriate interface for large scale I/O
 where performance is critical."


try also...

http://groups.google.com.au/groups?q=robert+dewar+text_io+efficiency+grou
p:comp.lang.ada&hl=en&lr=&ie=UTF-8&group=comp.lang.ada&selm=3id0ip%24e42%
40gnat.cs.nyu.edu&rnum=2

Why not -make- it suitable for large scale I/O? Why not ensure that
everyone who wants to do some I/O doesn't have the thought in the 
back of their head "shouldn't really use text_io because it doesn't
scale".


> Are you sure that *this* takes much time ? Did you do a profiling ?

No, but I believe what Robert Dewar said. It makes me hesitant to 
recommend people code with Text_IO, which is problematic. It should
be possible to have one I/O package which is good, and people feel
will be able to grow with their application.


> > as well as moving the generic I/O packages into child packages.
> 
> It is an aesthetic issue (although, who cares ?), not a performance
> one... Do such non-instanciated generic sub-packages even appear in
> the machine-code in object files, on any compilation system ?

See Randy's followup. I didn't realise it was a problem efficieny wise,
but i've always found it an annoyance when teaching Ada to students.
It's much easier to talk about child packages than encapsulated packages.

Dale