Last september Bent Rasmussen (there might be others but this
http://www.digitalmars.com/d/archives/digitalmars/D/10156.html is the one I
found) suggested adding
bit eof()
bit isOpen()
to InputStream and
bit isOpen()
void flush()
void close()
to OutputStream. Those requests seem reasonable to me. Any complaints? Otherwise
I'll include them with my std.stream bugfixes.

-Ben

On Wed, 20 Apr 2005 00:54:59 +0000 (UTC), Ben Hinkle wrote:

> Last september Bent Rasmussen (there might be others but this
> http://www.digitalmars.com/d/archives/digitalmars/D/10156.html is the one I
> found) suggested adding
> bit eof()
> bit isOpen()
> to InputStream and
> bit isOpen()
> void flush()
> void close()
> to OutputStream. Those requests seem reasonable to me. Any complaints? Otherwise
> I'll include them with my std.stream bugfixes.
> 

May I suggest that 'bool' be used rather than 'bit'?

Yes I know its an alias today, but maybe one glorious day in the future, D might support a real boolean type and you will be ready for it.

-- 
Derek
Melbourne, Australia
20/04/2005 11:25:40 AM

In article <vknwiwes4n13$.ag9ivtqwqy2k$.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 20 Apr 2005 00:54:59 +0000 (UTC), Ben Hinkle wrote:
>
>> Last september Bent Rasmussen (there might be others but this
>> http://www.digitalmars.com/d/archives/digitalmars/D/10156.html is the one I
>> found) suggested adding
>> bit eof()
>> bit isOpen()
>> to InputStream and
>> bit isOpen()
>> void flush()
>> void close()
>> to OutputStream. Those requests seem reasonable to me. Any complaints? Otherwise
>> I'll include them with my std.stream bugfixes.
>> 
>
>May I suggest that 'bool' be used rather than 'bit'?
>
>Yes I know its an alias today, but maybe one glorious day in the future, D might support a real boolean type and you will be ready for it.
>
>-- 
>Derek
>Melbourne, Australia
>20/04/2005 11:25:40 AM

May I also suggest that when passing in a ubyte[] data to the MemoryStream constructor, that the MemoryStream works on that physical location of memory, instead of having to copy the MemoryStream's data back to where you got it from.

I encountered this strangeness when I was using SDL_Net library to do some UDP socket programming.  The UDPpacket asks for a ubyte* field called data and the SDLNet_AllocPacket function already allocates memory for that field with malloc() (since it is a C library).

I was expecting MemoryStream to work on that memory area that was already allocated when I passed the data pointer to the constructor as a sliced array. I guess the default behavior is to copy the contents from that buffer into a new one and dynamically grow that.

Other than that unintuitive bit of behavior, your library is generally pretty nice!  Thanks for your hard work, Ben.

Regards,
James Dunne

>May I also suggest that when passing in a ubyte[] data to the MemoryStream constructor, that the MemoryStream works on that physical location of memory, instead of having to copy the MemoryStream's data back to where you got it from.

It should only reallocate when growing the array to hold more content than the
original passes in. So for example if the code looks like
# ubyte[] data = new ubyte[100];
# MemoryStream s = new MemoryStream(data);
then s.data and s.toString should return slices of the original array up until
100 bytes have been written and then the MemoryStream needs to grow the array
and so it might be reallocated then.

>I encountered this strangeness when I was using SDL_Net library to do some UDP socket programming.  The UDPpacket asks for a ubyte* field called data and the SDLNet_AllocPacket function already allocates memory for that field with malloc() (since it is a C library).

Do you know how big those arrays were? If you can narrow down some reproduction steps I can look into it because I agree MemoryStream should reuse the array passed to the ctor.

>I was expecting MemoryStream to work on that memory area that was already allocated when I passed the data pointer to the constructor as a sliced array. I guess the default behavior is to copy the contents from that buffer into a new one and dynamically grow that.
>
>Other than that unintuitive bit of behavior, your library is generally pretty nice!  Thanks for your hard work, Ben.
>
>Regards,
>James Dunne

>May I suggest that 'bool' be used rather than 'bit'?

will do.

Derek Parnell wrote:

> May I suggest that 'bool' be used rather than 'bit'? 
> 
> Yes I know its an alias today, but maybe one glorious day in the future,
> D might support a real boolean type and you will be ready for it.

Who knows, one day "bool" might even be a real D *keyword*... ?

Yes, I know it's just an alias and those don't have keywords.
But then again, true and false are just integer constants now
and those usually don't have any designated keywords either ?

