www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D as a Better C

reply Mike Parker <aldacron gmail.com> writes:
To coincide with the improvements to -betterC in the upcoming DMD 
2.076, Walter has published a new article on the D blog about 
what it is and why to use it. A fun read. And I'm personally 
happy to see the love this feature is getting. I have a project 
I'd like to use it with if I can ever make the time for it!

The blog:

https://dlang.org/blog/2017/08/23/d-as-a-better-c/

Reddit:
https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/
Aug 23 2017
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


Interesting article, though one thing that I'm confused by is


 Hence D libraries remain inaccessible to C programs, and 
 chimera programs (a mix of C and D) are not practical. One 
 cannot pragmatically “try out” D by add D modules to an 
 existing C program.




I've been mixing C and full D for a while now (on Linux) by 
either having the main C program call rt_init/rt_term directly 
(if druntime is linked in when building a mixed C/D application), 
or have Runtime.initialize/Runtime.terminate be called from D via 
some plugin_load/plugin_unload functionality when using D shared 
libraries.
Why is this not considered practical?
Aug 23 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:

 Interesting article, though one thing that I'm confused by is
 

 Hence D libraries remain inaccessible to C programs, and chimera programs (a 
 mix of C and D) are not practical. One cannot pragmatically “try out” D by 
 add D modules to an existing C program.




 
 I've been mixing C and full D for a while now (on Linux) by either having the 
 main C program call rt_init/rt_term directly (if druntime is linked in when 
 building a mixed C/D application), or have
Runtime.initialize/Runtime.terminate 
 be called from D via some plugin_load/plugin_unload functionality when using D 
 shared libraries.
 Why is this not considered practical?


Because in order to add a D function as trivial as:

    int foo() { return 3; }

to a C program, now the C program has to link to druntime, and the program no 
longer has a small footprint. One of the reasons people use C is to get that 
small footprint. This has been a large barrier to C programs making use of D.
Aug 23 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 10:00 AM, Walter Bright wrote:

 On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:

 Interesting article, though one thing that I'm confused by is


 Hence D libraries remain inaccessible to C programs, and chimera 
 programs (a mix of C and D) are not practical. One cannot 
 pragmatically “try out” D by add D modules to an existing C program.




 I've been mixing C and full D for a while now (on Linux) by either 
 having the main C program call rt_init/rt_term directly (if druntime 
 is linked in when building a mixed C/D application), or have 
 Runtime.initialize/Runtime.terminate be called from D via some 
 plugin_load/plugin_unload functionality when using D shared libraries.
 Why is this not considered practical?


 
 Because in order to add a D function as trivial as:
 
     int foo() { return 3; }
 
 to a C program, now the C program has to link to druntime, and the 
 program no longer has a small footprint. One of the reasons people use C 
 is to get that small footprint. This has been a large barrier to C 
 programs making use of D.
 


Nope.

Stevens-MacBook-Pro:testd steves$ cat testdfunc.d
extern(C) int foo() { return 3; }
Stevens-MacBook-Pro:testd steves$ cat testdfunc_c.c
#include <stdio.h>
extern int foo();

int main()
{
     printf("%d\n", foo());
}
Stevens-MacBook-Pro:testd steves$ dmd -c testdfunc.d
Stevens-MacBook-Pro:testd steves$ gcc -o testdfunc testdfunc_c.c testdfunc.o
Stevens-MacBook-Pro:testd steves$ ./testdfunc
3


It's only if you do something that needs the runtime, such as static 
ctors, or use the GC.

-Steve
Aug 23 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

 It's only if you do something that needs the runtime, such as static ctors, or 
 use the GC.


Or use asserts, or even declare a struct.
Aug 23 2017
parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Wednesday, 23 August 2017 at 15:53:11 UTC, Walter Bright wrote:

 On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

 It's only if you do something that needs the runtime, such as 
 static ctors, or use the GC.


 Or use asserts, or even declare a struct.


No structs in -betterC ???
Aug 23 2017
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote:

 On Wednesday, 23 August 2017 at 15:53:11 UTC, Walter Bright 
 wrote:

 On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

 It's only if you do something that needs the runtime, such as 
 static ctors, or use the GC.


 Or use asserts, or even declare a struct.


 No structs in -betterC ???


IIUC, Steven's question was about the need for the `-betterC` 
switch - in his small example there was no need for it. Walter 
pointed out that without -betterC using structs cause link-time 
references to druntime, which are avoided by the use of the 
`-betterC` switch.
Though, one particular thing that doesn't work in `-betterC` 
w.r.t. structs is RAII. You can still call manually the 
destructor, but that's a crude hack. Work on RAII for `-betterC` 
is work in progress.
Aug 23 2017
prev sibling parent reply sarn <sarn theartofmachinery.com> writes:
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote:

 No structs in -betterC ???


I haven't tried the latest iteration of betterC yet, but the 
longstanding problem is that the compiler generates TypeInfo 
instances for structs, and TypeInfos are classes, which inherit 
from Object, which are implemented in the D runtime.  If you're 
using the current release of D, the workarounds are to include an 
implementation of Object so that classes work, or hack out the 
TypeInfo at link time.
Aug 23 2017
parent Kagamin <spam here.lot> writes:
On Wednesday, 23 August 2017 at 22:45:27 UTC, sarn wrote:

 I haven't tried the latest iteration of betterC yet, but the 
 longstanding problem is that the compiler generates TypeInfo 
 instances for structs


LDC doesn't generate TypeInfo for structs until it's required for 
some features like array comparison.
Aug 24 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

 Nope.


A ModuleInfo is generated, as well as FMB/FM/FME sections. Those sections may 
not work with the C runtime.
Aug 23 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 11:56 AM, Walter Bright wrote:

 On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

 Nope.


 
 A ModuleInfo is generated, as well as FMB/FM/FME sections. Those 
 sections may not work with the C runtime.


My point was simply that your small example doesn't cause any runtime or 
link time errors. You need something more complicated to require betterC.

Not sure if ModuleInfo is generated. IIRC, Martin made it so it's not if 
no usage of the ModuleInfo is apparent.

