View mode: basic / threaded / horizontal-split · Log in · Help
May 22, 2006
Re: htod - convert C .h files to D import files
//C typedef signed char GLbyte;
alias sbyte GLbyte;

>dmd gl.d
gl.d(42): identifier 'sbyte' is not defined

?? something new or something old?

L.
May 22, 2006
Re: htod - convert C .h files to D import files
Anders F Björklund wrote:
> Walter Bright wrote:
> 
>>> Q: Will there be source code later, for porting to GDC ?
>>
>> Sorry, but it's totally based on the C compiler. But that also means 
>> it could be done to gcc.
> 
> It doesn't have to be complete... As long as it's something like
> "insert C/C++ front end here", it could then be adapted to GCC ?
> 
> Anyway, we can probably do a re-implementation from the documentation
> but the more info you are able to provide the more similar they'll get.
> 
> If we can do a larger implementation test, like Dstress for the 
> compiler, then we can run that on the two "htod" to compare them...
> 
> Will do a spike / hack in a scripting language. "ghtod", I suppose. ?
> Time will tell if that'll do, or if we need a "real" C or D program.
> 
> --anders

There really isn't much to it, it just walks the symbol table of the C 
compiler.
May 23, 2006
Re: htod - convert C .h files to D import files
"I'm not sure how useful this will be."

That's such a typical Walter quote <g>. About as useful as a Ferrari 
that only works on roads, I reckon. Time to throw away my regexp billy-cart.

A perfect H to D converter is probably impossible, because #defines are 
so ambiguous. It takes a human who knows how the header file is intended 
to be used. However, it ought to be possible to construct patch files to 
apply to C headers prior to running them into htod. It also seems 
feasible in the long term to persuade some open-source projects to make 
their headers D-friendly.

I'm left wondering what this means for the Windows API project. I 
certainly would have done things differently, if I'd known this was 
coming. Where to now?
May 23, 2006
Re: htod - convert C .h files to D import files
I have found some other issues with htod, but am reluctant to post them. 
 Don't want Walter's focus to shift to other tools. (Who am I to worry 
about Walter's focus? :S)

Anyway, here are some things to keep in mind when using htod:

* signed char => sbyte
* wchar_t not known (it's built-in in vc?)
* void func( void (*callback)(void) ) => void func( void 
function(...)callback );
* comments are 1 line off

L.
May 23, 2006
Re: htod - convert C .h files to D import files
Lionello Lunesu wrote:
> I have found some other issues with htod, but am reluctant to post them. 
>  Don't want Walter's focus to shift to other tools. (Who am I to worry 
> about Walter's focus? :S)
> 
> Anyway, here are some things to keep in mind when using htod:
> 
> * signed char => sbyte

What's the issue?

> * wchar_t not known (it's built-in in vc?)

Hmm. Example?

> * void func( void (*callback)(void) ) => void func( void 
> function(...)callback );

That's correct.

> * comments are 1 line off

This can happen with macros, but it shouldn't happen with declarations.
May 23, 2006
Re: htod - convert C .h files to D import files
Don Clugston wrote:
> A perfect H to D converter is probably impossible, because #defines are 
> so ambiguous.

Not just that, there are things like using "char" as "byte" in C code. 
There's no way to reliably distinguish the usages.

> It takes a human who knows how the header file is intended 
> to be used.

That's right. That's why the original declarations are included as 
comments to make it easy to go through the results line by line and 
check them.

> However, it ought to be possible to construct patch files to 
> apply to C headers prior to running them into htod. It also seems 
> feasible in the long term to persuade some open-source projects to make 
> their headers D-friendly.

That's why the __HTOD__ macro is predefined when running htod.

> I'm left wondering what this means for the Windows API project. I 
> certainly would have done things differently, if I'd known this was 
> coming. Where to now?

Windows would still need a lot of hand work because of its heavy 
dependence on the preprocessor. There are still nearly 100,000 lines of 
code to check.

What I hope is that the D outputting version of SWIG will no longer be 
necessary, that one can just run the C output of SWIG through htod. That 
way we can easily leverage all the work put into SWIG by others.
May 23, 2006
Re: htod - convert C .h files to D import files
Lionello Lunesu wrote:
>
> * wchar_t not known (it's built-in in vc?)

vc actually offers an option of whether to define wchar_t as a separate 
type or merely to make it a typedef of unsigned short.  I prefer the 
former option, but it doesn't work with all third-party code.


Sean
May 23, 2006
Re: htod - convert C .h files to D import files
"Walter Bright" <newshound@digitalmars.com> wrote in message 
news:e4vhd6$25ti$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>> I have found some other issues with htod, but am reluctant to post them. 
>> Don't want Walter's focus to shift to other tools. (Who am I to worry 
>> about Walter's focus? :S)
>>
>> Anyway, here are some things to keep in mind when using htod:
>>
>> * signed char => sbyte
> What's the issue?

dmd claims (correctly) it doesn't know about sbyte:
gl.d(42): identifier 'sbyte' is not defined

>> * wchar_t not known (it's built-in in vc?)
> Hmm. Example?

const wchar_t* APIENTRY gluErrorUnicodeStringEXT (
   GLenum   errCode);

wchar_t wasn't defined anywhere (although I can find it in the headers, but 
it must have been ifdef'ed or something). And I think it's indeed handled as 
a built-in type by VC, which might be the reason why it's not typedef'en 
explicitely. This header is from the PlatformSDK, by the way, so I was 
expecting some ms-only stuff.

>> * void func( void (*callback)(void) ) => void func( void 
>> function(...)callback );
> That's correct.

Thought so. Still, useful info for a knowledge base : )

>> * comments are 1 line off
> This can happen with macros, but it shouldn't happen with declarations.

I'll have to check the exact occurence at the office tomorrow, but it 
happened during the conversion of gl.h (as did the others):

#define SOME_CONSTANT 123   /* multi-line
                     comment */
=>
/* multi-line
const SOME_CONSTANT = 123;
                     comment */
The code ended up being commented and I had to shift it up (or down; don't 
recall).

Just another thing to be noted, that's all.

All-in-all, it still saved me a lot of time!

L.
May 23, 2006
Re: htod - convert C .h files to D import files
Lionello Lunesu wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message 
> news:e4vhd6$25ti$1@digitaldaemon.com...
>> Lionello Lunesu wrote:
>>> I have found some other issues with htod, but am reluctant to post them. 
>>> Don't want Walter's focus to shift to other tools. (Who am I to worry 
>>> about Walter's focus? :S)
>>>
>>> Anyway, here are some things to keep in mind when using htod:
>>>
>>> * 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!
May 23, 2006
Re: htod - convert C .h files to D import files
>>>> * 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.

L.
1 2 3 4
Top | Discussion index | About this forum | D home