I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree with them! Them I automatically compiled
supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain me
why?
I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to pay
for great features, D offeres. I understand that now the memory/disk space
is cheap, but...

Id say that yes, its just because all D programs have to linked statically with
the runtime. C++ is so popular that the run time comes in dlls (or the like)
with the operating system.
In article <c730ri$1di8$1 digitaldaemon.com>, Elbert Lev says...

I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree with them! Them I automatically compiled
supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain me
why?
I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to pay
for great features, D offeres. I understand that now the memory/disk space
is cheap, but...

I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree with them! Them I automatically

supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain

why?

It's an overhead (needed for GC) that seems extremely large for small
trivial programs such as those presented in the examples. This overhead
however is static and does not grow with the size of the program. Thus, a
program of significant value or size (comercially viable programs
[opensource or otherwise]) will not be affected by the menial overhead
imposed.

I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to

I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree with them! Them I automatically compiled
supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain me
why?

Because a very basic C++ application compiled with DigitalMars compiler
is also the same size, a C application perhaps 15 kilobytes smaller. If
you are used to Microsoft compilers: the Microsoft C runtime is
distributed with Windows. Some other compilers, like LCC and MinGW also
use it, and thus can have very small footprint on executable. But since
DigitalMars compilers use their own C runtime, it was decided that it
should be linked in, so that compatibility is not sacrificed. In fact,
it might be possible to make DigitalMars compilers work with the MS C
runtime DLL, though there's probably not too much sense at the moment.
The current D runtime is built upon C runtime and pulls a significant
portion of it in. This is quite wise since C standard library is a part
of the D standard library specification anyway, and would likely be
pulled in by some other library or part of application anyhow.

I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to pay
for great features, D offeres. I understand that now the memory/disk space
is cheap, but...

You are right, on both points. Besides, size matters even more for big
applications than for small ones, and i suspect D executables grow
significantly more slowly than C++, because most of memory management
code disappears, along with most try/finally frames automatically
generated by the C++ compiler. So i would say, D features rather save
space than sacrifice it, on the large count.
-eye

OK! Statically linked run-time library is fine for a big program, but there
are cases when one needs a set of utilities (like Unix text utilities), or
small and simple GUI programs. Why not to have dll (so) for dynamic linking
and the developer can choose which stile to use? I do not think that this is
hard to do, or dlls will create problems.
"Walter" <newshound digitalmars.com> wrote in message
news:c7521u$1dnt$2 digitaldaemon.com...

I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.
Since a great many utilities are run-briefly things, it would not pose a problem
if there was simply no GC. I'd like to be able to select a phobos-light.lib.
"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c76cic$ci0$1 digitaldaemon.com...

OK! Statically linked run-time library is fine for a big program, but there
are cases when one needs a set of utilities (like Unix text utilities), or
small and simple GUI programs. Why not to have dll (so) for dynamic linking
and the developer can choose which stile to use? I do not think that this is
hard to do, or dlls will create problems.
"Walter" <newshound digitalmars.com> wrote in message
news:c7521u$1dnt$2 digitaldaemon.com...

Since a great many utilities are run-briefly things, it would not pose a

if there was simply no GC. I'd like to be able to select a

True in most cases. For example grep. Usually you run it over a 100 files,
but then you run it over the directory with half a million files... But
phobos-light.lib is certainly another option. Also take into account that
dll version of phobos is nothing more then "repackaging" of existing code.
While light version is full rewrite.
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c786a3$2q2$1 digitaldaemon.com...

I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.
Since a great many utilities are run-briefly things, it would not pose a

In a system like linux (and most others) the "grep" program will be cached in
memory, so the 40K will only load once; but if it still bothers you, put
"gc.disable()" at the top of main(). Then the GC won't run, and therefore,
won't be paged in (saving you a few milliseconds). Dynamic paging means only
the used parts of the program are paged in, so its okay to add big libraries
that you don't use.
In this light, a shared library is actually worse - the linker has to iterate
over it and fix pointers each time it links. In KDE C++ applications, the large
numbers of virtual pointer-heavy classes were causing this linking phase to drag
out to as much as a quarter or half of a second per process run.
So, if you use a lot of virtual pointers, static linking is your friend, even if
the app gets bigger. Dynamic paging is cheap, linking shared objs is less so.
Kevin
In article <c786a3$2q2$1 digitaldaemon.com>, Matthew says...

I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.
Since a great many utilities are run-briefly things, it would not pose a problem
if there was simply no GC. I'd like to be able to select a phobos-light.lib.
"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c76cic$ci0$1 digitaldaemon.com...

OK! Statically linked run-time library is fine for a big program, but there
are cases when one needs a set of utilities (like Unix text utilities), or
small and simple GUI programs. Why not to have dll (so) for dynamic linking
and the developer can choose which stile to use? I do not think that this is
hard to do, or dlls will create problems.
"Walter" <newshound digitalmars.com> wrote in message
news:c7521u$1dnt$2 digitaldaemon.com...

//In a system like linux (and most others) the "grep" program will be cached
in
memory, so the 40K will only load once;
Only if the system is doing nothing (like most desktop systems are
supposed to do). If you have a server, which runs tons of programs, "grep in
memory" will be trashed by the database endine (for example).
I'm not talking about the speed or memory footprint, but disk and
distribution size. What you are saying is correct, but using shared
libraries would save 50% or more of the size of the executable. Now consider
such a system: 3 executables and 10 dll's. All written in D. Now you have
(with no run-time dll) 13 statically linked gc modules. So half meg for
nothing.
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c78dht$e5i$1 digitaldaemon.com...

