May 12
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
May 12
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!
May 12
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)
May 12
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.
May 12
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.
May 13

On Thursday, 12 May 2022 at 21:36:40 UTC, Walter Bright wrote:

>

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.

It should be possible most of the time, as macros in most cases expands to counterparts in the C grammar. You also have to support _Generic. It is by and large a matter of aligning D semantics with C, and that is not a far fetched goal.

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).

May 13
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.


May 13
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.
May 13

On Friday, 13 May 2022 at 10:37:08 UTC, IGotD- wrote:

>

we are several months into import C.

It's impossible to eat all cake at one go.
It's even worse to give up halfway.
We can only support importc.
Besides, it's not that bad.

May 13

On Friday, 13 May 2022 at 11:21:18 UTC, zjh wrote:

>

On Friday, 13 May 2022 at 10:37:08 UTC, IGotD- wrote:

>

we are several months into import C.

It's impossible to eat all cake at one go.
It's even worse to give up halfway.
We can only support importc.
Besides, it's not that bad.

Import C is obsoloete before it is ready (wich it will never be). The limitations of import C will force people to conversion tools and/or manual conversion. C .h files are in general full of "clever" preprocessor tricks that never will be supported by import C.

import C feels like one of those corporate blunders where the management throws in resources into something that will hardly sell while it was obvious from the very beginning it was a bad idea.

45 46 47 48 49 50 51 52 53 54 55 56 57