Thread overview
Why do we have Dmain?
Oct 22, 2021
Kirill
Oct 22, 2021
Mike Parker
Oct 22, 2021
Kirill
Oct 22, 2021
Dukc
Oct 22, 2021
Kagamin
Oct 23, 2021
Elronnd
Oct 25, 2021
user1234
Oct 25, 2021
bauss
Oct 25, 2021
SealabJaster
October 22, 2021

I am not a compiler expert, but I genuinely would like to know why we have Dmain.

I've been looking at the generated assembly code recently and noticed the _Dmain function. I didn't notice it before. Then there is main, where Dmain is called.

Why is that?

October 22, 2021

On Friday, 22 October 2021 at 05:54:21 UTC, Kirill wrote:

>

I am not a compiler expert, but I genuinely would like to know why we have Dmain.

I've been looking at the generated assembly code recently and noticed the _Dmain function. I didn't notice it before. Then there is main, where Dmain is called.

Why is that?

The entry point for your program is a function _start. That's implemented in the C runtime, which all D programs depend on. It in turn calls main, as it does for C and C++ programs.

The D compiler generates an extern(C) main function that hands control off to DRuntime for initialization, then in turn calling your application main (a.k.a. _DMain).

See:
https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L245

If you declare your main function as extern(C), then the compiler does not generate one and you get handed control from the C runtime. Which in turn means you have to handle initialization of the D runtime yourself.

October 22, 2021

On Friday, 22 October 2021 at 07:00:25 UTC, Mike Parker wrote:

>

[...]

Thank you for such a clear explanation Mike and for a quick reply!

October 22, 2021

On Friday, 22 October 2021 at 07:00:25 UTC, Mike Parker wrote:

>

The entry point for your program is a function _start. That's implemented in the C runtime, which all D programs depend on. It in turn calls main, as it does for C and C++ programs.

It is possible, in both C and D, to write your own _start and not depend on the C runtime.

This is something you want to do only if necessary though - C runtime is so small that you don't want to drop it for any realistic desktop or even a smartphone program. The usual reason to do this is if there is no C runtime easily available - meaning mainly embedded targets.

October 22, 2021

Actually C runtime is many megabytes in size.

October 23, 2021
On Friday, 22 October 2021 at 09:01:53 UTC, Kagamin wrote:
> Actually C runtime is many megabytes in size.

A couple of samples:

$ wc -c /usr/lib/libc-2.33.so
2150424 /usr/lib/libc-2.33.so

% wc -c /lib/libc.so.7
 1981952 /lib/libc.so.7

I would hardly call two megabytes 'many'.
October 25, 2021

On Friday, 22 October 2021 at 05:54:21 UTC, Kirill wrote:

>

I am not a compiler expert, but I genuinely would like to know why we have Dmain.

I've been looking at the generated assembly code recently and noticed the _Dmain function. I didn't notice it before. Then there is main, where Dmain is called.

Why is that?

in addition to the other answers, there's also the parameters of main:

int argc, char** argv

becomes

string[]

so with the D main you're directly in the the D "domain". In theory from that point, you don't need to ever use strlen for example.

October 25, 2021

On Monday, 25 October 2021 at 07:49:44 UTC, user1234 wrote:

>

so with the D main you're directly in the the D "domain". In theory from that point, you don't need to ever use strlen for example.

Not just that, but you shouldn't use it at all, rather you can't use it!

You might be able to call it, but it won't work as expected because strings are not zero-terminated in D, unless the string is a literal.

strlen looks for \0, so using it for a string that isn't zero-terminated is asking for trouble.

October 25, 2021

On Monday, 25 October 2021 at 07:49:44 UTC, user1234 wrote:

>

in addition to the other answers, there's also the parameters of main:

Also, all programs running under the D runtime have special command line arguments(--DRT arguments). The Runtime needs to be able to parse those arguments at some point (among other initilisation), hence why the runtime handles the "true" main for us.