www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to convert C to D using compiler?

reply ManKey <mensikovk817 gmail.com> writes:
I tried this
```
ldc2 test.i -mixin="test.d"
```
but the test.d file is empty :(
Dec 07 2021
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


https://dlang.org/spec/importc.html
Dec 07 2021
parent reply ManKey <mensikovk817 gmail.com> writes:
On Tuesday, 7 December 2021 at 16:49:58 UTC, 12345swordy wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 https://dlang.org/spec/importc.html


I just want to convert from C file to D file, don't import it
Dec 07 2021
parent reply bachmeier <no spam.net> writes:
On Tuesday, 7 December 2021 at 16:52:47 UTC, ManKey wrote:

 On Tuesday, 7 December 2021 at 16:49:58 UTC, 12345swordy wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 https://dlang.org/spec/importc.html


 I just want to convert from C file to D file, don't import it


There's no way to convert arbitrary C files to D, but:

- You can compile C files directly if they are C11-compatible. 
You include them on the command line like .d files and import 
them the same as D modules. You have to run the C files through 
the preprocessor manually. There's not much support for GCC 
extensions.
- You can convert header files using 
[dstep](https://github.com/jacob-carlborg/dstep).
- You can include C header files directly in D modules using 
[dpp](https://github.com/atilaneves/dpp).
Dec 07 2021
parent max haughton <maxhaton gmail.com> writes:
On Tuesday, 7 December 2021 at 20:37:12 UTC, bachmeier wrote:

 On Tuesday, 7 December 2021 at 16:52:47 UTC, ManKey wrote:

 On Tuesday, 7 December 2021 at 16:49:58 UTC, 12345swordy wrote:

 [...]


 I just want to convert from C file to D file, don't import it


 There's no way to convert arbitrary C files to D, but:

 - You can compile C files directly if they are C11-compatible. 
 You include them on the command line like .d files and import 
 them the same as D modules. You have to run the C files through 
 the preprocessor manually. There's not much support for GCC 
 extensions.
 - You can convert header files using 
 [dstep](https://github.com/jacob-carlborg/dstep).
 - You can include C header files directly in D modules using 
 [dpp](https://github.com/atilaneves/dpp).


No way yet, expect a forum post / PR soon
Dec 07 2021
prev sibling next sibling parent ManKey <mensikovk817 gmail.com> writes:
On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


I write small script for this

```d

import std;

string replaceExt(string path, string from, string to){
	return path.dirName ~ "/" ~ path.baseName(from) ~ to;
}

int main(string[] args){
	assert(args.length == 2);

	string src_path = args[1];
	string srci_path = src_path.replaceExt(".c", ".i");
	string renamed_path = src_path.replaceExt(".c", ".d");

	void preprocess(string orig, string ifile){
		auto result = execute(["clang", "-E", orig]);
		assert(result.status == 0, result.output);
		std.file.write(ifile, result.output);
	}

	void convert(string src, string outf){
		auto result = execute(["ldc2", src, "-vcg-ast", "-o-"]);
		assert(result.status == 0, result.output);
		rename(src ~ ".cg", outf);
	}


	preprocess(src_path, srci_path);
	convert(srci_path, renamed_path);
	std.file.remove(srci_path);

	return 0;
}
```
Dec 07 2021
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


- you can do it by hand
- or instead you can wait a few years that ImportC becomes 
workable :)
Dec 08 2021
parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 8 December 2021 at 09:23:41 UTC, Guillaume Piolat 
wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 - you can do it by hand
 - or instead you can wait a few years that ImportC becomes 
 workable :)


It'll probably be dropped for the next big feature before being 
finished, just like everything else in D. Nothing is ever 
completed or workable. Only ever a subset works.

Not to be pessimistic but there's literally no ground-breaking 
feature in D that has been finished yet.

Everything is only finished half-way through and doesn't work 
properly - referring to nogc, safe, shared, betterC, the many 
phobos modules under experimental.

D has this mentality that it's better to start something new and 
exciting, than fixing up/finishing what we have.

So yeah, never wait for something to be completed in D, always 
expect what you have now is what you have in a couple of years, 
except for that you can be guaranteed a tons of new half-finished 
features will be added along with a handful of new attributes 
that nobody really understands.
Dec 08 2021
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 8 December 2021 at 12:05:16 UTC, bauss wrote:

 On Wednesday, 8 December 2021 at 09:23:41 UTC, Guillaume Piolat 
 wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 - you can do it by hand
 - or instead you can wait a few years that ImportC becomes 
 workable :)


 It'll probably be dropped for the next big feature before being 
 finished, just like everything else in D. Nothing is ever 
 completed or workable. Only ever a subset works.


Disagree.
For example SIMD, array ops, DUB improved and transitionned from 
unusable to workhorse.
Stuff that no one cares about, on the other hand, gets in the 
limbo zone much longer.
Dec 08 2021
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 8 December 2021 at 12:05:16 UTC, bauss wrote:

 On Wednesday, 8 December 2021 at 09:23:41 UTC, Guillaume 
 Piolat wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 - you can do it by hand
 - or instead you can wait a few years that ImportC becomes 
 workable :)


 It'll probably be dropped for the next big feature before 
 being finished, just like everything else in D. Nothing is 
 ever completed or workable. Only ever a subset works.


 Disagree.
 For example SIMD, array ops, DUB improved and transitionned 
 from unusable to workhorse.
 Stuff that no one cares about, on the other hand, gets in the 
 limbo zone much longer.


I listed things that has been unfinished for like a decade, how 
can you disagree by just stating a couple of examples that has 
been done?

I never said everything doesn't get finished. I said that 
ground-breaking features never gets finished, things that 
actually matters, like shared is still broken, nogc is still too 
limited, allocators don't work properly and have been in 
experimental for years, std.json has never been replaced, same 
with std.sockets etc. betterC is still somewhat limited, scope 
has so many bugs/edge cases that hasn't been solved, making it 
unusable in general. I could list probably a thousand other 
things where D has neglected existing features for new features.
Dec 08 2021
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:


 I could list probably a thousand other things where D has 
 neglected existing features for new features.


Thousands, plural :) 3076 open reports for dmd alone at this 
time, if I'm reading bugzilla correctly.
Dec 08 2021
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:

 I never said everything doesn't get finished.