Yes, adding a struct causes link errors, but not because of ModuleInfo, 
it's because of the expected TypeInfo.

-Steve
Aug 23 2017
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote:

 On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:

 
 I've been mixing C and full D for a while now (on Linux) by 
 either having the main C program call rt_init/rt_term directly 
 (if druntime is linked in when building a mixed C/D 
 application), or have Runtime.initialize/Runtime.terminate be 
 called from D via some plugin_load/plugin_unload functionality 
 when using D shared libraries.
 Why is this not considered practical?


 Because in order to add a D function as trivial as:

    int foo() { return 3; }

 to a C program, now the C program has to link to druntime, and 
 the program no longer has a small footprint. One of the reasons 
 people use C is to get that small footprint. This has been a 
 large barrier to C programs making use of D.


Thank you, are there other factors involved, or is it only 
impractical for people who require minimal application size / 
memory footprint, then?
Aug 23 2017
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote:

 One of the reasons people use C is to get that small footprint. 
 This has been a large barrier to C programs making use of D.


Not a better C, but intermediate D has small footprint for me too.
7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - 
wrote it to put images in xml for opensearch descriptions.
12.5kb retab.exe (retabifies source code with various features)
5.5kb keepower.exe (manages screen saver and power settings 
because of obnoxious domain policy)
14.5kb fsum.exe (computes various hash sums of a file)

Additional features: string switch, array cast. Also how assert 
failure works in C? Mine shows a nice formatted message.
Aug 23 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 10:17 AM, Kagamin wrote:

 Also how assert failure works in C?


It calls the C assert failure function.
Aug 23 2017
prev sibling parent reply Parke via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, Aug 23, 2017 at 10:17 AM, Kagamin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Not a better C, but intermediate D has small footprint for me too.


What is "intermediate D"?

-Parke


 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it
 to put images in xml for opensearch descriptions.
 12.5kb retab.exe (retabifies source code with various features)
 5.5kb keepower.exe (manages screen saver and power settings because of
 obnoxious domain policy)
 14.5kb fsum.exe (computes various hash sums of a file)

 Additional features: string switch, array cast. Also how assert failure
 works in C? Mine shows a nice formatted message.
Aug 24 2017
parent reply Kagamin <spam here.lot> writes:
On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


D with minimal runtime.
Aug 25 2017
next sibling parent reply Suliman <evermind live.ru> writes:
On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:

 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


 D with minimal runtime.


How to pass to dub -betterC flag?
Aug 25 2017
parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 25 August 2017 at 09:50:39 UTC, Suliman wrote:

 On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:

 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


 D with minimal runtime.


 How to pass to dub -betterC flag?


{
     ...
     "dflags" : ["betterC"],
     ...
}
Aug 25 2017
parent Basile B. <b2.temp gmx.com> writes:
On Friday, 25 August 2017 at 10:01:25 UTC, Basile B. wrote:

 On Friday, 25 August 2017 at 09:50:39 UTC, Suliman wrote:

 On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:

 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


 D with minimal runtime.


 How to pass to dub -betterC flag?


 {
     ...
     "dflags" : ["betterC"],
     ...
 }


oooooooooooooops, add the hyphen before, so

{
     ...
     "dflags" : ["-betterC"],
     ...
}
Aug 25 2017
prev sibling next sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:

 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


 D with minimal runtime.


5 years later...

D - BetterC++ (no gc)
D - BetterJava (full on gc + other goodie tissue)
D - BetterRust (full interoperability with rust)

Forgive my cynicism
Aug 25 2017
parent Jolly James <j.j jmail.com> writes:
On Friday, 25 August 2017 at 15:29:54 UTC, Swoorup Joshi wrote:

 On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:

 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?


 D with minimal runtime.


 5 years later...

 D - BetterC++ (no gc)
 D - BetterJava (full on gc + other goodie tissue)
 D - BetterRust (full interoperability with rust)

 Forgive my cynicism



templates instead)
Phobos - Better.NET (pointless names, weird structure, outdated 
stuff)
DCD - BetterIntelliSense (tends to always not find about ~10 of 
all real possibilities, is rather "patched into" IDEs/editors 
than integrated)
Aug 25 2017
prev sibling parent reply Parke via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
 On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:

 What is "intermediate D"?




On Fri, Aug 25, 2017 at 1:54 AM, Kagamin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 D with minimal runtime.


Is there any documentation on how to access and use the minimal runtime?

-Parke
Aug 25 2017
parent reply Kagamin <spam here.lot> writes:
On Friday, 25 August 2017 at 18:08:06 UTC, Parke wrote:

 Is there any documentation on how to access and use the minimal 
 runtime?


Runtime implements language features like boundschecking, it's 
not used explicitly in the code.
Aug 28 2017
parent reply Parke via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
 On Friday, 25 August 2017 at 18:08:06 UTC, Parke wrote:

 Is there any documentation on how to access and use the minimal runtime?




On Mon, Aug 28, 2017 at 5:22 AM, Kagamin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Runtime implements language features like boundschecking, it's not used
 explicitly in the code.


I understand that.

On Wed, Aug 23, 2017 at 10:17 AM, Kagamin via Digitalmars-d-announce

 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it
 to put images in xml for opensearch descriptions.
 12.5kb retab.exe (retabifies source code with various features)
 5.5kb keepower.exe (manages screen saver and power settings because of
 obnoxious domain policy)
 14.5kb fsum.exe (computes various hash sums of a file)


Is the source code available for totext.exe, retab.exe keepower.exe,
and fsum.exe?

If the source code were available, I could try compiling them and see
if I could reproduce the nice, small executable sizes you list above.

When I write "hello world" in C, the executable is 8,519 bytes.  When
I write "hello world" in D, the executable is 100 times larger:
865,179 bytes.

Interestingly, "hello world" in C, compiled statically, yields 908,608
bytes.  And "hello world" in assembly yields 368 bytes.

Thanks,

Parke
Aug 28 2017
next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:

 When I write "hello world" in C, the executable is 8,519 bytes.
  When I write "hello world" in D, the executable is 100 times 
 larger: 865,179 bytes.


