www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - InputStream/OutputStream

reply Ben Hinkle <Ben_member pathlink.com> writes:
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
Apr 19 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Apr 19 2005
next sibling parent reply James Dunne <jdunne4 bradley.edu> writes:
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
Apr 19 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
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


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
Apr 19 2005
parent James Dunne <jdunne4 bradley.edu> writes:
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


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
Apr 20 2005
prev sibling next sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
May I suggest that 'bool' be used rather than 'bit'? 


will do.
Apr 19 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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

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
Apr 20 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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

 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!
Apr 20 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 20 2005
parent reply Joshua Cearley <jtech ezoob.com> writes:
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
Apr 20 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 20 Apr 2005 13:16:27 -0500, Joshua Cearley <jtech ezoob.com> wrote:

 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.


And D:

char[] strip(char[] input) {}
char[] a;
char[] b;
b = a.strip();

It's a lovely little feature of arrays. I'm hoping it's extended to 'int'  
etc.

Regan
Apr 20 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <opspjwg8y923k2f5 nrage.netwin.co.nz>, Regan Heath says...

On Wed, 20 Apr 2005 13:16:27 -0500, Joshua Cearley <jtech ezoob.com> wrote:

 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.


And D:

char[] strip(char[] input) {}
char[] a;
char[] b;
b = a.strip();

It's a lovely little feature of arrays. I'm hoping it's extended to 'int'  
etc.

Regan


That's pretty neat; is it documented anywhere?

Kevin
Apr 21 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 22 Apr 2005 05:41:38 +0000 (UTC), Kevin Bealer  
<Kevin_member pathlink.com> wrote:

 In article <opspjwg8y923k2f5 nrage.netwin.co.nz>, Regan Heath says...

 On Wed, 20 Apr 2005 13:16:27 -0500, Joshua Cearley <jtech ezoob.com>  
 wrote:

 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.


 And D:

 char[] strip(char[] input) {}
 char[] a;
 char[] b;
 b = a.strip();

 It's a lovely little feature of arrays. I'm hoping it's extended to  
 'int'
 etc.

 Regan


 That's pretty neat; is it documented anywhere?


Not to my knowledge.

Regan
Apr 22 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <42664D91.1070405 nospam.org>, Georg Wrede says...

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.


Personally, I never use the 'bool' alias as I feel it's misleading.  I do use
'true' and 'false' however, just because I find that much more useful than '1'
and '0'.


Sean
Apr 20 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d46it3$1d9d$1 digitaldaemon.com...

 In article <42664D91.1070405 nospam.org>, Georg Wrede says...

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.


 Personally, I never use the 'bool' alias as I feel it's misleading.  I do 
 use
 'true' and 'false' however, just because I find that much more useful than 
 '1'
 and '0'.


Out of curiosity, does the D spec actually say what the values of bit are? I 
thought they were true and false since the .init value is false. The types 
of 1 and 0 are ints that get implicitly converted to true/false.
Apr 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 Out of curiosity, does the D spec actually say what the values of bit are? I 
 thought they were true and false since the .init value is false. The types 
 of 1 and 0 are ints that get implicitly converted to true/false. 


The values of bit are 0 and 1. "true" is a const bit 1, and "false" a 0.
(to make things more exciting, those constants are D compiler-internal)

And when you for instance put a 2 into a bit, it gets the value of 1...
(as does any non-zero integer you put into it. 0 is still 0, or "false")

It's truly confused. But it works the same as the _Bool type does, in C.
--anders

PS.
     assert(typeid(typeof(true)) == typeid(bit));
     assert(typeid(typeof(false)) == typeid(bit));
     assert(bit.sizeof == 1);
     assert(true == 1);
     assert(false == 0);
Apr 21 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d48gqn$7kq$1 digitaldaemon.com...

 Ben Hinkle wrote:


 Out of curiosity, does the D spec actually say what the values of bit 
 are? I thought they were true and false since the .init value is false. 
 The types of 1 and 0 are ints that get implicitly converted to 
 true/false.


 The values of bit are 0 and 1. "true" is a const bit 1, and "false" a 0.
 (to make things more exciting, those constants are D compiler-internal)


