Hi Dennis,
Thanks for that explanation. I didn't know that, but the explanation
you gave makes sense.
On 2/20/12, Dennis Towne wrote:
> Thomas and Jim,
>
> Most of the time, the executable size is dominated by the linked in
> libraries, which are usually a lot bigger than the source. However,
>
Hi Dennis,
Thank you, I thought that was the difference between low level and high level
programming languages. I didn't know about the difference in for the target
machine though.
In the first Basic language that I programmed in it actually had peek, poke and
something like varpoint. And I
Thomas and Jim,
Most of the time, the executable size is dominated by the linked in
libraries, which are usually a lot bigger than the source. However,
the size of the executable is very dependent on the programming
language used and can be either bigger or smaller than the source code
depending
Hi Jim,
HI see what you mean. I wonder if perhaps when VB compiles
your executable files if it does statically link some libraries
resulting in the extra file size.
I know if I statically link some lib files, compile them directly into
the executable, naturally my exe file is larger becau
Hi Thomas,
Actually the opposite is true, my compiled executable files are always much
larger than my source code files. But that was not my point at all. It is
that some times the source code file compiles larger than other source code and
vice versa. Such as;
starmule frm 43,
Hi Jim,
The things I mentioned such as line indentions etc were examples only
of the kinds of things that get stripped when compiling. As I said
when it gets converted from source to an executable all the words in
your source code regardless of its a variable name, function name, etc
is converted
Hi Thomas,
Yes but, I do not do any of the things in my source code that you mentioned.
That is no rem statements, indenting of paragraphs or anything like that. So
my style is constant in my source code, but if you look at the two lists below
you would think that they would be in the same o
Hi Jim,
That's because the executable doesn't need everything included in your
source file. As I mentioned to Phil we do a lot of things to make
source code human readable like double spacing between functions,
commenting a line so what we know this line of text does, indenting
programs so we can
Hi Phil,
That's correct. Comments, extra spaces, and basically everything that
doesn't apply to the program itself gets stripped or rather ignored by
the compiler when compiling the code into a binary file. Even
languages like Python ande Java that are byte compiled and optomized
for the runtime e
was Python and Interactive Fiction
Hi Phil,
Hmmm, that is very interesting that the rem statements don't seem to change the
compiled executable file size. I might have to experiment with that.
I do know even though I am not sure why, that the size of the source code
doesn't always correspond
Hi. You are correct. Even the variable names are usually stripped from
the program when compiling.
On 2/17/2012 1:16 PM, Phil Vlasak wrote:
Hi Jim,
I think when a game is compiled, the compiler strips the rem, remark
statements and comment lines out of the executable.
Early on Carl was putting a
Hi Jim,
I think when a game is compiled, the compiler strips the rem, remark
statements and comment lines out of the executable.
Early on Carl was putting a lot of them in a game written in C plus plus for
DOS, so I could read his code. I compiled the game with and without the
extensive statements
12 matches
Mail list logo