You mean the examples from the blog post 
https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb 
executables?
Aug 29 2017
parent reply Parke via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
 On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:

 When I write "hello world" in C, the executable is 8,519 bytes.
  When I write "hello world" in D, the executable is 100 times larger:
 865,179 bytes.





On Tue, Aug 29, 2017 at 8:26 AM, Kagamin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 You mean the examples from the blog post
 https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb
 executables?



No, I was talking about the below version of "hello world" that I
compiled several weeks prior to reading the blog post.

import std.stdio;
void main() { writeln("Hello, world!"); }

The above D code yields 865,179 bytes.


Below is the version from the blog post:

import core.stdc.stdio;
extern (C) int main( int argc, char** argv ) {
    printf ( "hello world\n" );
    return 0;
}

The above D code yields 445,244 bytes when compiled with -release.
The above D code yields 445,187 bytes when compiled with -release -betterC.
DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.

Still 50 times larger than C.  Perhaps it would be smaller with a
newer version of DMD.

But my original question was about what you (Kagamin) called
"intermediate D".  I was trying to understand what "intermediate D"
is, and whether or not I could use "intermediate D" (whatever it is)
to produce small(er) executables.

-Parke
Aug 29 2017
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:

 The above D code yields 445,187 bytes when compiled with 
 -release -betterC.
 DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.


-betterC does virtually nothing on that version of dmd...


 But my original question was about what you (Kagamin) called
 "intermediate D".  I was trying to understand what 
 "intermediate D"
 is, and whether or not I could use "intermediate D" (whatever 
 it is)
 to produce small(er) executables.


Regular D with a custom runtime library. You can get as small as 
3 KB on Linux (though that is a super bare bones hello world).

But note that if you are distributing several executables you 
might also just use the shared phobos lib too with 
-defaultlib=libphobos2.so on Linux.
Aug 29 2017
prev sibling next sibling parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:


 But my original question was about what you (Kagamin) called
 "intermediate D".  I was trying to understand what 
 "intermediate D"
 is, and whether or not I could use "intermediate D" (whatever 
 it is)
 to produce small(er) executables.


"Intermediate D" probably refers to not use the -betterC switch, 
not linking in the official druntime, and instead implementing 
the features of D required by your program yourself.

For example, the following is the most minimal "Hello World" I 
can make with D that does not require the -betterC switch, and 
does not use the official D runtime.  Instead the runtime 
features required by this program are implemented in object.d.

object.d
--------
module object;

alias immutable(char)[] string;

struct ModuleInfo { }

class Object { }

class TypeInfo
{
     bool equals(in void* p1, in void* p2) const
     {
         return p1 == p2;
     }

     int compare(in void* p1, in void* p2) const
     {
         return _xopCmp(p1, p2);
     }
}

class TypeInfo_Class : TypeInfo
{
     ubyte[136] ignore;
}

alias TypeInfo_Class ClassInfo;

class TypeInfo_Struct : TypeInfo
{
     ubyte[120] ignore;
}

extern (C) Object _d_newclass(const ClassInfo ci)
{
     return null;
}

extern(C) void _d_throwc(Object h) { }

class Throwable { }

class Error : Throwable
{
     this(string x)
     { }
}

extern(C) void _d_throwdwarf(Throwable o) { }

extern(C) void _d_dso_registry(void* data) { }


// The following code basically replaces the C runtime
//----------------------------------------------------
extern extern(C) int main(int argc, char** argv);

extern(C) void sys_exit(long arg1)
{
     asm
     {
         mov RAX, 60;
         mov RDI, arg1;
         syscall;
     }
}

extern(C) void _start()
{
     auto ret = main(0, null);
     sys_exit(ret);
}

private alias extern(C) int function(char[][] args) MainFunc;

extern (C) int _d_run_main(int argc, char **argv, MainFunc 
mainFunc)
{
     // ignore args for now
     return mainFunc(null);
}

main.d
------
module main;

long sys_write(long arg1, in void* arg2, long arg3)
{
     long result;

     asm
     {
         mov RAX, 1;
         mov RDI, arg1;
         mov RSI, arg2;
         mov RDX, arg3;
         syscall;
     }

     return result;
}

void write(in string text)
{
     sys_write(2, text.ptr, text.length);
}

void main()
{
     write("Hello\n");
}

Building and executing
----------------------
On Linux 64-bit compile with:
$ dmd -c -fPIC -release object.d main.d -of=main.o

Link with:
$ ld main.o -o main

Report size:
$ size main
    text    data     bss     dec     hex filename
    1070    1872       8    2950     b86 main

Text execution:
$ ./main
Hello

If you link with:
$ ld main.o -o main --gc-sections

You end up with:
$ size main
    text    data     bss     dec     hex filename
     950    1688       0    2638     a4e main


This illustration does not require -betterC, but instead requires 
you to implement a "minimal D runtime" specific to your program, 
and the features of D that it employs.  In this illustration that 
"minimal D runtime" is object.d.