By 0 and 1 I mean the values with type int, since that is how D parses the 
constants 0 and 1. I agree a 1 with type bit is defined to be "true" so they 
are indistinguishable. The constants 0 or 1 (with type int) are implicitly 
converted to false or true (which are by definition 0 or 1 with type bit). 
So I still think it's accurate to say the values of bit are true and false 
since that implies the correct type while saying the values are 0 and 1 
confuse the type bit with int. To illustrate
assert(typeid(typeof(1)) == typeid(bit));
fails.


 And when you for instance put a 2 into a bit, it gets the value of 1...
 (as does any non-zero integer you put into it. 0 is still 0, or "false")


I can't assign 2 to a variable of type bit. It says it can't convert int to 
bit. Do you mean cast(bit)2?


 It's truly confused. But it works the same as the _Bool type does, in C.
 --anders

 PS.
     assert(typeid(typeof(true)) == typeid(bit));
     assert(typeid(typeof(false)) == typeid(bit));
     assert(bit.sizeof == 1);
     assert(true == 1);
     assert(false == 0);


These make sense to me. true and false are implicitly convertible to 1 and 0 
(the ints).
Apr 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 So I still think it's accurate to say the values of bit are true and false 
 since that implies the correct type while saying the values are 0 and 1 
 confuse the type bit with int. To illustrate
 assert(typeid(typeof(1)) == typeid(bit));
 fails.


That's correct. I guess one *should* say the "bit" is true and false.
Like many others, I am more comfortable with using the alias "bool".


And when you for instance put a 2 into a bit, it gets the value of 1...
(as does any non-zero integer you put into it. 0 is still 0, or "false")


 
 I can't assign 2 to a variable of type bit. It says it can't convert int to 
 bit. Do you mean cast(bit)2?


Sorry, yes - that is what I meant. Thus, bit is not an integer type ?
(which is easy to believe if you just hear the term "bit" being used)