In a system like linux (and most others) the "grep" program will be cached

memory, so the 40K will only load once; but if it still bothers you, put
"gc.disable()" at the top of main(). Then the GC won't run, and

won't be paged in (saving you a few milliseconds). Dynamic paging means

the used parts of the program are paged in, so its okay to add big

that you don't use.
In this light, a shared library is actually worse - the linker has to

over it and fix pointers each time it links. In KDE C++ applications, the

numbers of virtual pointer-heavy classes were causing this linking phase

out to as much as a quarter or half of a second per process run.
So, if you use a lot of virtual pointers, static linking is your friend,

the app gets bigger. Dynamic paging is cheap, linking shared objs is less

Kevin
In article <c786a3$2q2$1 digitaldaemon.com>, Matthew says...

I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.
Since a great many utilities are run-briefly things, it would not pose a

In a system like linux (and most others) the "grep" program will be cached
in
memory, so the 40K will only load once; but if it still bothers you, put
"gc.disable()" at the top of main(). Then the GC won't run, and
therefore,
won't be paged in (saving you a few milliseconds). Dynamic paging means
only the used parts of the program are paged in, so its okay to add big
libraries that you don't use.
In this light, a shared library is actually worse - the linker has to
iterate
over it and fix pointers each time it links. In KDE C++ applications, the
large numbers of virtual pointer-heavy classes were causing this linking
phase to drag out to as much as a quarter or half of a second per process
run.
So, if you use a lot of virtual pointers, static linking is your friend,
even if
the app gets bigger. Dynamic paging is cheap, linking shared objs is less
so.

Interesting aspect! Anyway: this should - if possible - be left as a
decision to the distibutor/administrator. Even if there are good reasons
for static linking of libraries, it will be seen as a limitation of the
compiler/linker/language, if shared libraries are not, or not fully,
supported.
There certainly are situations, where executable size is more important than
execution time or RAM usage.

THIS IS MY FIRST EXPERIMENT WITH D.
Taking in the account what was written by other people, I decided to write a
simple program, which "spies" on the file. Periodically it reads the file
(from current position) and prints it on the screen. Another program writes
text to the file. Very convenient for debugging of services. The program is
attached.
It does not work(!), because File.open(name, FileMode.In) opens the text
file in such a way, that "another" program can't update it! (In "C" FILE *f
= fopen(argv[1], "rb"); ALLOWS file updates by another process.)
The size of the executable is astonishing! 80K. So not only gc (as was
mentioned by people), but Stream and File are statically linked. I beleive,
that in "real life" program, which used most of the phobos, whoole
phobos.lib, as well as, third party libs will be linked to the executable
(So 400K+)
Give me a break!

THIS IS MY FIRST EXPERIMENT WITH D.
Taking in the account what was written by other people, I decided to write

simple program, which "spies" on the file. Periodically it reads the file
(from current position) and prints it on the screen. Another program

text to the file. Very convenient for debugging of services. The program

attached.
It does not work(!), because File.open(name, FileMode.In) opens the text
file in such a way, that "another" program can't update it! (In "C" FILE

= fopen(argv[1], "rb"); ALLOWS file updates by another process.)

Try closing the file after the spying is done!
or declare it like:
auto File file = new File();
and this way the destructor will be called when exiting the scope.

The size of the executable is astonishing! 80K. So not only gc (as was
mentioned by people), but Stream and File are statically linked. I

that in "real life" program, which used most of the phobos, whoole
phobos.lib, as well as, third party libs will be linked to the executable
(So 400K+)

I don't think executable size is a problem in D, it is true that like you
say a
basic console application is 60-70kB, but try writing a larger program.
I have a really complex and relativelly big program in D and it is only
120kB. That isn't souch a big increase in size.

Try closing the file after the spying is done!
or declare it like:
auto File file = new File();
and this way the destructor will be called when exiting the scope.

Will not help! The read position will not be preserved. Attached is "C"
program. Try to run it against the file. Then open the file in a notepad,
add a few lines and save. You will see che changes on the screen
By the way, a little bit off topic, but I compiled logspy.cpp with: Borland
free compiler, with MSC6 and with MinGW-gcc. All work the same way, but when
I compiled it with dmc.exe - the program does not work.
while (1)
{
while (1)
{
c = fgetc(f);
printf("%d\n", (int)c);
if (c == EOF)
break;
putchar(c);
}
Sleep(1000);
}
c = fgetc(f) always returns -1 (EOF).
Attached are both programs C and D
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c7avej$1c8q$1 digitaldaemon.com...

THIS IS MY FIRST EXPERIMENT WITH D.
Taking in the account what was written by other people, I decided to

a

simple program, which "spies" on the file. Periodically it reads the

(from current position) and prints it on the screen. Another program

text to the file. Very convenient for debugging of services. The program

attached.
It does not work(!), because File.open(name, FileMode.In) opens the text
file in such a way, that "another" program can't update it! (In "C"

*f

= fopen(argv[1], "rb"); ALLOWS file updates by another process.)

Try closing the file after the spying is done!
or declare it like:
auto File file = new File();
and this way the destructor will be called when exiting the scope.

The size of the executable is astonishing! 80K. So not only gc (as was
mentioned by people), but Stream and File are statically linked. I

that in "real life" program, which used most of the phobos, whoole
phobos.lib, as well as, third party libs will be linked to the

(So 400K+)

I don't think executable size is a problem in D, it is true that like you
say a
basic console application is 60-70kB, but try writing a larger program.
I have a really complex and relativelly big program in D and it is only
120kB. That isn't souch a big increase in size.