May 22, 2006
//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
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
"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
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
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
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
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
"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
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
>>>> * 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.