I still don't know what all the fuss about calling it "bit" is about.
(why it wasn't named "bool" in the first place... probably the size ?)

Oh well, that's been decided since long. Time to move on, for sure.
I'll try not to mutter, when next newcomer to D wonders about this...

--anders
Apr 21 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 21 Apr 2005 18:23:37 +0200, Anders F Björklund wrote:


 Ben Hinkle wrote:
 

 So I still think it's accurate to say the values of bit are true and false 
 since that implies the correct type while saying the values are 0 and 1 
 confuse the type bit with int. To illustrate
 assert(typeid(typeof(1)) == typeid(bit));
 fails.


 
 That's correct. I guess one *should* say the "bit" is true and false.
 Like many others, I am more comfortable with using the alias "bool".
 

And when you for instance put a 2 into a bit, it gets the value of 1...
(as does any non-zero integer you put into it. 0 is still 0, or "false")


 
 I can't assign 2 to a variable of type bit. It says it can't convert int to 
 bit. Do you mean cast(bit)2?


 
 Sorry, yes - that is what I meant. Thus, bit is not an integer type ?
 (which is easy to believe if you just hear the term "bit" being used)
 
 I still don't know what all the fuss about calling it "bit" is about.
 (why it wasn't named "bool" in the first place... probably the size ?)


Its a confusion between implementation and theory. 

bit is a number value. Semantically speaking, it makes sense to do
arithmetic on numbers, and it doesn't make sense to test the truth of a
number.

bool is a truth value. Semantically speaking, it doesn't make sense to do
arithmetic on truths, and does make sense to test the truth of a truth.

However, Walter has decided to *implement* bool as if it was the same as a
bit. Which allows coders to do stupid things like ...

<code>
import std.stdio;
void main()
{
  int a;

  a = 2*true + false;

  bool b;
  b = 1;
  b++;

  bool c;
  c = cast(bit)2;
  c = cast(bool)-2;
  writefln("%s %s %s %s", a, b, b+1, c);
}
</code>

One would have thought that a smart compiler could have just said - "Hey!
That doesn't make any sense. Do it properly."

The belief is that if bool is implmented as a bit, then the compiler can
create some optimised machine code. What isn't so strongly believed, is
that one can do that *in addition* to better compiler type checking.


 Oh well, that's been decided since long. Time to move on, for sure.
 I'll try not to mutter, when next newcomer to D wonders about this...


True, or should I say 1 ;-)

-- 
Derek
Melbourne, Australia
22/04/2005 9:31:51 AM
Apr 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Its a confusion between implementation and theory. 


This was *all* about the implementation, as in "right now in D"


 bit is a number value. Semantically speaking, it makes sense to do
 arithmetic on numbers, and it doesn't make sense to test the truth of a
 number.


No, that is not how it is implemented. "bit" is a boolean value,
it is not one of the integer types. (and as you know, D defines
the "truth" of both integers and pointers, so that's kinda moot)

[In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]


 bool is a truth value. Semantically speaking, it doesn't make sense to do
 arithmetic on truths, and does make sense to test the truth of a truth.


I prefer to use the term "boolean", when talking about the Real Thing.
(just as I use terms "integer" and "floating point", and even "strings")

[In theory, the regular boolean concept only has values true and false.]

"bool" is the right keyword, but it does suffer from the same problem as


Then again, "bool" is not a keyword in C and D but just a typedef/alias?


 However, Walter has decided to *implement* bool as if it was the same as a
 bit. Which allows coders to do stupid things like ...


That code worked similar in C99/C++ too:

#include <stdio.h>
#include <stdbool.h>

int main()
{
   int a;

   a = 2*true + false;

   bool b;
   b = 1;
   b++;

   bool c;
   c = (bool)2;
   c = (bool)-2;
   printf("%d %d %d %d\n", a, b, b+1, c);

   return 0;
}

So just *having* such a boolean type is not enough to "enforce" it ?
(for that purpose, D's bit type is "boolean enough" - just as _Bool)

Enforcing it means:

bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
bool.cs(8) error CS0019: Operator * cannot be applied to operands of 
type `int' and `bool'
bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'




 One would have thought that a smart compiler could have just said - "Hey!
 That doesn't make any sense. Do it properly."


I think Walter preferred that it worked the same way that it did in C.


Which means that we will continue to see arithmetic logic. And since
we will do, there is really not much point in separating bit and bool ?

But I still don't see much use for "bit", except for the venerable bit[]


 The belief is that if bool is implmented as a bit, then the compiler can
 create some optimised machine code. What isn't so strongly believed, is
 that one can do that *in addition* to better compiler type checking.


This is not true. "bit"/byte is just the smallest, not the fastest type.
If that was the reason for choosing bit, why does opEquals return "int"?

I thought it would be *easier* to optimize booleans that were not of a
fixed size, but of course that also means much trickier API definitions.
(at least "bit" has a fixed size of 1, when not being part of arrays -
unlike C++ where the size of a "bool" varies with the tide of the moon)

"bit" is just the default boolean type, like "char[]" is for strings ?
But in full reality, D has three boolean types and three string types:

See http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools
and http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs

At least you can do binary comparisons of booleans in D, which wasn't
possible in ancient C - unless comparing with false (which is always 0)
i.e. if you a have a "bool b;", you can say: "if (b == true) { ... }"
Since you now know that the only "true" value of a bit will be true (1).
But that's how it works in C99 / C++ too, so not much of an improvement.


Oh well, that's been decided since long. Time to move on, for sure.
I'll try not to mutter, when next newcomer to D wonders about this...


 
 True, or should I say 1 ;-)


"true" or "cast(bool) 1", you mean ;-) Otherwise you could get warnings
about "possible loss of data" when converting from int to bool, right ?

--anders
Apr 22 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 22 Apr 2005 10:53:43 +0200, Anders F Björklund wrote:


 Derek Parnell wrote:
 

 Its a confusion between implementation and theory. 


 
 This was *all* about the implementation, as in "right now in D"


Huh? What have you been smoking?


 bit is a number value. Semantically speaking, it makes sense to do
 arithmetic on numbers, and it doesn't make sense to test the truth of a
 number.


 
 No, that is not how it is implemented. "bit" is a boolean value,
 it is not one of the integer types. (and as you know, D defines
 the "truth" of both integers and pointers, so that's kinda moot)


Where did I say "bit is an integer"? I said "bit is a *number* value". In
other words, 'bit' is a numeric value. Just as integers and floating point
values are numeric values. And because they are numeric, it makes sense to
do numeric type operations, such as arithmetic with them.
 

 [In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]


Of course. A 'bit' is a numeric value that can have only two distinct
values - zero and one. You will note that "on" is a two-character string
and not a number ;-)


 bool is a truth value. Semantically speaking, it doesn't make sense to do
 arithmetic on truths, and does make sense to test the truth of a truth.


 
 I prefer to use the term "boolean", when talking about the Real Thing.
 (just as I use terms "integer" and "floating point", and even "strings")


That's nice, but so what???? 
 

 [In theory, the regular boolean concept only has values true and false.]
 
 "bool" is the right keyword, but it does suffer from the same problem as



Yes, that's what I just said.


 Then again, "bool" is not a keyword in C and D but just a typedef/alias?


So?
 

 However, Walter has decided to *implement* bool as if it was the same as a
 bit. Which allows coders to do stupid things like ...


 
 That code worked similar in C99/C++ too:


So? That just makes C99 and C++ just as stupid as D, in respect to the
concept of boolean values.

[snip]
 

 So just *having* such a boolean type is not enough to "enforce" it ?
 (for that purpose, D's bit type is "boolean enough" - just as _Bool)
 
 Enforcing it means:
 
 bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
 bool.cs(8) error CS0019: Operator * cannot be applied to operands of 
 type `int' and `bool'
 bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
 bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
 bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
 bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'
 



Yes, exactly what I was saying. In D the 'bool' does not implement the true
boolean concept. It is a hybrid that implements some boolean aspects but
not all.
 

 One would have thought that a smart compiler could have just said - "Hey!
 That doesn't make any sense. Do it properly."


 
 I think Walter preferred that it worked the same way that it did in C.



Yes, so what? Does that make DMD a smart compiler?


 Which means that we will continue to see arithmetic logic. And since
 we will do, there is really not much point in separating bit and bool ?


I agree that because Walter cannot see fit to implement a true boolean,
that it is no point in discussing it in order to influence Walter. It isn't
going to happen. However, there is no problem discussing it in terms of
programming concepts.


 But I still don't see much use for "bit", except for the venerable bit[]




 The belief is that if bool is implmented as a bit, then the compiler can
 create some optimised machine code. What isn't so strongly believed, is
 that one can do that *in addition* to better compiler type checking.


 
 This is not true. "bit"/byte is just the smallest, not the fastest type.
 If that was the reason for choosing bit, why does opEquals return "int"?


True. What I should have said was "... bool is implemented as a numeric
value ...".

-- 
Derek Parnell
Melbourne, Australia
23/04/2005 12:28:58 AM
Apr 22 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


This was *all* about the implementation, as in "right now in D"


 Huh? What have you been smoking?


Sorry, "in this thread" (there has been a few)


 Where did I say "bit is an integer"? I said "bit is a *number* value". In
 other words, 'bit' is a numeric value. Just as integers and floating point
 values are numeric values. And because they are numeric, it makes sense to
 do numeric type operations, such as arithmetic with them.


I know, I know... I meant the bit _type_ there.


 Of course. A 'bit' is a numeric value that can have only two distinct
 values - zero and one. You will note that "on" is a two-character string
 and not a number ;-)


It was a constant... But I wouldn't call them "true" and "false" as my
first choices, similar to as I wouldn't guess the type of them as "bool"


Then again, "bool" is not a keyword in C and D but just a typedef/alias?


 
 So?


An old pet peeve... D has keywords "true" and "false", but *not* "bool"?


 So? That just makes C99 and C++ just as stupid as D, in respect to the
 concept of boolean values.


It does... Or D "no smarter", depending on how you see it.


 Yes, exactly what I was saying. In D the 'bool' does not implement the true
 boolean concept. It is a hybrid that implements some boolean aspects but
 not all.


No argument there.


Which means that we will continue to see arithmetic logic. And since
we will do, there is really not much point in separating bit and bool ?


 
 I agree that because Walter cannot see fit to implement a true boolean,
 that it is no point in discussing it in order to influence Walter. It isn't
 going to happen. However, there is no problem discussing it in terms of
 programming concepts.


OK. I'll settle for using "bool" and "true" and "false", in D.

--anders
Apr 22 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Anders F Björklund wrote:


 Of course. A 'bit' is a numeric value that can have only two distinct
 values - zero and one. You will note that "on" is a two-character string
 and not a number ;-)


 
 It was a constant... But I wouldn't call them "true" and "false" as my
 first choices, similar to as I wouldn't guess the type of them as "bool"