As you can see it is not a polished experience and gets much 
worse when you start employing more features of D.  This could be 
improved, and in fact, with GDC you need even less useless 
boilerplate in object.d and may end up with an even smaller 
executable. (Maybe I'll follow up later with GDC illustration.  
Right now I don't have a computer with the latest GDC installed). 
  If you try this experiment with LDC, you may end up with a 
multi-gigabyte file and crash your PC due to 
https://github.com/ldc-developers/ldc/issues/781

Hopefully we can improve the compiler/runtime implementation so 
doing this kind of programming won't require so many useless 
stubs, and users can implement just the features of D that they 
need for their program without having to rely on the on the blunt 
and heavy hand of -betterC.

Mike
Aug 29 2017
next sibling parent Parke via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Tue, Aug 29, 2017 at 7:19 PM, Michael V. Franklin via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 For example, the following is the most minimal "Hello World" I can make with
 D that does not require the -betterC switch, and does not use the official D
 runtime.  Instead the runtime features required by this program are
 implemented in object.d.


Thank you for the very helpful example and explanation.

-Parke
Aug 29 2017
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 30 August 2017 at 02:19:21 UTC, Michael V. Franklin 
wrote:

 As you can see it is not a polished experience and gets much 
 worse when you start employing more features of D.  This could 
 be improved, and in fact, with GDC you need even less useless 
 boilerplate in object.d and may end up with an even smaller 
 executable. (Maybe I'll follow up later with GDC illustration.  
 Right now I don't have a computer with the latest GDC 
 installed).
  If you try this experiment with LDC, you may end up with a 
 multi-gigabyte file and crash your PC due to 
 https://github.com/ldc-developers/ldc/issues/781


I use stock object.d, just don't link it.
Aug 30 2017
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:

 But my original question was about what you (Kagamin) called
 "intermediate D".  I was trying to understand what 
 "intermediate D"
 is, and whether or not I could use "intermediate D" (whatever 
 it is)
 to produce small(er) executables.


I rely on llvm tooling to remove unused stuff, build process is a 
bit lengthy, I didn't write a step by step guide for it. Also 
linux might need different approach depending what code compiler 
generates.
Aug 30 2017
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:

 When I write "hello world" in C, the executable is 8,519 bytes.
  When I write "hello world" in D, the executable is 100 times 
 larger: 865,179 bytes.

 Interestingly, "hello world" in C, compiled statically, yields 
 908,608 bytes.  And "hello world" in assembly yields 368 bytes.


https://forum.dlang.org/post/tmofjecvnqdthvetezfp forum.dlang.org 
- an example for elf target.
Sep 07 2017
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


Great piece.

It might be useful to beef up the documentation on some of the 
things that betterC changes. For instance, here
http://dlang.org/dmd-windows.html#switch-betterC
links to TypeInfo, which has like one line of explanation of what 
it's for, and ModuleInfo isn't linked to at all (and I'm still a 
little unclear on what that does).
Aug 23 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 7:01 AM, jmh530 wrote:

 ModuleInfo isn't linked to at all (and I'm still a little unclear on what that 
 does).


That's because ModuleInfo doesn't appear in the online documentation due to 
having a malformed Ddoc comment. I fixed it here:

   https://github.com/dlang/druntime/pull/1906

but nobody has pulled it.
Aug 23 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 10:11 AM, Walter Bright wrote:

 On 8/23/2017 7:01 AM, jmh530 wrote:

 ModuleInfo isn't linked to at all (and I'm still a little unclear on 
 what that does).


 
 That's because ModuleInfo doesn't appear in the online documentation due 
 to having a malformed Ddoc comment. I fixed it here:
 
    https://github.com/dlang/druntime/pull/1906
 
 but nobody has pulled it.


Looks like there are some outstanding requests to be fulfilled before 
it's pulled.

-Steve
Aug 23 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 7:24 AM, Steven Schveighoffer wrote:

 Looks like there are some outstanding requests to be fulfilled before it's
pulled.


I don't agree that the requests improve matters.
Aug 23 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 11:52 AM, Walter Bright wrote:

 On 8/23/2017 7:24 AM, Steven Schveighoffer wrote:

 Looks like there are some outstanding requests to be fulfilled before 
 it's pulled.


 
 I don't agree that the requests improve matters.


You may want to mention that in the PR. Right now it just looks like you 
haven't seen or responded to the requests.

-Steve
Aug 23 2017
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 23 August 2017 at 14:01:30 UTC, jmh530 wrote:

 On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


 Great piece.

 It might be useful to beef up the documentation on some of the 
 things that betterC changes. For instance, here
 http://dlang.org/dmd-windows.html#switch-betterC
 links to TypeInfo, which has like one line of explanation of 
 what it's for, and ModuleInfo isn't linked to at all (and I'm 
 still a little unclear on what that does).


Walter has made a PR to improve the ModuleInfo documentation: 
https://github.com/dlang/druntime/pull/1906
Aug 23 2017
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 23 August 2017 at 14:01:30 UTC, jmh530 wrote:

 Great piece.

 It might be useful to beef up the documentation on some of the 
 things that betterC changes. For instance, here
 http://dlang.org/dmd-windows.html#switch-betterC
 links to TypeInfo, which has like one line of explanation of 
 what it's for, and ModuleInfo isn't linked to at all (and I'm 
 still a little unclear on what that does).



Am I correct that betterC requires main to be extern(C) and must 
act like a C main (i.e. no void return)?

Is that something that can be changed in the future? For 
instance, the simplest change would be if the compiler knows that 
its betterC, then it can insert extern(C) to main. A second 
adjustment could potentially to re-write D's void main's to int 
and add in a return. The first seems like a good idea 
superficially, but I'm not 100% on the second.
Aug 23 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 10:26 AM, jmh530 wrote:

 Am I correct that betterC requires main to be extern(C) and must act like a C 
 main (i.e. no void return)?


Yes.


 Is that something that can be changed in the future?


Yes, but I don't see a need for it.
Aug 23 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 23 August 2017 at 17:39:00 UTC, Walter Bright wrote:

 On 8/23/2017 10:26 AM, jmh530 wrote:

 Am I correct that betterC requires main to be extern(C) and 
 must act like a C main (i.e. no void return)?


 Yes.


This might be added to
http://dlang.org/dmd-windows.html#switch-betterC
or
http://dlang.org/spec/betterc.html


 Is that something that can be changed in the future?


 Yes, but I don't see a need for it.


Fair enough. A version statement could handle it

version(BetterC)
{
     extern(C) int main()
     {
         callRealMain();
     }
}
else
{
     void main()
     {
         callRealMain();
     }
}
Aug 23 2017
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 9:12 AM, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming DMD 2.076, 
 Walter has published a new article on the D blog about what it is and 
 why to use it. A fun read. And I'm personally happy to see the love this 
 feature is getting. I have a project I'd like to use it with if I can 
 ever make the time for it!
 
 The blog:
 
 https://dlang.org/blog/2017/08/23/d-as-a-better-c/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


How do dynamic closures work without the GC?

Nice article, BTW.

-Steve
Aug 23 2017
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven 
Schveighoffer wrote:

 On 8/23/17 9:12 AM, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!
 
 The blog:
 
 https://dlang.org/blog/2017/08/23/d-as-a-better-c/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


 How do dynamic closures work without the GC?

 Nice article, BTW.

 -Steve


