On Thu, May 12, 2022 at 10:43:56AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/12/2022 10:25 AM, max haughton wrote:
> > Preprocessor support takes more than just preprocessing the C source.
> 
> I know.
> 
> > You need to be able to use the macros or it's useless. That's the main thing dstep is able to do.
> 
> I understand that access to the manifest constant #define's is important.  But it's not useless to not have them. We're making progress on it.

It's not just manifest constants. There's also macro functions that sometimes crop up in complex C headers. Those are hard to automatically translate; some cases may need inline functions, some involve token-pasting and may not be translatable without human intervention.


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin

On 5/11/2022 8:48 PM, Walter Bright wrote:
> I agree. Now, if only someone would approve 14090, we'd be good to go!

And, it's pulled now!

On Thursday, 12 May 2022 at 18:10:20 UTC, H. S. Teoh wrote:
> It's not just manifest constants. There's also macro functions that sometimes crop up in complex C headers. Those are hard to automatically translate; some cases may need inline functions, some involve token-pasting and may not be translatable without human intervention.

importC's advantage is that they don't have to be translated. If you can mixin some C code, you can do the macro expansion there and then merge the ASTs, without losing the hygeine of the D code.

If this gets implemented - and Max took a few steps toward it recently - we might actually exceed dstep in some cases. (You'd still have to express it in the right way but still)

On 5/12/2022 6:34 AM, Adam D Ruppe wrote:
> C bitfields are useless even in C for hardware work, unless you lock into proprietary compiler, since the layout is undefined.

It's not undefined, it's implementation defined.

Also, the layout of ordinary fields is also implementation defined. C has a lot of surprising unportable features.

And if you're interfacing to specific hardware, portability to some other platform likely isn't in the cards anyway.

If you use bitfields for, say, reducing the memory consumption of the program, it is irrelevant if a different compiler users a different layout. It would only be an issue if the bit fields were written to a file, which is not that common.

On 5/12/2022 11:10 AM, H. S. Teoh wrote:
> There's also macro functions that
> sometimes crop up in complex C headers. Those are hard to automatically
> translate; some cases may need inline functions, some involve
> token-pasting and may not be translatable without human intervention.

All true. If a .h file uses preprocessor for metaprogramming, there's no way to make that work in D.

On Friday, 13 May 2022 at 09:58:17 UTC, Ola Fosheim Grøstad wrote:
> ..
> ...
> If such things are not supported then the utility is so limited that it might be better to drop import-C. People generally dont want to deal with 90% solutions (only the most hardcore users want that).


Personally, I'm being turned off from using D, because of importC.

And to 'try' to keep this thread back on topic, it's why D is becoming 'unpopular' with me.

Please drop import-C.

A C hack in D is pointless.

Walter, please go and create C->M (C with Modules) instead.

Then make it an international standard.

Then I will give serious consideration to it.

On Friday, 13 May 2022 at 10:15:37 UTC, forkit wrote:
>
> Personally, I'm being turned off from using D, because of importC.
>
> And to 'try' to keep this thread back on topic, it's why D is becoming 'unpopular' with me.
>
> Please drop import-C.
>
> A C hack in D is pointless.
>
> Walter, please go and create C->M (C with Modules) instead.
>
> Then make it an international standard.
>
> Then I will give serious consideration to it.

Thank you and you are saying what I thought from the beginning when I read about import C. Import C is an answer to a question we never asked. Since we don't have a preprocessor and if it ever will exist it will be crippled and unusable. Basically we have to run a .h file through GCC/Clang in order to run the preprocessor, then what is the point of import C if we have to use an external tool to begin with. Then we can just use a stand alone tool to convert C .h files to D which is likely to work much better as well. Also external tools also opens up the possibility for C++ and other languages translation as well, something that will never happen with import C.

Now we are several months into import C and Walther claimed it was easy to implement from the beginning which is obviously not true at all. If you look at the bug list, it is just riddled with import C bugs and will be.

Just remove import C, it is pointless and rely on external translation tools instead.