"wouldn't guess the type of true and false as bit", it should have read

:-P

--anders
Apr 22 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Yes, exactly what I was saying. In D the 'bool' does not implement the true
 boolean concept. It is a hybrid that implements some boolean aspects but
 not all.


Sorry if I repeated some of your earlier stated opinions,
I was just trying to giving some more examples and details.


I think Walter preferred that it worked the same way that it did in C.



 
 Yes, so what? Does that make DMD a smart compiler?


Not in this aspect, no it doesn't. Then again, if the D compiler
had flagged it as illegal a lot of current D code wouldn't pass.

That was not a problem then, but it's getting to be one as more
and more D code is being developed. But it *could* be an optional
warning, just like the warnings about "might cause loss of data" ?
And use the "bool" alias and the "true/false" constants, and pretend.


 I agree that because Walter cannot see fit to implement a true boolean,
 that it is no point in discussing it in order to influence Walter. It isn't
 going to happen. However, there is no problem discussing it in terms of
 programming concepts.


One advantage is that code using bool-as-a-separate-type will
continue to compile, with the less restrictive DMD compiler.

So it would be possible to either add these as warnings, or if
that is not welcome one could add it to a separate "dlint" program.

And then you could run with warnings / preprocess, to make it
behave as if it wasn't allowed to compare "bool" with others...

