May 23, 2006
Walter Bright wrote:
> I'm not sure how useful this will be.
> 
> Here it is: http://www.digitalmars.com/d/htod.html

Cool!! Just the ticket.
Out of curiosity, how much new coding did this take?

feature request:
	print to stdout (would be handy for piping to sed or the like)
May 24, 2006
BCS wrote:
> Out of curiosity, how much new coding did this take?

Maybe 1500 lines.
May 24, 2006
Lionello Lunesu wrote:
>>>>> * signed char => sbyte
>>>> What's the issue?
>>> dmd claims (correctly) it doesn't know about sbyte:
>>> gl.d(42): identifier 'sbyte' is not defined
>> <slaps forehead> Arrgh!
> 
> Hey! Don't get me wrong! I've posted before that "byte" should be unsigned! So, create an sbyte for the signed byte and let's have a laugh about it.

The integer types are designed to be named consistently with each other.

byte, short, int and long are signed.
ubyte, ushort, uint and ulong are unsigned.

Stewart.
May 24, 2006
Stewart Gordon wrote:
> byte, short, int and long are signed.
> ubyte, ushort, uint and ulong are unsigned.
> 
> Stewart.

Yes, obviously. Interesting though that Walter himself wrote "sbyte" and didn't notice what was wrong with it :)

There's something to be said for intuitiveness, even when it's not consequent.

L.
May 24, 2006

Lionello Lunesu wrote:
> Stewart Gordon wrote:
>> byte, short, int and long are signed.
>> ubyte, ushort, uint and ulong are unsigned.
>>
>> Stewart.
> 
> Yes, obviously. Interesting though that Walter himself wrote "sbyte" and didn't notice what was wrong with it :)
> 
> There's something to be said for intuitiveness, even when it's not consequent.
> 
> L.

Funny, I always thought having 'char' in C being signed unlike every other integer type was hugely unintuitive.  Usually, the first thing I do with a C or C++ program is something like this:

#define byte signed char
#define ubyte unsigned char

Otherwise I end up getting confused...

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 24, 2006
Walter Bright wrote:
> I'm not sure how useful this will be.
> 
> Here it is: http://www.digitalmars.com/d/htod.html


One case that it doesn't handle but would seem to be simple is:

#define FOO "bar"
  |
  v
const char[] FOO = "bar\0"; //explicitly null terminate
May 24, 2006
BCS wrote:
> Walter Bright wrote:
>> I'm not sure how useful this will be.
>>
>> Here it is: http://www.digitalmars.com/d/htod.html
> 
> 
> One case that it doesn't handle but would seem to be simple is:
> 
> #define FOO "bar"
>   |
>   v
> const char[] FOO = "bar\0"; //explicitly null terminate

Why would you need it to be explicitly null terminated ? D string literals have a zero anyway just after their normal data (it's not reflected by the 'length' property, but it's there).


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
May 25, 2006
In article <e52ivj$3am$1@digitaldaemon.com>, Tom S says...
>
>BCS wrote:
>> Walter Bright wrote:
>>> I'm not sure how useful this will be.
>>>
>>> Here it is: http://www.digitalmars.com/d/htod.html
>> 
>> 
>> One case that it doesn't handle but would seem to be simple is:
>> 
>> #define FOO "bar"
>>   |
>>   v
>> const char[] FOO = "bar\0"; //explicitly null terminate
>
>Why would you need it to be explicitly null terminated ? D string literals have a zero anyway just after their normal data (it's not reflected by the 'length' property, but it's there).
>

#1 because that behavior it not in standard (AFAIK)

#2 copying

<code file=a.h>
#define FOO "start"
#define FOO "stop"
int func(char* string);
<\code>

<code file=b.d>
import a;
..
char[] command = FOO;
..
char[] use = command.dup;  // don't known why, but someone going to do it
..
func(use.prt);   // now what??
..
<\code>


May 25, 2006
BCS wrote:
> In article <e52ivj$3am$1@digitaldaemon.com>, Tom S says...
>> BCS wrote:
>>> Walter Bright wrote:
>>>> I'm not sure how useful this will be.
>>>>
>>>> Here it is: http://www.digitalmars.com/d/htod.html
>>>
>>> One case that it doesn't handle but would seem to be simple is:
>>>
>>> #define FOO "bar"
>>>   |
>>>   v
>>> const char[] FOO = "bar\0"; //explicitly null terminate
>> Why would you need it to be explicitly null terminated ? D string literals have a zero anyway just after their normal data (it's not reflected by the 'length' property, but it's there).
>>
> 
> #1 because that behavior it not in standard (AFAIK)
> 
> #2 copying
> 
> <code file=a.h>
> #define FOO "start"
> #define FOO "stop"
> int func(char* string);
> <\code>
> 
> <code file=b.d>
> import a;
> ..
> char[] command = FOO;
> ..
> char[] use = command.dup;  // don't known why, but someone going to do it
> ..
> func(use.prt);   // now what??
> ..
> <\code>

But that's simply a bug in the code, not in the "header".
What if "use" included the zero terminator, what would "use ~= "t";" result it? A "t" after the zero terminator? So, either the append code would have to strip zero terminators before appending (sure hope it won't), or the length property should not include the zero, which is exactly what's being done now.

L.
May 25, 2006
On Wed, 24 May 2006 14:15:43 -0700, BCS wrote:

> Walter Bright wrote:
>> I'm not sure how useful this will be.
>> 
>> Here it is: http://www.digitalmars.com/d/htod.html
> 
> One case that it doesn't handle but would seem to be simple is:
> 
> #define FOO "bar"
>    |
>    v
> const char[] FOO = "bar\0"; //explicitly null terminate

But if that happened, things lke concatenation would cause problems.

#define FOO "foo"
#define BAR "bar"
   |
   |
   V
const char[] FOO = "foo\0"; //explicitly null terminate
const char[] BAR = "bar\0"; //explicitly null terminate

. . .

  char[] x = FOO ~ BAR; // Now it has an embedded \0 !

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
25/05/2006 5:03:13 PM