They don't (right now, using dmd ~master), because they depend on 
druntime:

--- a.c ---
#include <stdio.h>
#include <stdint.h>

uint32_t foo();

int main(int argc, char** argv)
{
     uint32_t x = foo();
     printf("%d\n", x);
}
-----------

--- b.d ---
auto test()
{
     uint i = 42;
     return () {
         return i;
     };
}

oo()
{
     auto x = test();
     return x();
}
-----------

$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
   "__d_allocmemory", referenced from:
       _D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
ld: symbol(s) not found for architecture x86_64extern(C) uint 
foo()
{
     auto x = test();
     return x();
}
-----------

$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
   "__d_allocmemory", referenced from:
       _D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
Aug 23 2017
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 23 August 2017 at 15:17:31 UTC, Moritz Maxeiner 
wrote:

 On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven 
 Schveighoffer wrote:

 On 8/23/17 9:12 AM, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!
 
 The blog:
 
 https://dlang.org/blog/2017/08/23/d-as-a-better-c/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


 How do dynamic closures work without the GC?

 Nice article, BTW.

 -Steve


 They don't (right now, using dmd ~master), because they depend 
 on druntime:

 [...]


Sorry, I screwed up when pasting. Here's what I meant to post:


--- a.c ---
#include <stdio.h>
#include <stdint.h>

uint32_t foo();

int main(int argc, char** argv)
{
     uint32_t x = foo();
     printf("%d\n", x);
     return 0;
}
-----------

--- b.d ---
auto test()
{
     uint i = 42;
     return () {
         return i;
     };
}

$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
   "__d_allocmemory", referenced from:
       _D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
Aug 23 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 7:37 AM, Steven Schveighoffer wrote:

 How do dynamic closures work without the GC?


They don't allocate the closure on the GC heap. (Or do I have static/dynamic 
closures backwards?)
Aug 23 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/23/17 11:59 AM, Walter Bright wrote:

 On 8/23/2017 7:37 AM, Steven Schveighoffer wrote:

 How do dynamic closures work without the GC?


 
 They don't allocate the closure on the GC heap. (Or do I have 
 static/dynamic closures backwards?)


I thought "closure" means allocating the stack onto the heap so you can 
return the delegate with its context intact.

 From https://en.wikipedia.org/wiki/Closure_(computer_programming) :

"A language implementation cannot easily support full closures if its 
run-time memory model allocates all automatic variables on a linear 
stack. In such languages, a function's automatic local variables are 
deallocated when the function returns. However, a closure requires that 
the free variables it references survive the enclosing function's 
execution. Therefore, those variables must be allocated so that they 
persist until no longer needed, typically via heap allocation, rather 
than on the stack, and their lifetime must be managed so they survive 
until all closures referencing them have are no longer in use."

-Steve
Aug 23 2017
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven 
Schveighoffer wrote:

 On 8/23/17 11:59 AM, Walter Bright wrote:

 On 8/23/2017 7:37 AM, Steven Schveighoffer wrote:

 How do dynamic closures work without the GC?


 
 They don't allocate the closure on the GC heap. (Or do I have 
 static/dynamic closures backwards?)


 I thought "closure" means allocating the stack onto the heap so 
 you can return the delegate with its context intact.

 From 
 https://en.wikipedia.org/wiki/Closure_(computer_programming) :

 "A language implementation cannot easily support full closures 
 if its run-time memory model allocates all automatic variables 
 on a linear stack. In such languages, a function's automatic 
 local variables are deallocated when the function returns. 
 However, a closure requires that the free variables it 
 references survive the enclosing function's execution. 
 Therefore, those variables must be allocated so that they 
 persist until no longer needed, typically via heap allocation, 
 rather than on the stack, and their lifetime must be managed so 
 they survive until all closures referencing them have are no 
 longer in use."


Right, so if we wanted to support closures in betterC (we don't 
now, as my earlier example shows), they'd need a separate 
lifetime management implementation.
The two straightforward ones are either disable copying of 
closures in betterC (only moving them), so a single ownership 
model of their heap allocated context pointer is possible 
(deallocating the memory once the closure is destroyed), or make 
them reference counted.
The first has the disadvantage that you can't have two closures 
point to the same heap context (though to be honest, I haven't 
seen a codebase so far that actually uses that), but it should be 
trivial to implement. The RC variant is more complex (it would 
require an analysis if reference cycles can occur), but I think 
this might be one of the cases where RC is the right solution 
(and we might even consider using RC in normal D as well, if it 
works sanely).
Aug 23 2017
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven 
Schveighoffer wrote:

 I thought "closure" means allocating the stack onto the heap so 
 you can return the delegate with its context intact.


I understood closure as capture of variables from external 
context. They are divided into upward closures and downward 
closures, the former needs heap allocation.
Aug 24 2017
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


"D polymorphic classes will not, as they rely on the garbage 
collector."

They do? Don't have to allocate classes on the GC heap.
Aug 23 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 8:05 AM, John Colvin wrote:

 "D polymorphic classes will not, as they rely on the garbage collector."
 
 They do? Don't have to allocate classes on the GC heap.


Using them without the GC is a fairly advanced technique, and I don't want to 
deal with people writing:

     C c = new C();

and complaining that it doesn't work.
Aug 23 2017
prev sibling next sibling parent yawniek <yawniek srtnwz.com> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


nice article, however very unfortunate  introduction for the ADHD 
Generation as you start reading and you get put of by historical 
disabilities of D that are not true anymore. you may want to edit 
that and add the "until now" beforehand ;)
Aug 23 2017
prev sibling next sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it.


I like this concept of "upward compatibility," -- although 
opposed to backward it should be phrased "forward."

Will share also this one on LinkedIn...
I see D has official account on Facebook, Twitter, Reddit... No 
interest in LinkedIn? I think it can also be a good promotion 
platform for D.
Aug 23 2017
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 6:12 AM, Mike Parker wrote:

 The blog:
 
 https://dlang.org/blog/2017/08/23/d-as-a-better-c/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


