Xref: utzoo comp.lang.eiffel:245 comp.lang.c++:3586
Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!jos
From: jos@cs.vu.nl (Jos Warmer)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Message-ID: <2714@vlot.cs.vu.nl>
Date: 8 Jun 89 08:00:50 GMT
References: <2689@ssc-vax.UUCP> <150@eiffel.UUCP> <124@tridom.uucp> <5975@watdcsu.waterloo.edu> <25321@agate.BERKELEY.EDU>
Reply-To: jos@cs.vu.nl (Jos Warmer)
Organization: VU Informatica, Amsterdam
Lines: 38

In article <JWG1.89Jun6172452@bunny.gte.com> jwg1@bunny.gte.com (James W. Gish) writes:
>
>The following "Hello world" program generated an executable on a Sun3
>of 147456 bytes:
                           [... removed ...]
>The .eiffel file used was:
>
>ALL_ASSERTIONS (Y):
>C_PACKAGE (N):

The size of executables in Eiffel depends very much on the compile options.
The smallest size will be reached when all assertions are turned off.
And all optimizations like inline functions and others are only done
when generating a C package. Using:

ALL_ASSERTIONS(N): ALL
C_PACKAGE (Y): C

gives an executable of 73728 bytes. Using `strip world' gives 57344 bytes.
(Eiffel Version 2.1b, SUN3.5)

Besides, I do agree with Don Ahn:

In article <25321@agate.BERKELEY.EDU> donahn@gypsum.berkeley.edu (Don Ahn) writes:
>
>What I'd be more interested in here is the INCREMENTAL increase in executable
>size due to program lines/functionality. Given the fact that eiffel has more
>functionality in it's run-time environment (built in garbage collection etc..)
>it is understandable that for "trivial" programs code size will seem to be
>unexplainably huge.
   ...
                                 Jos Warmer
				 jos@cs.vu.nl
				 ...uunet!mcvax!cs.vu.nl!jos
-- 
                                 Jos Warmer
				 jos@cs.vu.nl
				 ...uunet!mcvax!cs.vu.nl!jos