On Monday, 1 May 2023 at 16:57:39 UTC, Dadoum wrote:
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
But how is this possible in a cross-compiling context. I am
not sure if I can do that with the D language either as pure D
or better C. DMD does not seem to offer cross compiling.
Any D function marked as extern(C) can be called from C. As
long as you have a C header file defining the functions and the
appropriate C declarations any custom types you have, the C
code will have no idea it's calling into a D library.
Thanks for the example. It clarify things up. The
On 5/1/23 03:23, Mike Parker wrote:
> If you're referring to `rt_init` and `rt_term` are the `extern(C)`
> functions in `core.runtime`. It's not necessary to call those from C. A
> D library with a C interface can provide an `extern(C)` initialization
> function that internally calls
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
But how is this possible in a cross-compiling context. I am not
sure if I can do that with the D language either as pure D or
better C. DMD does not seem to offer cross compiling. GDC can
compile better C, but not sure mingw can
On Monday, 1 May 2023 at 09:17:14 UTC, Eric P626 wrote:
This is a false dilemma: D has full C compatibility.
From what I understand, D can use C, but C cannot use D? It's
like C++: C++ can call C but C cannot call C++.
50% or more of my code will be put in re-usabled libraries. If
I want
On Monday, 1 May 2023 at 09:35:59 UTC, Dukc wrote:
hard. Seems the C-linked functions in
[core.runtime](https://dlang.org/phobos/core_runtime.html#.Runtime.initialize) ought to do the trick.
If you're referring to `rt_init` and `rt_term` are the
`extern(C)` functions in `core.runtime`. It's
On Monday, 1 May 2023 at 09:17:14 UTC, Eric P626 wrote:
This is a false dilemma: D has full C compatibility.
From what I understand, D can use C, but C cannot use D? It's
like C++: C++ can call C but C cannot call C++.
50% or more of my code will be put in re-usabled libraries. If
I want
As others have said, you have no reason to restrict yourself to
BetterC. If you dislike objects and/or other high-level features,
you can simply use D in a low-level way like you'd use C. That
works just as well from normal D as from BetterC. Both the C
standard library and third-party C
This is a false dilemma: D has full C compatibility.
From what I understand, D can use C, but C cannot use D? It's
like C++: C++ can call C but C cannot call C++.
50% or more of my code will be put in re-usabled libraries. If I
want people to use those libs, I would need to compile them in
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
# Language
I am currently using plain C and I love it. I am allergic to
C++ and object oriented programming.
..
So... what can you do in C that you cannot do in C++ ??
C++ is essentially C .. plus.. you get 'selective' access
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
The title of this thread might be weird, but I am currently
reconsidering the language and tools I am using before
returning to production again.
# Objective and projects
Make simple turn based (no animation) video games using
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
So what language do you recommend:
* Keep everything in plain C
* Use C patched with macros to gain some language features like
Foreach
* Use BetterC for everything
* Use D for the games, and better C or C for the libraries(To
keep
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:
* Use D for everything, no C compatibility.
This is a false dilemma: D has full C compatibility.
The title of this thread might be weird, but I am currently
reconsidering the language and tools I am using before returning
to production again.
# Objective and projects
Make simple turn based (no animation) video games using Allegro
4, maybe 5, and eventually SDL on multiple platforms:
14 matches
Mail list logo