I'm not sure how much work writing such a utility would be,
and it sure would be a lot easier if it was in DMD already.


Another minor problem is that some language constructs in D
are genuinely ugly without the implicit boolean contexts...

Such as "((key in hash) !== null)" and various assert forms.
"assert(false);" "assert(!(object is null));" and so on.

--anders
Apr 22 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Just a thought, since a signed bit numeric type would have the values "-1" and
"0" possible,
I can understand using a boolean representation instead of a signed bit...
However, an unsigned bit (ubit) would have 0 and 1 as values.

This should satisfy the desire to have an arithmetic bit type.

TZ

"Anders F Björklund" <afb algonet.se> wrote in message
news:d4ae2p$223g$1 digitaldaemon.com...

 Derek Parnell wrote:


 Its a confusion between implementation and theory.


 This was *all* about the implementation, as in "right now in D"


 bit is a number value. Semantically speaking, it makes sense to do
 arithmetic on numbers, and it doesn't make sense to test the truth of a
 number.


 No, that is not how it is implemented. "bit" is a boolean value,
 it is not one of the integer types. (and as you know, D defines
 the "truth" of both integers and pointers, so that's kinda moot)

 [In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]


 bool is a truth value. Semantically speaking, it doesn't make sense to do
 arithmetic on truths, and does make sense to test the truth of a truth.


 I prefer to use the term "boolean", when talking about the Real Thing.
 (just as I use terms "integer" and "floating point", and even "strings")

 [In theory, the regular boolean concept only has values true and false.]

 "bool" is the right keyword, but it does suffer from the same problem as


 Then again, "bool" is not a keyword in C and D but just a typedef/alias?


 However, Walter has decided to *implement* bool as if it was the same as a
 bit. Which allows coders to do stupid things like ...


 That code worked similar in C99/C++ too:

 #include <stdio.h>
 #include <stdbool.h>

 int main()
 {
    int a;

    a = 2*true + false;

    bool b;
    b = 1;
    b++;

    bool c;
    c = (bool)2;
    c = (bool)-2;
    printf("%d %d %d %d\n", a, b, b+1, c);

    return 0;
 }

 So just *having* such a boolean type is not enough to "enforce" it ?
 (for that purpose, D's bit type is "boolean enough" - just as _Bool)

 Enforcing it means:

 bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
 bool.cs(8) error CS0019: Operator * cannot be applied to operands of
 type `int' and `bool'
 bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
 bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
 bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
 bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'




 One would have thought that a smart compiler could have just said - "Hey!
 That doesn't make any sense. Do it properly."


 I think Walter preferred that it worked the same way that it did in C.


 Which means that we will continue to see arithmetic logic. And since
 we will do, there is really not much point in separating bit and bool ?

 But I still don't see much use for "bit", except for the venerable bit[]


 The belief is that if bool is implmented as a bit, then the compiler can
 create some optimised machine code. What isn't so strongly believed, is
 that one can do that *in addition* to better compiler type checking.


 This is not true. "bit"/byte is just the smallest, not the fastest type.
 If that was the reason for choosing bit, why does opEquals return "int"?

 I thought it would be *easier* to optimize booleans that were not of a
 fixed size, but of course that also means much trickier API definitions.
 (at least "bit" has a fixed size of 1, when not being part of arrays -
 unlike C++ where the size of a "bool" varies with the tide of the moon)

 "bit" is just the default boolean type, like "char[]" is for strings ?
 But in full reality, D has three boolean types and three string types:

 See http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools
 and http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs

 At least you can do binary comparisons of booleans in D, which wasn't
 possible in ancient C - unless comparing with false (which is always 0)
 i.e. if you a have a "bool b;", you can say: "if (b == true) { ... }"
 Since you now know that the only "true" value of a bit will be true (1).
 But that's how it works in C99 / C++ too, so not much of an improvement.


Oh well, that's been decided since long. Time to move on, for sure.
I'll try not to mutter, when next newcomer to D wonders about this...


 True, or should I say 1 ;-)


 "true" or "cast(bool) 1", you mean ;-) Otherwise you could get warnings
 about "possible loss of data" when converting from int to bool, right ?

 --anders
