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...
>
>

"Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
> 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?

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
pay
> for great features, D offeres.  I understand that now the memory/disk
space
> is cheap, but...
>
>

Elbert Lev schrieb:

> 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

"Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
> 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...

In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.

Walter wrote:

> 
> "Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
>> 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...
> 
> In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.

There is some way to completely disable GC, avoiding this extra code? Reading the especs I learnt about gc.disable(), but I'm no sure if it avoid the GC code.

Thanks,

Bruno.

Walter wrote:

> 
> "Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
>> 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...
> 
> In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.

Is there a fundamental reason why the garbage collector code has to be statically linked?

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...
>
> "Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
> > 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...
>
> In general, a D executable will be the same size as a C++ one plus about
40k
> for the garbage collector code. However, as Ilya pointed out, D code
should
> grow slower than C++ code.
>
>

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...
> >
> > "Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
> > > 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...
> >
> > In general, a D executable will be the same size as a C++ one plus about
> 40k
> > for the garbage collector code. However, as Ilya pointed out, D code
> should
> > grow slower than C++ code.
> >
> >
>
>

>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.

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
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...
> > >
> > > "Elbert Lev" <elbertlev@hotmail.com> wrote in message news:c730ri$1di8$1@digitaldaemon.com...
> > > > 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...
> > >
> > > In general, a D executable will be the same size as a C++ one plus
about
> > 40k
> > > for the garbage collector code. However, as Ilya pointed out, D code
> > should
> > > grow slower than C++ code.
> > >
> > >
> >
> >
>
>