weiner@novavax.UUCP (Bob Weiner) (06/06/89)
In article <148@eiffel.UUCP> sarkela@eiffel.UUCP (John Sarkela) writes:
Second, consider some the features of C++ which Eiffel does
not possess. Eiffel does not possess global variables.
Eiffel does not possess pointers. The elimination of
gratuitous pointer aliasing and extern'ed globals allows a
smart compiler greater lattitude in generating optimized code.
This may true but many applications, especially real-time projects that
need the power of testable pre and post conditions, also need pointer
access to get at underlying hardware tied to different signal lines.
Alternatively, an environment that fully encapsulates the hardware
interface has to be provided.
Does this mean that inline assembler will never be supported in Eiffel?
I've read that the language is meant to interface well with external
programs and possibly modules. Can I link C or C++ object files into an
Eiffel application?
Are there any plans to support cross-compilers, e.g. licensing of Eiffel
to third parties with experience in cross-compiler development, or any
support for real-time, embedded applications? You are competing with
Ada as a development environment, aren't you?
--
Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
(407) 738-2087jima@hplsla.HP.COM (Jim Adcock) (06/08/89)
> I have heard that eiffel creates hideously large executables from very > trivial programs. Does anyone have any information as to whether this is > true or not?? I found that using advantage C++ also produced large > executables...one of the reason why I am using Zortech C_++ currently. It does > not seem to have this problem (executable size seems on average to be about > 1/5 the size of advantage c++ code). > We're talking 35K here for a hello world program in advantage...something > that can't be tolerated on the PC. One source gave the comparable eiffel > program a number even much higher. For reference here's some sizes comparing various C and C++ compilers on my mid-range 680x0 Un*x based system: linked& compile executable only hello world using stdio.h -- ie a 'printf' statement cc 12920 144 CC 13056 176 gcc 17081 172 g++ 17242 172 hello world using stream.h -- ie cout << "hello world\n" CC 34232 617 g++ *** 4577 a null program: main(){} -- to test size of run-time environment cc 4240 83 CC 4372 111 gcc 6622 120 g++ 6783 120 *** I don't have a compiled stream library for g++ cc is hp-ux 6.5 C compiler CC is AT&T cfront using hp-ux 6.5 as the back end gcc is gnu-c for the 68020 g++ is gnu-c++ for the 68020 All sizes are file sizes in bytes -- code sizes are obviously somewhat smaller -- for example cc -O -S null.c generates a _main subroutine of exactly one machine instruction -- rts [return from subroutine] Some conclusions: Trivial C programs are not exactly tiny under un*x no matter what. No great difference in executable size between C and C++ under un*x. C and C++ executables for small programs [simple tools] are probably several times smaller than other OOPL exacutables due to a simpler run time environment. G++ compiles can be several times bigger than CC compiles since G++ generates code for in-line functions [while also maybe in-lining them.] Sure would be nice to have an OS with good support for shared libraries.
bs@alice.UUCP (Bjarne Stroustrup) (06/10/89)
We seem to have improved a bit. 2.0 gives:
$ cat h.c
#include <stdio.h>
main()
{
printf("Hello, world\n");
}
$ nCC h.c
nCC h.c:
cc h.i /usr/lib/nlibC.a
size a.out
$ text data bss dec hex
18432 2048 0 20480 5000
$
on my VAX
The printf() version equals C as usual.