Regan Heath wrote:
> HTTP sends a Content-Length most/all? of the time.
Not all the time :-(

> So unless the readLine function has a failure return value you have to throw an exception. The same would have to be true for readInt readFloat etc.
> 
> If it had a failure return value then..
> 
> while(!i.eof()) {
>     line = i.readLine();
>     if (line.length == 0) continue;
> }
But then how do you distinguish an empty line? My preferred behaviour would be something like
 data \n \n <EOF>
^
readLine() returns "data"

 data \n \n <EOF>
        ^
readLine() returns ""

 data \n \n <EOF>
           ^
readLine() returns ""

 data \n \n <EOF>
              ^
readLine() returns null (EOF already been hit)

Sam

On Mon, 14 Jun 2004 17:27:52 +1200, Sam McCall <tunah.d@tunah.net> wrote:
> Regan Heath wrote:
>> HTTP sends a Content-Length most/all? of the time.
> Not all the time :-(
>
>> So unless the readLine function has a failure return value you have to throw an exception. The same would have to be true for readInt readFloat etc.
>>
>> If it had a failure return value then..
>>
>> while(!i.eof()) {
>>     line = i.readLine();
>>     if (line.length == 0) continue;
>> }
> But then how do you distinguish an empty line? My preferred behaviour would be something like
>   data \n \n <EOF>
> ^
> readLine() returns "data"

agreed.

>   data \n \n <EOF>
>          ^
> readLine() returns ""

shouldn't that be " "

>   data \n \n <EOF>
>             ^
> readLine() returns ""

shouldn't that be " "

>   data \n \n <EOF>
>                ^
> readLine() returns null (EOF already been hit)

you're right here.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Regan Heath wrote:
> shouldn't that be " "
Sorry, those spaces were just meant to be for decoration, so it was clear what had and hadn't been read yet.
Sam

On Mon, 14 Jun 2004 17:35:35 +1200, Sam McCall <tunah.d@tunah.net> wrote:
> Regan Heath wrote:
>> shouldn't that be " "
> Sorry, those spaces were just meant to be for decoration, so it was clear what had and hadn't been read yet.
> Sam

I thought they *might* have been, just checking. :)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Sean Kelly" <sean@f4.ca> wrote in message news:caar8o$28ba$1@digitaldaemon.com...
> One question about character output.  The docs say dchar is a 32-bit
unicode
> character but I'm pretty sure that it's currently implemented as wchar_t
in
> Windows right now (which would make it compatible with wchar).  Is there
any
> reason there shouldn't be methods to operate on all three char types:
char,
> wchar, and dchar?

dchar is 32 bits
wchar is 16 bits
char is 8 bits

The stream methods should all operate on chars as UTF-8 streams. The conversion to/from Windows 'W' functions should come as the last step.

In article <caeaju$162q$1@digitaldaemon.com>, Arcane Jill wrote:
> (The efficiency argument doesn't hold true in C++, by the way. In C++, simply copying a new value into the stack pointer would be disastrous in C++ because there may be objects on the stack whose destructors need to be called. D is more sensible).

I'd have thought that exception handling in D and C++ have the same overhead, because both have RAII classes and try-catch statements.

(In typical well-written C++ program, though, unwinding the stack takes a bit longer, since RAII is also used for memory management.)

Of course, that wouldn't matter, since typical exception handling time is still negligible if exception handling is used properly.

> My one complaint about D's exceptions is that there realy SHOULD be some standard ones in Phobos which we could reuse - things like EndOfFile, OutOfMemory, BadParameter, ReadError, Success, and so on, all in one module. They should be organized into a heirarchy which makes sense, so it becomes obvious which one to use/derive from. Constructors for these should be simple. You shouldn't need to supply a string to construct an EndOfFile, and so on.

Gets my vote. I think Matthew Wilson had something in the works a few months ago?

(I somehow find it amusing to have a language with standard exception called "Success". Certainly requires some guts to admit that success is an exceptional condition ;) No committee-designed language would ever be able to pull that off...)

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

In article <caj6cj$254g$1@digitaldaemon.com>, Sam McCall says...
>
>Is there a way in theory in general streams (sockets, files, anything
>else) to test whether we've read the last byte, without blocking? If so,
>I think something along the lines of
>while(!f.eof) {
>	bf=f.gets(BFSZ);
>	...
>}
>is likely clearer.

In general, yes.  I would consider a socket at EOF when the socket is closed. The ANSI C file API has an feof() function, and other file APIs typically have a way to determine this as well.

>> I'd only want exceptions when:
>> - the file open failed
>> - the read failed (device error etc - not end of file)
>
>What if scanf was looking for a floating point number, and it got to 6.03E+ and then hit EOF?

This is what convinced me that exceptions made sense for stream operations. Encountering an unexpected EOF *is* an exceptional situation IMO.  Other exceptional situations include unformatted operations that fail to read the desired block size (typically as a result of EOF), and formatted read operations that result in unparsable or incorrect data.  Note that this includes instances where the user tries to read an integer from the keyboard and gets a letter instead.

One thing I'm considering is adding overridable methods that handle these error conditions so derived classes can throw more meaningful exceptions.  If it's Windows and a meaningful message can be pulled from the error code then the class should be able to include that information in the exception.  Since different APIs have different ways of returning error information, it isn't really possible to put all of this in the base class.


Sean

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnccrqj5.3eo.jsykari@pulu.hut.fi...
> In article <caeaju$162q$1@digitaldaemon.com>, Arcane Jill wrote:
> > (The efficiency argument doesn't hold true in C++, by the way. In C++, simply copying a new value into the stack pointer would be disastrous in C++ because there may be objects on the stack whose destructors need to be called. D is more sensible).
>
> I'd have thought that exception handling in D and C++ have the same overhead, because both have RAII classes and try-catch statements.
>
> (In typical well-written C++ program, though, unwinding the stack takes a bit longer, since RAII is also used for memory management.)
>
> Of course, that wouldn't matter, since typical exception handling time is still negligible if exception handling is used properly.
>
> > My one complaint about D's exceptions is that there realy SHOULD be some standard ones in Phobos which we could reuse - things like EndOfFile, OutOfMemory, BadParameter, ReadError, Success, and so on, all in one module. They should be organized into a heirarchy which makes sense, so it becomes obvious which one to use/derive from. Constructors for these should be
simple.
> > You shouldn't need to supply a string to construct an EndOfFile, and so on.
>
> Gets my vote. I think Matthew Wilson had something in the works a few months ago?

Yes, we did come to an accord on the naming conventions. I have to admit, somewhat sheepishly, that I didn't write it down anywhere, trusting the newgroup archive. If someone with more time (or good form) than me wants to search last year's posts for "Exception", or maybe "Win32Exception", then I'm sure it'll be there. Perhaps once located it could be placed up there with all JC's other good stuff on the Wiki?

Lenny Lazybones

Whoops! Posted this to the another thread, but I really meant to post here instead ...

Perhaps you might consider checking out mango.io over at http://www.dsource.org/forums/viewtopic.php?t=148 ? Mango.io attempts to provide seamless integration of the following:

-Buffered I/O for Files, Sockets etc
-A variety of Readers and Writers for formatted IO, endian conversion, etc
-Multiple reader/writers upon the same buffer
-Tokens and Tokenizers for loosely formatted input (text lines, words,
numbers, etc)
-RegExp token wrapper
-Chained operations
-EOS checking is almost completely redundant (you rarely, if ever, need to
check)
-Both put/get and <</>> syntax
-Bidi equivalent of std.outbuffer (can use Readers/Writers per usual)
-Memory-mapped IO seamlessly overloads buffered IO
-Class serialization (to file, network, etc)
-CompositeIO framework for bracketing IO (such as commit semantics)
-Simply mechanism to bind your own classes into Reader/Writer framework
-Exceptions thrown for exceptional conditions (per discussion)
-Printf wrapper
-Mango.io has very little overhead, so it's *fast*. You can optionally
enable array-slicing when using CompositeReader. Tokens are always sliced,
but you can .dup them
-Includes typical file management tools (FileProxy, FileConduit), file path
manipulation (FilePath), etc
-Includes an RFC 2396 compliant URI specification
-Includes a simple Properties file reader
-Usual stdio singletons
-some <gasp> documentation!

There's a bunch more stuff in there also. Mango.io has been pretty well beaten-up by three great guys since March, so it's quite stable and robust now. Sure, there's things in there that could use improvement, but it's a reasonable start. The design is somewhat reminiscent of Java NIO, but without all the hideous IO warts that Java IO was originally saddled with. I would contend that mango.io is dramatically cleaner than the Java design; but that wouldn't be too hard, now would it? <g>

Mango.io is part of the Mango Tree, which currently includes these other modules:

-exceptionally fast HTTP server (thanks mainly to D array slicing)
-Java like servlet engine (mango.io was built with this in mind)
-Log4J clone, including an HTML monitor/console for inspecting and setting
log/debug status at runtime (plus Chainsaw integration
-An HTTP client
-some simple caching mechanisms, including virtual caching to disk.

I invite you to take a look, and comment. It'd be great if we could turn mango.io into a truly excellent IO platform for D ...

- Kris


"Sean Kelly" <sean@f4.ca> wrote in message news:ca82sq$u9n$1@digitaldaemon.com...
> I think the D streams provide a good base but are missing some of the more complex features that I miss from C++, mostly to do with formatted i/o.
This
> raises the rather large issue of localization which I'm going to ignore
for the
> moment.
>
> As things stand, the basic D stream framework has an InputStream and OutputStream interface and then a single Stream class that implements both
of
> these.  File, MemoryStream, SliceStream, and BufferedStream all inherit
from
> Stream, while BufferedFile inherits from BufferedStream.  Stream and File
do not
> buffer by default, BufferedStream acts as an adaptor class, and
BufferedFile is
> the buffered version of the File stream class.  Currently, all formatted
i/o
> goes through the printf method, with the read/write methods offering
unformatted
> i/o.  There is also an OutBuffer class (though no corresponding InBuffer)
which
> seems functionally similar to MemoryStream.
>
> I'd like separate InputStream, OutputStream, and Stream base classes to
allow
> support for streams where only input or output makes sense.  To make it
clear
> these are base classes and prevent naming problems with the interfaces I
propose
> these names: InputStreamBase, OutputStreamBase, and StreamBase (or InputOutputStreamBase, though that's pretty darn verbose).  Because of the single inheritance rule, StreamBase won't be able to inherit from InputStreamBase and OutputStreamBase which will liekly result in some
toying
> with the design to avoid code duplication.  These classes will be
obviously be
> abstract base classes.  If I wanted to nit-pick I might suggest renaming
File to
> FileStream for consistency.
>
> In addition to the existing functionality I propose new formatted i/o
methods
> for all types that already have unformatted methods.  Apart from a few
instances
> these can forward most of the work to the existing printf method.  The
default
> methods would be "get" and "put" with the possibility of adding overloaded operator support in the future.  I'd also like to see something similar to
the
> callback mechanism in C++ streams so arbitrary classes can hook in
formatting
> information.  And Jill had mentioned wanting something similar to
readsome()
> from C++ streams so I suspect this list will grow a bit.
>
> As for open issues, someone with more experience than myself should
probably
> address localization.  At the very least, there should be some support for proper numeric formatting, but that raises the issue of how formatting
rules
> will be supplied to the stream classes and what else the localization
rules
> should cover.
>
> I'm willing to go and do this myself, but as it's a modification of
existing
> Phobos stuff I wanted to get some feedback.  Does anyone have any
objections or
> suggestions?  Assuming the design doesn't suck will it have a chance for inclusion?
>
>
> Sean
>
>

Matthew wrote:
> "Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message
> news:slrnccrqj5.3eo.jsykari@pulu.hut.fi...
> 
...
>>
>>>My one complaint about D's exceptions is that there realy SHOULD be some
>>>standard ones in Phobos which we could reuse - things like EndOfFile,
>>>OutOfMemory, BadParameter, ReadError, Success, and so on, all in one module.
>>>They should be organized into a heirarchy which makes sense, so it becomes
>>>obvious which one to use/derive from. Constructors for these should be
> 
> simple.
> 
>>>You shouldn't need to supply a string to construct an EndOfFile, and so on.
>>
>>Gets my vote. I think Matthew Wilson had something in the works a few
>>months ago?
> 
> 
> Yes, we did come to an accord on the naming conventions. I have to admit,
> somewhat sheepishly, that I didn't write it down anywhere, trusting the newgroup
> archive. If someone with more time (or good form) than me wants to search last
> year's posts for "Exception", or maybe "Win32Exception", then I'm sure it'll be
> there. Perhaps once located it could be placed up there with all JC's other good
> stuff on the Wiki?
> 
> Lenny Lazybones

FYI, I think I found the thread you were remembering. It was called "Exception naming conventions - Phobos, and third party libraries" (yay, for helpful thread subjects).

http://www.digitalmars.com/drn-bin/wwwnews?D/15869

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/