Re: Programs in D are huge
On Friday, 19 August 2022 at 11:18:48 UTC, bauss wrote: It's one thing D really misses, but is really hard to implement when it wasn't thought of to begin with. It should have been implemented alongside functions that may change between languages and cultures. I guess we have another task for Phobos v2.
Re: Programs in D are huge
On Friday, 19 August 2022 at 06:34:19 UTC, Patrick Schluter wrote: On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole wrote: On 19/08/2022 4:56 AM, IGotD- wrote: BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality. Unicode support in Full D isn't complete. There is nothing in phobos to even change case correctly! Both are limited if you care about certain stuff like non-latin based languages like Turkic. A general toupper/tolower for Unicode is doomed to fail. As already mentioned Turkish has its specificity, but other languages also have traps. In Greek toupper/tolower are not reversible i.e. `x.toupper.tolower == x` is not guaranteed . Some languages have 1 codepoint input and 2 codepoints as result (German ß becomes SS in most cases, capital ẞ is not the right choice in most cases). etc. etc. That's why you should implementat formatting providers for languages that handle such things. Like in C# you have the CultureInfo class that you can give to methods such as ToString, ToLower etc. which will correctly handle specific "cultures" It's one thing D really misses, but is really hard to implement when it wasn't thought of to begin with. It should have been implemented alongside functions that may change between languages and cultures.
Re: Programs in D are huge
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole wrote: Unicode support in Full D isn't complete. There is nothing in phobos to even change case correctly! Both are limited if you care about certain stuff like non-latin based languages like Turkic. I think full D is fine for terminal programs. What you commonly do is tokenize text, remove white space, convert text to numbers etc. The D library is good for these tasks. Rewrite all this for betterC would be a tedious tak
Re: Programs in D are huge
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole wrote: On 19/08/2022 4:56 AM, IGotD- wrote: BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality. Unicode support in Full D isn't complete. There is nothing in phobos to even change case correctly! Both are limited if you care about certain stuff like non-latin based languages like Turkic. A general toupper/tolower for Unicode is doomed to fail. As already mentioned Turkish has its specificity, but other languages also have traps. In Greek toupper/tolower are not reversible i.e. `x.toupper.tolower == x` is not guaranteed . Some languages have 1 codepoint input and 2 codepoints as result (German ß becomes SS in most cases, capital ẞ is not the right choice in most cases). etc. etc.
Re: Programs in D are huge
On 19/08/2022 4:56 AM, IGotD- wrote: BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality. Unicode support in Full D isn't complete. There is nothing in phobos to even change case correctly! Both are limited if you care about certain stuff like non-latin based languages like Turkic.
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 BetterC means no arrays or strings library and usually in terminal tools you need to process text. Full D is wonderful for such task but betterC would be limited unless you want to write your own array and string functionality.
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
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
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.
Re: Programs in D are huge
On 8/16/22 4:25 AM, Diego wrote:
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?
By default (but changing in some cases), D links the standard library in
statically. This means that every D executable has a copy of the library
(at least the used functions).
If you use C for a comparison, you have to include the C library size as
well when comparing. On my system, libc is 2MB.
You can reduce size by using dynamic linking, but the drawback is that
then you have to ensure the library exists on the target system in order
to run.
If you are shipping a package with lots of D binaries it might make
sense to do this, but for one-offs, probably not.
-Steve
Re: Programs in D are huge
On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote: 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? If compile speed and verbose error codes are not important, use ldc2 with the -O1 parameter. There is also strip for Linux. For example, a simple program: LCD2+strip: 138.5KB. DMD: 1.9 MB. SDB@79
Re: Programs in D are huge
On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote: It seams huge in my opinion for an empty program What are the best practices to reduce the size? The problem is that the druntime, the run time library needed to support many D features, is large and linked in its entirety by default. The linker could strip unused functions, but even in an empty program, a lot is done before `main` that pulls in most of it: - initializing floating point settings, signal handlers, stdout and stderr - parsing --DRT command line options for configuring the Garbage Collector - running module constructors / unit tests There is a goal to make druntime more 'pay as you go' so these things only happen when they're needed, but progress is slow. In the mean time, if you can live without a lot of D features that require the runtime, you can use `-betterC`: https://dlang.org/spec/betterc.html With the LDC2 compiler, you can use `--link-defaultlib-shared`, so your program dynamically links with the run time library. This doesn't help for a single D program, but multiple D programs can reuse a single shared library. Finally, you could look at customized versions of the runtime, such as Light Weight D Runtime: https://github.com/hmmdyl/LWDR
Re: Programs in D are huge
On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote:
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?
This is normal, by default you have plenty of typeinfo (static
data allowing dynamic introspection), code located in implicit
import object.d, the runtime (e.g code for the GC).
You can really get rid of that, excepted using -betterC, but you
see all the stuff that make the default main program big will
actually be useful in a real program.
It's just that D is not as much "pay as you go" as that, for now.
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?