Apr 23 2005
prev sibling parent reply "Charlie" <charles jwavro.com> writes:
Bent Rasmussen, you still around ?

Charlie

"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:d44993$1uki$1 digitaldaemon.com...

 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
Apr 20 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Charlie" <charles jwavro.com> wrote in message 
news:d46ajl$15n0$1 digitaldaemon.com...

 Bent Rasmussen, you still around ?

 Charlie


slightly off-topic, this reminds me that for years when I was a kid my 
dentist would call me "Bent" and I never knew if she was joking or not and I 
was too intimidated to correct her.
Apr 20 2005
parent "Charlie" <charles jwavro.com> writes:
 slightly off-topic, this reminds me that for years when I was a kid my
 dentist would call me "Bent" and I never knew if she was joking or not and


I

 was too intimidated to correct her.



Want us to teach her a lesson ?

Regulators .... mount up.

:)

P.S., hey can you get me a discount on matlab :) ?  I never got to use it at
uni and now its really expensive :S.

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d46bq6$16qn$1 digitaldaemon.com...

 "Charlie" <charles jwavro.com> wrote in message
 news:d46ajl$15n0$1 digitaldaemon.com...

 Bent Rasmussen, you still around ?

 Charlie


 slightly off-topic, this reminds me that for years when I was a kid my
 dentist would call me "Bent" and I never knew if she was joking or not and


I

 was too intimidated to correct her.
Apr 20 2005