It's easy to get that impression when you wrote:


 Nothing is ever completed or workable.


And only specified afterwards that it's limited to 
"ground-breaking features", which is a pretty big caveat by the 
way. If I say "static/dynamic arrays, `scope(exit)` and `foreach` 
work pretty good", then you could just reply "well, those are not 
ground-breaking".


 nogc is still too limited


Do you have a bugzilla issue, or are you referring to liberal use 
of GC allocations in druntime/Phobos?


 betterC is still somewhat limited


It works well when translating C code to D, which was its 
intended use case. It's when you start writing new -betterC code 
with D features that you get cryptic/unnecessary TypeInfo errors, 
which makes this an interesting case: it shows how things can be 
unfinished not because the implementation doesn't match the 
requirements, but because the requirements update, as people 
started using it for e.g. WebAssembly / embedded purposes.


 scope  has so many bugs/edge cases that hasn't been solved, 
 making it unusable in general.


This year there actually has been lots of progress in eliminating 
those bugs, e.g.:
[Fix issue 17977 - destructor allows escaping reference to a 
temporary struct 
instance](https://github.com/dlang/dmd/pull/13349)
[Fix Issue 22366 - [dip1000] scope variable can be assigned to 
associative array](https://github.com/dlang/dmd/pull/13156)
[Fix issue 20245 - address of ref should be scope 
](https://github.com/dlang/dmd/pull/12812)
[Fix issue 21912 - delegate assigned to return scope variable 
needs closure](https://github.com/dlang/dmd/pull/12880)
[Fix Issue 20150 - -dip1000 defeated by 
pure](https://github.com/dlang/dmd/pull/12010)

I aggregated the remaining ones here: 
https://github.com/orgs/dlang/projects/4/
Dec 08 2021
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 8 December 2021 at 14:20:44 UTC, Dennis wrote:

 On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:

 I never said everything doesn't get finished.


 It's easy to get that impression when you wrote:


 Nothing is ever completed or workable.


 And only specified afterwards that it's limited to 
 "ground-breaking features", which is a pretty big caveat by the 
 way. If I say "static/dynamic arrays, `scope(exit)` and 
 `foreach` work pretty good", then you could just reply "well, 
 those are not ground-breaking".


Come on, since when does a hyperbole require qualification? :) 
Surely he didn't mean literally "nothing".

Although, on the point of qualification, "work pretty good" is a 
far cry from "work, period". Static/dynamic arrays don't "work, 
period" as soon as copy constructors get involved. Which is a 
new-ish feature, by D standards. One that is recommended to 
switch to by the documentation, while the language and its 
runtime aren't actually able to support such transition. Which 
emphasizes bauss' point.
Yes, this is reported on bugzilla and is being slowly worked on. 
But that means one has to know the current caveats and work 
around them.


 nogc is still too limited


 Do you have a bugzilla issue, or are you referring to liberal 
 use of GC allocations in druntime/Phobos?


212 open issues on bugzilla with search for 'nogc'. Cursory look 
shows some of 'em might have gotten fixed along the way though. I 
guess I've just volunteered myself to vet them.


 betterC is still somewhat limited


 It works well when translating C code to D, which was its 
 intended use case.


Was it? Its documentation suggests that its intended use case is 
to integrate D code into existing code bases.


 It's when you start writing new -betterC code with D features 
 that you get cryptic/unnecessary TypeInfo errors, which makes 
 this an interesting case: it shows how things can be unfinished 
 not because the implementation doesn't match the requirements, 
 but because the requirements update, as people started using it 
 for e.g. WebAssembly / embedded purposes.


That doesn't alleviate the frustration one gets when faced with 
that particular error message :) I mean, for real, just adding an 
-inline flag might break a build, with not even a hint as to why. 
Bonus points for being able to reduce the issue for a bug report!


 scope  has so many bugs/edge cases that hasn't been solved, 
 making it unusable in general.


 This year there actually has been lots of progress in 
 eliminating those bugs, e.g.:


I've noticed you've been cracking hard on DIP1000, and the 
progress is great to see. I don't think anyone here wants to 
belittle the actual sleeves up work that is being done. But the 
general frustration is also pretty understandable. For example, 
one of the issues you've cited was 4 years old. And there are 
many, many more (not necessarily DIP1000-related) that date back 
more than a decade.
Dec 08 2021
parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 8 December 2021 at 15:42:05 UTC, Stanislav Blinov 
wrote:

 Come on, since when does a hyperbole require qualification? :) 
 Surely he didn't mean literally "nothing".


True, but it's best to avoid exaggeration if you don't want to be 
misunderstood.


 But the general frustration is also pretty understandable.


Also true, I just think that being hyperbolically negative and 
blaming the attitude of D's contributors is unfair. There's 
plenty of people fixing bugs in existing features (just look at 
the changelog of new releases), but sometimes it's hard to keep 
up, and other times it's impossible to 'finish' things. CTFE 
started as a simple extension to constant folding, but nowadays 
some D programs do very complex things with it, hitting 
limitations and getting compile-time performance problems. That's 
not because the implementation of CTFE was abandoned 80% through 
in favor of a new shiny feature, it's because there was never a 
clear 100% to begin with, it's ever evolving.
Dec 08 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 8 December 2021 at 21:04:36 UTC, Dennis wrote:

 Also true, I just think that being hyperbolically negative and 
 blaming the attitude of D's contributors is unfair.


I don't think anyone in particular is being blamed, but there is 
a mismatch between the chosen compiler architecture and an 
evolutionary development model. Evolution demands a more modular 
approach, and frankly, a constant reevaluation of the 
architecture with planned refactoring.


 That's not because the implementation of CTFE was abandoned 80% 
 through in favor of a new shiny feature, it's because there was 
 never a clear 100% to begin with, it's ever evolving.


That's probably true for a lot of things, also things like 
[inconsistencies and limitations of 
alias](https://forum.dlang.org/post/augmegssadjgrzvfhofk forum.dlang.org)
probably started as a quick add-on, but there is a limit to how far you can go
with just evolution. If one keeps on evolving without redesigning then one ends
up painting oneself into a corner where completion becomes an intractable
proposition.

The most sensible thing then is to start remodelling into layers 
where you have a chance. The obvious starting point is to put a 
layer between frontend and backend. But then you have to make it 
a priority. Projects like ``` live``` and ```importC``` are 
rather ambitious. For importC you basically need to do like clang 
and implement [the commonly used gcc 
extensions](https://clang.llvm.org/docs/LanguageExtensions.html). 
Doing all of that at the same time pushes the finish-line far 
into the horizon. And then it is of limited use, even though a 
well developed ``` live``` analysis stage might be useful for 
analysing C-code and could possibly make some C-code accessible 
as ``` safe```.

Maybe D should do like C++ compilers and set up page with 
hatch-marks for feature completion. I don't start using next 
generation C++ or JavaScript without checking those feature 
tables for 100% completion.

For many contexts of serious software development having a 
half-baked feature is almost the same as not having it at all.
Dec 08 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 December 2021 at 00:19:19 UTC, Ola Fosheim Grøstad 
wrote:


May be you need a reconstruction DIP.
Dec 08 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 December 2021 at 02:20:09 UTC, zjh wrote:

 May be you need a reconstruction DIP.


DIPs are only for language specifcation changes.
Dec 09 2021
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume Piolat 
wrote:


 Disagree.
 For example SIMD, array ops, DUB improved and transitionned 
 from unusable to workhorse.
 Stuff that no one cares about, on the other hand, gets in the 
 limbo zone much longer.


I disagree in my turn. There is a clear pattern: a new cool 
feature is introduced; people try to use it but give up because 
the feature is half-implemented/buggy; then, a few years later, 
the feature gets deprecated because "nobody used it".
Dec 08 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 8 December 2021 at 14:30:46 UTC, Max Samukha wrote:

 On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume Piolat 
 wrote:


 Disagree.
 For example SIMD, array ops, DUB improved and transitionned 
 from unusable to workhorse.
 Stuff that no one cares about, on the other hand, gets in the 
 limbo zone much longer.


 I disagree in my turn. There is a clear pattern: a new cool 
 feature is introduced; people try to use it but give up because 
 the feature is half-implemented/buggy; then, a few years later, 
 the feature gets deprecated because "nobody used it".


I struggle to find an example honestly?

There used to be such early bumps with UDAs or nothrow, or ranges.
For a decade or so, arrays ops simply crashed DMD with 
optimizations on. Now they work. Brings value for the daily D 
programmer actually.

Again I was a big user of builtin complexes, and loudly 
compagined against their removal.
When removal day came, it was very little work and worked without 
penalty or adverse effect.
So in the end the D core team was right not to listen to me... 
and now it is argued on the D forums that complex numbers were 
removed as if it was a bad thing and people were impacted. Well, 
no, was a good change.
Dec 08 2021
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 8 December 2021 at 14:41:39 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 8 December 2021 at 14:30:46 UTC, Max Samukha 
 wrote:

 On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume 
 Piolat wrote:


 Disagree.
 For example SIMD, array ops, DUB improved and transitionned 
 from unusable to workhorse.
 Stuff that no one cares about, on the other hand, gets in the 
 limbo zone much longer.


 I disagree in my turn. There is a clear pattern: a new cool 
 feature is introduced; people try to use it but give up 
 because the feature is half-implemented/buggy; then, a few 
 years later, the feature gets deprecated because "nobody used 
 it".


 I struggle to find an example honestly?

 There used to be such early bumps with UDAs or nothrow, or 
 ranges.
 For a decade or so, arrays ops simply crashed DMD with 
 optimizations on. Now they work. Brings value for the daily D 
 programmer actually.

 Again I was a big user of builtin complexes, and loudly 
 compagined against their removal.
 When removal day came, it was very little work and worked 
 without penalty or adverse effect.
 So in the end the D core team was right not to listen to me... 
 and now it is argued on the D forums that complex numbers were 
 removed as if it was a bad thing and people were impacted. 
 Well, no, was a good change.


Are you sure it's not a form of Stockholm syndrome? Why is the 
change good?
Dec 09 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 10 December 2021 at 02:51:11 UTC, Max Samukha wrote:

 Are you sure it's not a form of Stockholm syndrome? Why is the 
 change good?


For sure there is some high degree of Stockholm, with something 
as addictive as D. :)

But in this case:

- makes the language and implementation a tiny easier. If it 
makes compiler engineers happy then it's a positive (afaik some 
wanted to kill builtin complex with fire).

- as a heavy complex number users: you don't really write _that_ 
much literals often at all. 80% of these complex literals are 
zero and one (for which aliases would be maybe nice in 
std.complex btw)

- Complex literals always seemed a little un-D to me:
       Complex!double(-2.1039 , 2.6575)
   yields less questions about operator priority than:
       -2.1039 + 2.6575i
   We have to remember cfloat/cdouble/creal also introduced the 
ifloat/idouble/ireal types.

   Also the i is easily misread in 2.6575i, so there there was 
less fanfare about using complex numbers. It falls under "short 
syntax for rarely used thing" trap to me.

- a lot of the code using complex numbers separates imaginary and 
real values in separate arrays. That, or SIMD code, erase the 
type anyway.
Dec 10 2021
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Dec 10, 2021 at 05:49:44PM +0000, Guillaume Piolat via Digitalmars-d
wrote:
[...]

 - as a heavy complex number users: you don't really write _that_ much
 literals often at all. 80% of these complex literals are zero and one (for
 which aliases would be maybe nice in std.complex btw)
 
 - Complex literals always seemed a little un-D to me:
       Complex!double(-2.1039 , 2.6575)


Hmm, technically you *could* do something like:

	enum i = Complex!double(0.0, 1.0);

which then lets you write:

	-2.1039 + 2.2.6575*i

of course, this then depends on the optimizer to optimize away the
redundant operation. But it would be more-or-less almost as readable as
built-in complex literals.


T

-- 
Жил-был король когда-то, при нём блоха жила.
Dec 10 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 8 December 2021 at 12:05:16 UTC, bauss wrote:

 It'll probably be dropped for the next big feature before being 
 finished, just like everything else in D. Nothing is ever 
 completed or workable. Only ever a subset works.

 Not to be pessimistic but there's literally no ground-breaking 
 feature in D that has been finished yet.


It would be nice if at least there was a plan to implement basic 
things like type unification. (binding parametric names)
Dec 08 2021
prev sibling parent reply Hasan Kashi <hnk1440 gmail.com> writes:
On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


Write your transpiler!
Dec 08 2021
parent ManKey <mensikovk817 gmail.com> writes:
On Thursday, 9 December 2021 at 07:12:59 UTC, Hasan Kashi wrote:

 On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

 I tried this
 ```
 ldc2 test.i -mixin="test.d"
 ```
 but the test.d file is empty :(


 Write your transpiler!


I have already written a small script in D.
Dec 09 2021