Now on the front page of news.ycombinator.com !
Aug 23 2017
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d-
announce wrote:

 To coincide with the improvements to -betterC in the upcoming DMD
 2.076, Walter has published a new article on the D blog about
 what it is and why to use it. A fun read. And I'm personally
 happy to see the love this feature is getting. I have a project
 I'd like to use it with if I can ever make the time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


I confess that I tend to think of betterC as a waste of time. Clearly, there
are folks who find it useful, but it loses so much that I see no point in
using it for anything unless I have no choice. As long as attempts to
improve it don't negatively impact normal D, then I don't really care what
happens with it, but it's clearly not for me.

And it _is_ possible to use full-featured D from C/C++ when D does not
control main. It's just more of a pain.

- Jonathan M Davis
Aug 23 2017
next sibling parent sarn <sarn theartofmachinery.com> writes:
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 
wrote:

 I confess that I tend to think of betterC as a waste of time.


The overwhelming majority of programmers don't need betterC.  At 
all.  But today we live in a world where practically everything 
just builds on top of C, and we keep seeing how that goes wrong.  
I think Rust and betterC D are the best candidates we've got for 
replacing C everywhere C is used.
Aug 23 2017
prev sibling next sibling parent reply Michael V. Franklin <none none.com> writes:
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 
wrote:


 I confess that I tend to think of betterC as a waste of time. 
 Clearly, there are folks who find it useful, but it loses so 
 much that I see no point in using it for anything unless I have 
 no choice. As long as attempts to improve it don't negatively 
 impact normal D, then I don't really care what happens with it, 
 but it's clearly not for me.

 And it _is_ possible to use full-featured D from C/C++ when D 
 does not control main. It's just more of a pain.


I'm somewhat in agreement here.  I wouldn't call it a "waste of 
time", but I would prefer refactoring D's implementation to make 
using full-featured D from C/C++ less of a pain.  I fear, 
however, that -betterC will be the favored excuse for not 
pursuing or prioritizing such improvements.

Consider this:  Rust doesn't need a special switch to make it 
interoperable with C.  What's wrong with D's implementation that 
requires such things?  Granted, D is not Rust, but D's 
implementation could be improved to make it more competitive with 
Rust in these use cases.  For example, there is really no need 
for TypeInfo if you're not doing any dynanmic casts, but the 
current implementation generates it regardless.  I find -betterC 
to be somewhat of a copout for avoiding the hard work of 
improving D's implementation.

Mike
Aug 23 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Thu, Aug 24, 2017 at 12:35:22AM +0000, Michael V. Franklin via
Digitalmars-d-announce wrote:
[...]

 Consider this:  Rust doesn't need a special switch to make it
 interoperable with C.  What's wrong with D's implementation that
 requires such things?  Granted, D is not Rust, but D's implementation
 could be improved to make it more competitive with Rust in these use
 cases.  For example, there is really no need for TypeInfo if you're
 not doing any dynanmic casts, but the current implementation generates
 it regardless.  I find -betterC to be somewhat of a copout for
 avoiding the hard work of improving D's implementation.


[...]

One thing that would help is if things like TypeInfo, ModuleInfo, etc.,
are only emitted on-demand, or if they are stored as weak symbols in the
object file so that the linker can just omit them if they are never
referenced.

Ideally, the GC would also be on-demand, but it's currently too tightly
integrated with druntime for this to be possible. At least, it would
take a huge amount of effort to make it work.  Similarly, thread-related
stuff might be difficult to make optional, since the D startup code is
dependent on it.

Other smaller things in druntime like string switches, array comparison
functions, etc., could possibly also be optionally included, but then
you'll need to link (parts of) druntime. It will be more troublesome,
but within the realm of possibility, I think.

I, for one, would be happier if D's features are more pay-as-you-go so
that simpler programs don't have to pull in a whole bunch of executable
bloat that's not actually going to be used.


T

-- 
Let's eat some disquits while we format the biskettes.
Aug 23 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-08-24 02:55, H. S. Teoh via Digitalmars-d-announce wrote:


 One thing that would help is if things like TypeInfo, ModuleInfo, etc.,
 are only emitted on-demand


I think that would be quite difficult if we want to keep all the 
existing features. Combining separate compilation, runtime reflection 
and similar features make it difficult to know when a Type/ModuleInfo is 
used.

-- 
/Jacob Carlborg
Aug 24 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/23/2017 5:35 PM, Michael V. Franklin wrote:

 Consider this:  Rust doesn't need a special switch to make it interoperable
with 
 C.  What's wrong with D's implementation that requires such things? 
Granted, D 
 is not Rust, but D's implementation could be improved to make it more 
 competitive with Rust in these use cases.  For example, there is really no
need 
 for TypeInfo if you're not doing any dynanmic casts, but the current 
 implementation generates it regardless.


There is a PR to make it only on demand,

   https://github.com/dlang/dmd/pull/6561

but it is mired in problems that are not in the D test suite and for which no 
test cases exist.


 I find -betterC to be somewhat of a 
 copout for avoiding the hard work of improving D's implementation.


On the contrary, I view it as providing motivation for dealing with those 
issues. The PR above is stalled for lack of motivation.

---

Another issue is asserts. -betterC redirects them to C's assert. Perhaps we 
should abandon D's asserts? -betterC provides motivation to examine that.
Aug 24 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/24/2017 11:56 AM, Walter Bright wrote:

 I find -betterC to be somewhat of a copout for avoiding the hard work of 
 improving D's implementation.


 
 On the contrary, I view it as providing motivation for dealing with those 
 issues. The PR above is stalled for lack of motivation.


-betterC also brings into sharp focus exactly what the issues are.
Aug 24 2017
parent reply Michael V. Franklin <none none.com> writes:
On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright wrote:

 On 8/24/2017 11:56 AM, Walter Bright wrote:

 I find -betterC to be somewhat of a copout for avoiding the 
 hard work of improving D's implementation.


 
 On the contrary, I view it as providing motivation for dealing 
 with those issues. The PR above is stalled for lack of 
 motivation.


 -betterC also brings into sharp focus exactly what the issues 
 are.


