View mode: basic / threaded / horizontal-split · Log in · Help
May 23, 2006
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
BCS wrote:
> Out of curiosity, how much new coding did this take?

Maybe 1500 lines.
May 24, 2006
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
Re: htod - convert C .h files to D import files
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
1 2 3 4
Top | Discussion index | About this forum | D home