Re: Programs in D are huge
On Wednesday, 17 August 2022 at 17:25:51 UTC, Ali Çehreli wrote: On 8/17/22 09:28, Diego wrote: > I'm writing a little terminal tool, so i think `-betterC` is the best > and simple solution in my case. It depends on what you mean with terminal tool bun in general, no, full features of D is the most useful option. I've written a family of programs that would normally be run on the terminal; I had no issues that would warrant -betterC. Ali Thank you all, As suggested from Salih is better to use `ldc2` with `--link-defaultlib-shared` and `-O1` Ali, your book is a fluent reading, thank you :) Diego
Re: Programs in D are huge
Thank you to everyone, I'm writing a little terminal tool, so i think `-betterC` is the best and simple solution in my case.
Programs in D are huge
Hello everyone,
I'm a Java programmer at work but i'm learning D for pleasure.
I'm reading _The D Programming Language by Ali Çehreli_.
I noticed that DMD creates very huge executable, for example an
empty program:
```
empty.d:
void main() {
}
```
after a compilation with these flags `dmd -de -w empty.d` i have
an executable of 869KiB
It seams huge in my opinion for an empty program
What are the best practices to reduce the size?
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote: I had a little fun today kicking the crap out of C's memcpy with a D implementation. https://github.com/JinShil/memcpyD Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with. If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results. Feedback, advise, and pull requests to improve the implementation are most welcome. Mike Hello Mike, These are my results: Ubuntu 16.04.4 amd64 Linux 4.16.0-ck1+ Intel Xeon E5-2620 0 @ 2.00GHz - 12 cores 32 GB RAM dmd -O -release memcpyd.d # dmd 2.080.0 size memcpyC memcpyD 1 125349 47658 2 155014 50492 4 173099 52669 8 228236 52676 16 107897 32621 32 128039 32604 64 163644 37658 128 223840 50420 256 338769 90300 512 584772 171038 1024 878093 995813 2048 1346958 1254141 4096 2439378 2101284 8192 5631202 3554307 16384 9873090 6496635 32768 22489302 21328288 65536 50522961 45748356 size memcpyC memcpyD 1 123241 27631 1 130758 28165 1 123247 32748 2 142964 27587 2 140914 28103 4 168084 32616 4 171166 27590 8 228274 27604 8 233249 27605 4 168624 27597 8 238049 29435 16 103956 52730 ldc2 -O3 -release memcpyd.d # ldc2 1.10.0-beta1 (I think these are strange results) size memcpyC memcpyD 1 0 0 2 0 0 4 0 0 8 0 0 16 559 0 32 1003 0 64 0 0 128 0 0 256 0 0 512 0 0 1024 460182 1519048 2048 739148 1973641 4096 1533047 3168472 8192 2913463 5560106 16384 6385370 10353178 32768 20889322 21487968 65536 44920382 48339716 size memcpyC memcpyD 1 0 0 1 0 0 1 0 0 2 0 0 2 0 0 4 0 0 4 0 0 8 0 0 8 0 0 4 0 0 8 0 0 16 0 0
Re: Why does this not compile?
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
You cannot assign a const element (`a`) to a non-const element
(`b`) in `S b = a` expression. To make de assignment, you have to
cast a to a non-constant expression:
S b = cast(S)a;
Or make `b` as const:
const S b = a;
Or, better, use auto keyword:
auto b = a;
Re: Is there a cleaner way of doing this?
On Monday, 7 August 2017 at 08:01:26 UTC, Shachar Shemesh wrote:
It is often desired to have a struct with an extra parameter.
The common way to do this is like so:
struct S(T) {
T param;
void initialize(T param) {
this.param = param;
// Other stuff
}
}
The problem is what happens when the param is optional. The
common way to do this is to set T to void. This results in the
following code:
struct S(T) {
enum HasParam = !is(T == void);
static if( HasParam ) {
T param;
}
static if( HasParam ) {
void initialize(T param) {
this.param = param;
// Other stuff
}
} else {
void initialize() {
// Same other stuff as above!
}
}
}
This is both tedious and error prone. Is there a cleaner way of
doing this?
Just as an unrealistic fantasy, if the following code was
legal, the problem would be resolved on its own:
void func(void p) {
void param;
param = p;
return param;
}
Of course, that code has its own set of problems, and I'm not
really suggesting that change.
Shachar
You can use type default initialization property:
struct S(T) {
T param;
void initialize(T param = T.init) {
this.param = param;
// Other stuff
}
}
S!int s;
s.initialize(42); // works
s.initialize(); // also works; s.param == int.init == 0