Great! I look forward to seeing improvements and hope to help.

Allow me to point out a recent pull request that should have 
resulted in an improvement in the full-featured D implementation 
rather than the -betterC implementation.

https://github.com/dlang/dmd/pull/6918

DMD should never link in Phobos or druntime automatically. 
Rather, I think such dependencies should be specified on a 
platform-by-platform basis using a dmd.conf, linker script, or 
some other configuration file that is distributed with the 
toolchain's package.

This puts the power in the hands of the user to avoid linking in 
Phobos and druntime without having to use the -betterC switch 
which is especially useful if the user is providing their own 
minimal runtime implementation to support features of D that are 
excluded with the heavy hand of -betterC.

Mike
Aug 24 2017
parent reply Mengu <mengukagan gmail.com> writes:
On Friday, 25 August 2017 at 00:24:14 UTC, Michael V. Franklin 
wrote:

 On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright 
 wrote:

 [...]


 Great! I look forward to seeing improvements and hope to help.

 [...]


i believe that should be an opt-out. what about newcomers? will 
they have to learn how to link std lib?
Aug 25 2017
parent Michael V. Franklin <none none.com> writes:
On Friday, 25 August 2017 at 23:13:53 UTC, Mengu wrote:

 On Friday, 25 August 2017 at 00:24:14 UTC, Michael V. Franklin 
 wrote:

 On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright 
 wrote:

 [...]


 Great! I look forward to seeing improvements and hope to help.

 [...]


 i believe that should be an opt-out. what about newcomers? will 
 they have to learn how to link std lib?


No, because the dmd.conf that is delivered with the toolchain is 
already ready to go with reasonable defaults; and not hard-coded 
into the compiler.  Advanced users can update dmd.conf or point 
the compiler to a different dmd.conf as they choose.

Mike
Aug 25 2017
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 24 August 2017 at 18:56:25 UTC, Walter Bright wrote:

 There is a PR to make it only on demand,

   https://github.com/dlang/dmd/pull/6561

 but it is mired in problems that are not in the D test suite 
 and for which no test cases exist.


C++ compilers also have a switch, like -fno-rtti, for 
de-activating RTTI. BetterC seems like a combination of several 
pieces of underlying functionality. There is not yet any ability 
to have any kind of granularity. For instance,
-betterC=[flag]
where [flag] might be something like "off-dassert" which calls 
the C assert function instead of the D one.
Aug 24 2017
prev sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 
wrote:

 On Wednesday, August 23, 2017 13:12:04 Mike Parker via 
 Digitalmars-d- announce wrote:

 [...]


 I confess that I tend to think of betterC as a waste of time. 
 Clearly, there are folks who find it useful, but it loses so 
 much that I see no point in using it for anything unless I have 
 no choice. As long as attempts to improve it don't negatively 
 impact normal D, then I don't really care what happens with it, 
 but it's clearly not for me.

 And it _is_ possible to use full-featured D from C/C++ when D 
 does not control main. It's just more of a pain.

 - Jonathan M Davis


Totally agree with this.
Aug 23 2017
parent twkrimm <invalid 123.xxx> writes:
On Thursday, 24 August 2017 at 03:31:02 UTC, Swoorup Joshi wrote:

 On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 
 wrote:

 On Wednesday, August 23, 2017 13:12:04 Mike Parker via 
 Digitalmars-d- announce wrote:

 [...]


 I confess that I tend to think of betterC as a waste of time. 
 Clearly, there are folks who find it useful, but it loses so 
 much that I see no point in using it for anything unless I 
 have no choice. As long as attempts to improve it don't 
 negatively impact normal D, then I don't really care what 
 happens with it, but it's clearly not for me.

 And it _is_ possible to use full-featured D from C/C++ when D 
 does not control main. It's just more of a pain.

 - Jonathan M Davis


 Totally agree with this.


I disagree, I believe BetterC is worth the time.
Aug 24 2017
prev sibling next sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


Thanks for this feature! Looking forward to see its future  --Ilya
Aug 23 2017
prev sibling next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
On 23 August 2017 at 19:44, Jonathan M Davis via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d-
 announce wrote:

 To coincide with the improvements to -betterC in the upcoming DMD
 2.076, Walter has published a new article on the D blog about
 what it is and why to use it. A fun read. And I'm personally
 happy to see the love this feature is getting. I have a project
 I'd like to use it with if I can ever make the time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


 I confess that I tend to think of betterC as a waste of time. Clearly, there
 are folks who find it useful, but it loses so much that I see no point in
 using it for anything unless I have no choice. As long as attempts to
 improve it don't negatively impact normal D, then I don't really care what
 happens with it, but it's clearly not for me.

 And it _is_ possible to use full-featured D from C/C++ when D does not
 control main. It's just more of a pain.


It's getting better, there are certainly some tough topics that need
to be addressed in the compiler implementation.

The GDC camp concurs with the sentiment of betterC being a waste of
time.  My particular stance on the matter is that it should not be an
all or nothing switch, granular control is fine.  The compiler should
(and can!) produce a very small footprint whilst using the expressive
richness of the language.

For instance, a D project targeting STM board, makes heavy use of
classes and templates, resultant code segment is 3k.

https://github.com/JinShil/stm32f42_discovery_demo#the-good

I quote the author here that when building the project, there is:

"""
No Stinking -betterC. If you don't want the overhead of a certain
feature of D, don't use it. -betterC is just a synonymn for -worseD.
"""
Aug 24 2017
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Thu, Aug 24, 2017 at 08:13:29PM +0200, Iain Buclaw via
Digitalmars-d-announce wrote:
[...]

 The GDC camp concurs with the sentiment of betterC being a waste of
 time.  My particular stance on the matter is that it should not be an
 all or nothing switch, granular control is fine.  The compiler should
 (and can!) produce a very small footprint whilst using the expressive
 richness of the language.
 
 For instance, a D project targeting STM board, makes heavy use of
 classes and templates, resultant code segment is 3k.
 
 https://github.com/JinShil/stm32f42_discovery_demo#the-good
 
 I quote the author here that when building the project, there is:
 
 """
 No Stinking -betterC. If you don't want the overhead of a certain
 feature of D, don't use it. -betterC is just a synonymn for -worseD.
 """


