On Thursday, 16 December 2021 at 18:38:10 UTC, Elronnd wrote:
> On Thursday, 16 December 2021 at 14:26:42 UTC, bachmeier wrote:
>> https://github.com/ibuclaw/importC/blob/main/src/keywords.c.in
>
>> #define __builtin_bswap16(x) ((u_int16_t) ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8)))
>
> Oh, my, that's bad.  GCC __builtins don't generally evaluate more than once.  And this could just be an inline function anyway.

This is why most of us should stay away from C. I honestly don't know what that incantation is doing, even though I've written a fair amount of C over the years.

On Thursday, 16 December 2021 at 19:04:21 UTC, bachmeier wrote:
> On Thursday, 16 December 2021 at 18:38:10 UTC, Elronnd wrote:
>> On Thursday, 16 December 2021 at 14:26:42 UTC, bachmeier wrote:
>>> https://github.com/ibuclaw/importC/blob/main/src/keywords.c.in
>>
>>> #define __builtin_bswap16(x) ((u_int16_t) ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8)))
>>
>> Oh, my, that's bad.  GCC __builtins don't generally evaluate more than once.  And this could just be an inline function anyway.
>
> This is why most of us should stay away from C. I honestly don't know what that incantation is doing, even though I've written a fair amount of C over the years.

:-) it rotates the MSB right 8 places into the LSB, rotates the LSB left 8 places, and ORs/overlays them both together, to effectively swap the MSB and LSB bytes

On Thursday, 16 December 2021 at 19:04:21 UTC, bachmeier wrote:
> On Thursday, 16 December 2021 at 18:38:10 UTC, Elronnd wrote:
>> On Thursday, 16 December 2021 at 14:26:42 UTC, bachmeier wrote:
>>> https://github.com/ibuclaw/importC/blob/main/src/keywords.c.in
>>
>>> #define __builtin_bswap16(x) ((u_int16_t) ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8)))
>>
>> Oh, my, that's bad.  GCC __builtins don't generally evaluate more than once.  And this could just be an inline function anyway.
>
> This is why most of us should stay away from C. I honestly don't know what that incantation is doing, even though I've written a fair amount of C over the years.

You're not serious, aren't you? Except for the typecast syntax the expression is also valid D.

There is https://github.com/Temtaime/stb also
Outdated a little and missing some define macros, but i'll update it if someone needs it

On 12/16/2021 2:38 AM, stb wrote:
> are we going to be able use https://github.com/nothings/stb with importc?
> these are header only libraries and i use stb (and similar libraries) all the time.
> there is no reason for me to use c/c++ for tools if importc can pull this off.

That is indeed the point of ImportC.

On 12/16/2021 2:44 AM, rikki cattermole wrote:
> In theory.
> 
> Recently Iain let me know that zlib's test suite is now passing with ImportC.
> 
> So the things that are missing are the macro preprocessor and whatever extensions those files use. Once they have been sorted out (the macro preprocessor is the big one of the two), then sure, they should work, if not either it isn't C or its a bug.

We are having a problem with what to do with all the C extensions the system .h files rely on.

On 12/16/2021 5:38 AM, Adam D Ruppe wrote:
> note that some of these have already been ported to D like
> https://github.com/adamdruppe/arsd/blob/master/ttf.d
> 
> though i haven't updated it back from upstream for a while.

The updating problem is one of the major motivations for ImportC.

On Saturday, 18 December 2021 at 21:49:31 UTC, Walter Bright wrote:
> On 12/16/2021 2:38 AM, stb wrote:
>> are we going to be able use https://github.com/nothings/stb with importc?
>> these are header only libraries and i use stb (and similar libraries) all the time.
>> there is no reason for me to use c/c++ for tools if importc can pull this off.
>
> That is indeed the point of ImportC.

i was waiting for this for about 10 years, better late than never. some still won't understand how huge this feature is, talking about complexity added to the language. compared to its benefits the complexity (which could probably be deferred to llvm etc..) added is nothing. when matured, wrappers/wrapper-versions will be obsolete for 100% of the battle tested libraries, and going to reduce the work needed for the obscure/extension-heavy libraries.

one of the bigger if not the biggest starting point of c++ was its c backwards compatibility. with importc you have best of both worlds. you have backwards/foreign compatibility with c libraries and since this is just an `include "path-to-c"` you do not contaminate d with c syntax.

thank you walter!