So "consistency" says for true / false to not be keywords. :-(


Sadly, there doesn't seem to be *any* chance of D _ever_ getting
semantics like C#/Java has. So we have to make do with "stdbool".
And, just maybe, "bit" is a better word for it than "_Bool" is ?

I think this boolean matter was settled even years ago, at least
it seemed to have been so when I stumbled into it here last fall:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11575


Be with that as it may, IMHO in this case "bool" is more readable:
	bool isOpen();
But I guess some will argue that returning an int is more efficient ?

--anders


PS. For those new to the subject, the D bit _type_ is boolean
    enough (it only takes 0 or 1 values), it's the _expressions_
    that involve "bool" that now cheerfully converts between types...

    See http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

In article <d44gi3$250k$1@digitaldaemon.com>, Ben Hinkle says...
>
>>May I also suggest that when passing in a ubyte[] data to the MemoryStream constructor, that the MemoryStream works on that physical location of memory, instead of having to copy the MemoryStream's data back to where you got it from.
>
>It should only reallocate when growing the array to hold more content than the
>original passes in. So for example if the code looks like
># ubyte[] data = new ubyte[100];
># MemoryStream s = new MemoryStream(data);
>then s.data and s.toString should return slices of the original array up until
>100 bytes have been written and then the MemoryStream needs to grow the array
>and so it might be reallocated then.
>
>>I encountered this strangeness when I was using SDL_Net library to do some UDP socket programming.  The UDPpacket asks for a ubyte* field called data and the SDLNet_AllocPacket function already allocates memory for that field with malloc() (since it is a C library).
>
>Do you know how big those arrays were? If you can narrow down some reproduction steps I can look into it because I agree MemoryStream should reuse the array passed to the ctor.
>

After some more debugging I realize it was my code that was in error.  I was using a custom-written function to write data to the stream that wasn't writing anything out.  Oops!  Sorry Ben.  Great work - there is no bug ;)  It works now.

Regards,
James Dunne

Anders F Björklund wrote:
> Derek Parnell wrote:
> 
>> May I suggest that 'bool' be used rather than 'bit'?
>> Yes I know its an alias today, but maybe one glorious day in the future,
>> D might support a real boolean type and you will be ready for it.
> 
> 
> Who knows, one day "bool" might even be a real D *keyword*... ?
> 
> Yes, I know it's just an alias and those don't have keywords.
> But then again, true and false are just integer constants now
> and those usually don't have any designated keywords either ?
> 
> So "consistency" says for true / false to not be keywords. :-(
> 
> 
> Sadly, there doesn't seem to be *any* chance of D _ever_ getting
> semantics like C#/Java has. So we have to make do with "stdbool".
> And, just maybe, "bit" is a better word for it than "_Bool" is ?
> 
> I think this boolean matter was settled even years ago, at least
> it seemed to have been so when I stumbled into it here last fall:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11575
> 
> 
> Be with that as it may, IMHO in this case "bool" is more readable:
>     bool isOpen();
> But I guess some will argue that returning an int is more efficient ?
> 
> --anders
> 
> 
> PS. For those new to the subject, the D bit _type_ is boolean
>     enough (it only takes 0 or 1 values), it's the _expressions_
>     that involve "bool" that now cheerfully converts between types...
> 
>     See http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

All I hope is that we're consistent!!

The boss of a sw company I recently raved about D to, took a look at the sources delivered with DMD, and he was unimpressed.

First he had a hard time figuring out this "bit" stuff. (I know, I know!)

Then he was amazed about bit and bool being both used.

Understandably, I had to talk for an extra hour, just to patch up his dented impression of D.   :-(  :-(  :-(

------------

And while I'm at it, somebody well versed in Perl could probably write a script that goes through the entire source tree, and converts variable names to something consistent.

  my_foo, MyFoo, myFoo....  good grief.

A Perl guru ought to write it in 15 minutes.

A major contribution to the D community, if I ever saw one done in 15 minutes!

Georg Wrede wrote:

> The boss of a sw company I recently raved about D to, took a look at the sources delivered with DMD, and he was unimpressed.

To learn about a new language, he looked at the source code first ?

Hmmm... I think we need some more slideshows.

> First he had a hard time figuring out this "bit" stuff. (I know, I know!)
> 
> Then he was amazed about bit and bool being both used.

Aren't we all. Then again, "bit" isn't being used all that much...

It's just a built-in type ? (like C99 _Bool)


> Understandably, I had to talk for an extra hour, just to patch up his dented impression of D.   :-(  :-(  :-(

Yeah, I think it is a pretty common experience. And it usually
stumbles on a few pretty basic concepts and misunderstandings.

Like: "why is there no boolean type", "why is there no string type",
or "why doesn't D support extended ASCII" and the rest of the FAQ ?


And it's also usually a lot easier to come from old C to D,
than to be used to C++ or Java or any other newer language.

Then you are used to booleans as integers and strings as
arrays of characters, and not spoiled with having types. :-)

--anders

I've used almost all of the known languages out there for some reason or another and the only reason I can think of ever wanting a String type is for OO. You would be able to say ThisIsSomeString.strip() like you can in Ruby or Java. Booleans/bits are the same purpose; and theres already an alias in the standard library.

But then again I'm too grateful of not having different syntax based on if something is a pointer or if its local, lol. That, and having to worry about segfaults because your char[] didn't use the right symbol so  it doesn't transfer right.

-JC