To be fair, though, the above-mentioned project did have to create a
stub druntime in order to get things to work.  Not everyone may have the
know-how required to construct a minimal druntime that works for their
purposes.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
Aug 24 2017
parent Michael V. Franklin <none none.com> writes:
On Thursday, 24 August 2017 at 18:26:37 UTC, H. S. Teoh wrote:


 For instance, a D project targeting STM board, makes heavy use 
 of classes and templates, resultant code segment is 3k.
 
 https://github.com/JinShil/stm32f42_discovery_demo#the-good





 To be fair, though, the above-mentioned project did have to 
 create a stub druntime in order to get things to work.  Not 
 everyone may have the know-how required to construct a minimal 
 druntime that works for their purposes.


Those runtime stubs are needed precisely because of problems in 
D's implementation.  If the implementation were fixed, none of 
those stubs would be required, and neither would the -betterC 
switch.

Because the project above is not using any feature provided by 
those runtime stubs, those stubs should not be required, and 
neither should the -betterC switch.

GDC has made some improvements here, and that is why the project 
above only compiles with GDC.

LDC doesn't even display an error message when those stubs aren't 
created.  Instead it enters a codegen loop generating a 
gargantuan multi-gigabyte file, ultimately crashing my VM 
(https://github.com/ldc-developers/ldc/issues/781).

Sometimes, however, it is not known whether a runtime feature 
will be needed until link-time.  In that case, it's OK for the 
compiler to emit TypeInfo, ModuleInfo, etc..., but it should do 
so in a way that the linker (with either LTO or --gc-sections) 
can determine what is needed and what isn't and discard that 
which isn't needed.  Once unneeded object code is discarded, the 
linker errors disappear, and you get a functioning executable 
without linking in the runtime and without a -betterC switch.

GDC recently implemented such an improvement 
(https://github.com/D-Programming-GDC/GDC/pull/505).  It brought 
my binary size from 600kB to 6KB, so now I can get back to 
microcontroller programming in D.  This is the kind of work 
that's needed.

Mike
Aug 24 2017
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote:

 To coincide with the improvements to -betterC in the upcoming 
 DMD 2.076, Walter has published a new article on the D blog 
 about what it is and why to use it. A fun read. And I'm 
 personally happy to see the love this feature is getting. I 
 have a project I'd like to use it with if I can ever make the 
 time for it!

 The blog:

 https://dlang.org/blog/2017/08/23/d-as-a-better-c/

 Reddit:
 https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


Questions regarding c++ classes in betterC mode. Can the c++ 
class destructor be called by the destroy function or do I have 
to call it explicitly like p-<~class()?

Alex
Aug 24 2017
prev sibling next sibling parent reply Azi Hassan <azi.hassan live.fr> writes:
How should command-line arguments be used in better C ? Looping 
through argv seems to print environment variables :

import core.stdc.stdio;

extern(C) int main(int argc, char*[] argv, char*[] env)
{
	foreach(i; 0 .. argc)
		printf("arg %d: %s\n", i, argv[i]);
	return 0;
}


Compiling with v2.076.0-b2-dirty on Lubuntu 14.04 and running 
with one argument outputs the following :

arg 0: XDG_VTNR=7
arg 1: LC_PAPER=fr_FR.UTF-8
Aug 30 2017
next sibling parent Azi Hassan <azi.hassan live.fr> writes:
On Wednesday, 30 August 2017 at 22:22:23 UTC, Azi Hassan wrote:

 How should command-line arguments be used in better C ? Looping 
 through argv seems to print environment variables :

 import core.stdc.stdio;

 extern(C) int main(int argc, char*[] argv, char*[] env)
 {
 	foreach(i; 0 .. argc)
 		printf("arg %d: %s\n", i, argv[i]);
 	return 0;
 }


 Compiling with v2.076.0-b2-dirty on Lubuntu 14.04 and running 
 with one argument outputs the following :

 arg 0: XDG_VTNR=7
 arg 1: LC_PAPER=fr_FR.UTF-8


Forgot to mention, char*[] env was only for testing purposes. The 
code still produces the same output with char*[] env omitted.
Aug 30 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 30 August 2017 at 22:22:23 UTC, Azi Hassan wrote:

 extern(C) int main(int argc, char*[] argv, char*[] env)


That's a D array of pointers. A D array is larger than a C 
"array" argument, thus you're skipping past it.

The correct declaration is (int argc, char** argv, char** env).

(I'd argue that is the correct way to write it in C too, that's 
how I always do and it works there. But I just loathe C's arrays 
anyway.)
Aug 30 2017
parent Azi Hassan <azi.hassan live.fr> writes:
On Wednesday, 30 August 2017 at 22:48:45 UTC, Adam D. Ruppe wrote:

 On Wednesday, 30 August 2017 at 22:22:23 UTC, Azi Hassan wrote:

 extern(C) int main(int argc, char*[] argv, char*[] env)


 That's a D array of pointers. A D array is larger than a C 
 "array" argument, thus you're skipping past it.

 The correct declaration is (int argc, char** argv, char** env).

 (I'd argue that is the correct way to write it in C too, that's 
 how I always do and it works there. But I just loathe C's 
 arrays anyway.)


Brilliant, thanks ! I just re-read the blog post and it uses the 
char** syntax too, but I didn't pay attention to it.
Sep 01 2017
prev sibling parent reply Claude <no no.no> writes:
I think "betterC" can be a good tool to use D on embedded 
systems, keep as few dependencies as possible, a low ROM 
footprint and a good C interoperability.

I'll try to find some time to play with it.
Aug 31 2017
parent twkrimm <invalid 123.xxx> writes:
On Thursday, 31 August 2017 at 13:17:36 UTC, Claude wrote:

 I think "betterC" can be a good tool to use D on embedded 
 systems, keep as few dependencies as possible, a low ROM 
 footprint and a good C interoperability.

 I'll try to find some time to play with it.


I agree, embedded systems is one of the reasons I think betterC 
is a good idea.
Sep 07 2017