Ada vs. C

Ada vs. C

[The Quelisher]

I have found one thing that C has an advantage over Ada : executable
file sizes. Everything I have programmed in Ada is HUGE compared to a
program thta does the same thing but written in C.

Just my $.02
-- 
    *.........................................*
    .                |/                       .
    .                |\ENDAL                  .
    . WWW   => http://www.cs.fsu.edu/~vandyke .
    . EMail => kendal@freenet.scri.fsu.edu    .
    . Pager => (904) 297-6658                 .
    .                                         .
    *.........................................*

Re: Ada vs. C

[Robert Dewar]

The Quelisher says

"I have found one thing that C has an advantage over Ada : executable
file sizes. Everything I have programmed in Ada is HUGE compared to a
program thta does the same thing but written in C."


That's bogus, comparable programs in Ada and C will generate executables
of the same size, at least using a technology like GNAT. You have however
to be careful about that "comparable". Note for example that in GNAT,
by default the executable files contain debugging information which is
typically much more voluminous than the code itself -- so make sure 
you are comparing stripped file sizes. Second, in some version of GNAT,
the default is to link statically, and in others to link dynamically.
Be careful you are not comparing a statically linked Ada program to a
dynamically linked C program.

It's true that in the default configuration on some ports of GNAT, the
exe files will be bigger, due in particular to the inclusion by default
of debugging information. This choice of defaults is deliberate and
reflects the fact that disk prices have dropped dramatically, so the
gain from having the debugging information around seems worth the space
(after all a 300K file these days is occupying 5 cents worth of disk space).
Note also that it is ONLY a space issue, the debugging information is not
loaded if you are not debugging.

But anyway, if you don't want the debugging information, just make sure
it is stripped.

Re: Ada vs. C

[The Quelisher]

Robert Dewar wrote:
> That's bogus, comparable programs in Ada and C will generate 
> executables of the same size, at least using a technology like GNAT. 

Ok, so let me explain where I am coming from then. Here is the source in
both languages that does the exact same very basic thing:
-----------------------------------------------------------------------
C :
	main()
	{
		printf("Hello world! \n");
	}

-----------------------------------------------------------------------
Ada :

	WITH Ada.Text_IO; USE Ada.Text_IO;
	PROCEDURE hello IS
	BEGIN
	  Put_line("Hello world!");
	END hello;
-----------------------------------------------------------------------

When I compiled each of the above here are the file sizes that resulted:
	C ----> 24,576
	Ada -->	253,952

I used gcc to compile the C code and gnatmake for the Ada code, both on
unix machines. Now that's what I meant by the difference in file sizes.
I understand though that there is a tradeoff between file size and
functionability of a program, but let's take PC's for example. Who wants
to run a 6 mb program written in Ada when a 2mb program written in C
does the same thing? I'm not trying to knock Ada or anything, rather
just making an observation. Again, just my $.02

-- 
    *.........................................*
    .                |/                       .
    .                |\ENDAL                  .
    . WWW   => http://www.cs.fsu.edu/~vandyke .
    . EMail => kendal@freenet.scri.fsu.edu    .
    . Pager => (904) 297-6658                 .
    .                                         .
    *.........................................*

Re: Ada vs. C

[Robert Dewar]

The Quelisher said

"When I compiled each of the above here are the file sizes that resulted:
        C ----> 24,576
        Ada --> 253,952"

So what? this does not prove, or even relate to your point, and it is 
certainly complete nonsense to take this observation and deduce from
it that a 6 megabyte Ada program will correspond to a 2 megabyte C program.

Why are the above figures not relevant.

First: the size of an executable file is not related to the size of the
executable program in any simple way. Two factors are of critical importance.
First, are they both stripped or not, I am willing to bet that the Ada
file was not stripped -- so why didn't you strip it to make the comparison.

Second, I would guess the Ada program is statically linked, and the C
program is dynamically linked, meaning that the space for Text_IO is
included in the Ada size you see, and the space for printf is not included
in the C file that you see.


Finally, and most importantly, these are quite different programs, one
uses the package printf, and the oher uses the package Text_IO. Yes, there
is some overlap in capability, but they are definitely not the same package,
and both contain functionality not in the other. 

If you want to persue this, first make sure you understand what stripping
is about, and also what dynamic vs static linking is about, so that these
factors do not make your observations meaningless, and then compare
programs that are comparable!

Re: Ada vs. C

[steved]

The Quelisher <kendal@freenet.scri.fsu.edu> writes:
>Robert Dewar wrote:
>> That's bogus, comparable programs in Ada and C will generate 
>> executables of the same size, at least using a technology like GNAT. 
>
>Ok, so let me explain where I am coming from then. Here is the source in
>both languages that does the exact same very basic thing:
>-----------------------------------------------------------------------
>C :
>	main()
>	{
>		printf("Hello world! \n");
>	}
>
>-----------------------------------------------------------------------
>Ada :
>
>	WITH Ada.Text_IO; USE Ada.Text_IO;
>	PROCEDURE hello IS
>	BEGIN
>	  Put_line("Hello world!");
>	END hello;
>-----------------------------------------------------------------------
>
>When I compiled each of the above here are the file sizes that resulted:
>	C ----> 24,576
>	Ada -->	253,952
>
I think you'll find that if you add another ten lines of code to your example,
the size of the Ada executable will NOT increase proportionally.

Yes, for small app's C will come out smaller.  But for real reasonably sized
app's I think you'll find the sizes to be comparable.

My Opinion,
Steve Doiel
steved@pacifier.com

Re: Ada vs. C

[Robert Dewar]

Here is some realistic data on comparing C and Ada. The programs I 
compared are:

In Ada

procedure f is
   procedure printf (s : string);
   pragma Import (C, printf, "printf");
begin
   printf ("Hello World!");
end f;


In C

#include <stdio.h>
main(int argc, char *argv[], char *envp[])
{
   printf("hello world\n");
}


The stripped executables compiled by gcc are of course identical in
size as one would expect, 24580 bytes in either case.

I used printf in both programs so that they are exactly comparable. Now
of course if you include an additional package in the Ada version, like
GNAT.IO, then you will find that the Ada program gets bigger, it goes
up to 32772 bytes.

The additional 8200 bytes represents not some mysterious Ada inefficiency
but simply the size of this package, since it is linked statically and
not dynamically.

If we use the more complex package Text_IO, then the size gets larger still,
up to 53252 bytes. Once again, the extra 28K bytes simply represents the
size of the Text_IO package. Not surprisingly it is larger than the
simple GNAT.IO package since it has far more capability (it also uses
some of the other Ada library facilities like finalization support).

I can of course (since gcc allows mixed language programming) make a C
program which uses Text_IO facilities, guess how big it is -- that's right
53252 bytes (what a surprise :-)

I suppose these figures may surprise some people, but to me it would
be surprising if comparable C and Ada programs were NOT the same size!

Re: Ada vs. C

[Bob Kitzberger]

The Quelisher (kendal@freenet.scri.fsu.edu) wrote:
: Robert Dewar wrote:
: > That's bogus, comparable programs in Ada and C will generate 
: > executables of the same size, at least using a technology like GNAT. 

[Ada vs. C hello world example]

: When I compiled each of the above here are the file sizes that resulted:
: 	C ----> 24,576
: 	Ada -->	253,952

But these aren't real-world programs.  You'll probably discover that
much of the Ada overhead is fixed -- runtime requirements for tasking
(and you may be able to remove much of that if you don't use
tasking).

: I understand though that there is a tradeoff between file size and
: functionability of a program, but let's take PC's for example. Who wants
: to run a 6 mb program written in Ada when a 2mb program written in C
: does the same thing?

Of course no one wants to.    But basing observations on "hello
world" is silly.  I suspect that if you use the same underlying
back-end technology, the size of the Ada vs. C programs will
increase at roughly the same rate, once you ignore the
fixed-size runtime costs.

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: Ada vs. C

[Dave Wood]

The Quelisher wrote:
> 
> Robert Dewar wrote:
> > That's bogus, comparable programs in Ada and C will generate
> > executables of the same size, at least using a technology like GNAT.
> 
> Ok, so let me explain where I am coming from then. Here is the source in
> both languages that does the exact same very basic thing:
> -----------------------------------------------------------------------
> C :
>         main()
>         {
>                 printf("Hello world! \n");
>         }
> 
> -----------------------------------------------------------------------
> Ada :
> 
>         WITH Ada.Text_IO; USE Ada.Text_IO;
>         PROCEDURE hello IS
>         BEGIN
>           Put_line("Hello world!");
>         END hello;
> -----------------------------------------------------------------------
> 
> When I compiled each of the above here are the file sizes that resulted:
>         C ----> 24,576
>         Ada --> 253,952
> 
> I used gcc to compile the C code and gnatmake for the Ada code, both on
> unix machines. Now that's what I meant by the difference in file sizes.
> I understand though that there is a tradeoff between file size and
> functionability of a program, but let's take PC's for example. Who wants
> to run a 6 mb program written in Ada when a 2mb program written in C
> does the same thing? I'm not trying to knock Ada or anything, rather
> just making an observation. Again, just my $.02
> 

I get the following "hello world" figures on the PC:

Visual C++ 4.2  --------------->  76.0 KB
ObjectAda for Windows v7.0 ---->  89.5 KB

This compares the current VC++ release against the pre-release ObjectAda
compiler, both with debug symbols turned off and no special optimizations.

Not much of a difference, really, especially considering that MS has
had uncounted gazillions of person-years to apply to MSVC compared to
the humble Ada vendor (ahem).

So, I'd have to agree with Robert:  if you're comparing apples and
apples, there's little fundamental reason that an Ada program must
be bigger than a C program.  I don't see where this is a language
issue, as opposed to an implementation issue.

By the way, you forgot to #include <stdio.h> in your C snippet.  :)

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- http://www.thomsoft.com

Re: Ada vs. C

[busigin]

In <320D2677.499F@thomsoft.com>, Dave Wood <dpw@thomsoft.com> writes:
>The Quelisher wrote:
>> 
>> Robert Dewar wrote:
>> > That's bogus, comparable programs in Ada and C will generate
>> > executables of the same size, at least using a technology like GNAT.
>> 
>> Ok, so let me explain where I am coming from then. Here is the source in
>> both languages that does the exact same very basic thing:
>> -----------------------------------------------------------------------
>> C :
>>         main()
>>         {
>>                 printf("Hello world! \n");
>>         }
>> 
>> -----------------------------------------------------------------------
>> Ada :
>> 
>>         WITH Ada.Text_IO; USE Ada.Text_IO;
>>         PROCEDURE hello IS
>>         BEGIN
>>           Put_line("Hello world!");
>>         END hello;
>> -----------------------------------------------------------------------
>> 
>> When I compiled each of the above here are the file sizes that resulted:
>>         C ----> 24,576
>>         Ada --> 253,952
>> 
>> I used gcc to compile the C code and gnatmake for the Ada code, both on
>> unix machines. Now that's what I meant by the difference in file sizes.
>> I understand though that there is a tradeoff between file size and
>> functionability of a program, but let's take PC's for example. Who wants
>> to run a 6 mb program written in Ada when a 2mb program written in C
>> does the same thing? I'm not trying to knock Ada or anything, rather
>> just making an observation. Again, just my $.02
>> 
>
>I get the following "hello world" figures on the PC:
>
>Visual C++ 4.2  --------------->  76.0 KB
>ObjectAda for Windows v7.0 ---->  89.5 KB
>
>This compares the current VC++ release against the pre-release ObjectAda
>compiler, both with debug symbols turned off and no special optimizations.
>
>Not much of a difference, really, especially considering that MS has
>had uncounted gazillions of person-years to apply to MSVC compared to
>the humble Ada vendor (ahem).
>
>So, I'd have to agree with Robert:  if you're comparing apples and
>apples, there's little fundamental reason that an Ada program must
>be bigger than a C program.  I don't see where this is a language
>issue, as opposed to an implementation issue.
>
>By the way, you forgot to #include <stdio.h> in your C snippet.  :)
>
>-- Dave Wood
>-- Product Manager, ObjectAda for Windows
>-- http://www.thomsoft.com

Using GNAT under OS/2, the hello program compiles to
a 262,958 byte executable. When I strip the debug code,
the size goes down to 53,252 bytes. When I run the
LxLite utility program to compress the EXE file, the size
goes down to 31,364 bytes. This file size is certainly not
out of line with C/C++ compilers.

Anthony Busigin
NITEK Corporation

Re: Ada vs. C

[Robert Dewar]

Anthony said

"Using GNAT under OS/2, the hello program compiles to
a 262,958 byte executable. When I strip the debug code,
the size goes down to 53,252 bytes. When I run the
LxLite utility program to compress the EXE file, the size
goes down to 31,364 bytes. This file size is certainly not
out of line with C/C++ compilers.
"

And if you link dynamically instead of staticaly, you can of course
reduce the executable size much further.

Re: Ada vs. C

[Jerry van Dijk]

The Quelisher (kendal@freenet.scri.fsu.edu) wrote:

: Robert Dewar wrote:
: > That's bogus, comparable programs in Ada and C will generate 
: > executables of the same size, at least using a technology like GNAT. 

: 		printf("Hello world! \n");

: 	  Put_line("Hello world!");

: When I compiled each of the above here are the file sizes that resulted:
: 	C ----> 24,576
: 	Ada -->	253,952

To me this looks like comparing a C program using shared libraries to a
statically linked Ada program...

Besides, what do you think you are comparing here ? With only one line
of executable code, the programs mainly consist of the program start-up
code and runtime library. And then I would expect the GNAT executable to
be somewhat larger then the C one, since the GNAT RTL contains more
functionality (like tasking).

If you really want to compare executable file sizes, you should use two 
equivalent programs, large enough to make size of the RTL insignificant
compared to the code size.

But, then, whats the point to it...

P.S. Under DOS a GNAT hello world is about 87K, a gcc one about 57K.
     If I were to use a 16-bit C compiler I would expect a 6K exe size.
     Using an embedded systems compiler would bring that down to about
     500 bytes. If that is still to big, handwritten assembler will
     get away with about 40 bytes.

Re: Ada vs. C

[Vladimir Vukicevic]

dewar@cs.nyu.edu (Robert Dewar) writes:
> 
> Here is some realistic data on comparing C and Ada. The programs I 
> compared are:
>
> [..]
> 
> The stripped executables compiled by gcc are of course identical in
> size as one would expect, 24580 bytes in either case.
> [..]
> I can of course (since gcc allows mixed language programming) make a C
> program which uses Text_IO facilities, guess how big it is -- that's right
> 53252 bytes (what a surprise :-)
> 
> I suppose these figures may surprise some people, but to me it would
> be surprising if comparable C and Ada programs were NOT the same size!

Come on, Robert, you can't really believe that C and Ada programs compile
into the exact same size, no matter how identical they are. They are
very close in size: (f being the ada code, and foo being the C code)

-rw-rw-r--   1 vladimir vladimir      896 Aug 12 15:37 f.o
-rw-rw-r--   1 vladimir vladimir      880 Aug 12 15:38 foo.o

However, when compiled into full apps, the ada code needs to have
gnatbind needs to do various initialization, and only then call
procedure f(). In C, this isn't necessary; as such, the resulting
executable files have the following sizes [stripped, all libraries
shared]:

-rwxrwxr-x   1 vladimir vladimir     6692 Aug 12 15:46 f*
-rwxrwxr-x   1 vladimir vladimir     2436 Aug 12 15:47 foo*

Why the large size discrepancy? Because f is being linked (albeit shared)
with libgnat, libc, libpthread, and libm. foo, on the other hand,
is just being linked shared with libc. f also has the overhead of b_f.c,
whereas foo does not.

This is all rather pointless, actually, since executable file size doesn't
have anything to do with memory requirements of the program or running time
or whatnot. For comparison purposes, here is an equivalent program
in java:

		public class F {
			public static void main (String args[])
			{
				System.out.println ("hello world");
			}
		}

The resulting runnable code size?

-rw-rw-r--   1 vladimir users         407 Aug 12 15:51 F.class

I guess this makes java twice as good as Ada and C :-)

		- Vladimir

--
Vladimir Vukicevic  <vladimir@arp.com>  [std disclaimer here]
 C makes it easy for you to shoot yourself in the foot.  C++ makes that
 harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Re: Ada vs. C

[Jack W Scheible]

In article <3208F2BA.E34@freenet.scri.fsu.edu> kendal@freenet.scri.fsu.edu writes:
>I have found one thing that C has an advantage over Ada : executable
>file sizes. Everything I have programmed in Ada is HUGE compared to a
>program thta does the same thing but written in C.

Disk space is cheap, program maintenance is not.

-jack

Re: Ada vs. C

[Daniel P Hudson]

The Quelisher <kendal@freenet.scri.fsu.edu> wrote:
>I have found one thing that C has an advantage over Ada : executable
>file sizes. Everything I have programmed in Ada is HUGE compared to a
>program thta does the same thing but written in C.

>Just my $.02

 Psst, over here. That's a feature of the COMPILER, not the language.
 Plus, any OO language will compile larger a structured langauge because
 of the overhead OO requires.

 If you don't understand this, let me clarify. Years ago, when Microsofts
 Quick_C 1.0 was still a major sought after item by those trying to learn
 C, I was told by a close-minded friend that I was wasting my time
 writting my programs in Quick_Basic. Besides being the most unintelligent
 statement I had ever heard, after all these were my programs for MY 
 computer and they appeared to be working just fine to me, it was
 a challenge which I accepted. I asked him why and he told me the 
 code was slow and too big. My friend had never even seen a Basic compiler
 so this was his first shock, his second was when QuickBasic 4.5 
 mainly matched QC 1.0 in the final output tests. The language had nothing
 to do with it, the compilers were from the same general time era and
 the company implemented the same technology in both. The library was
 the only that determined which was better, and QB didn't give you the 
 control over FP that QC did, so QC had one advantage. Now, in
 today, most language are equivalent in such tests because compiler
 technology is shared quite freely due to projects like GNU or the
 newsgroup comp.compilers and freely available docs on a variety
 of architectures. However, if you compile these two sources

 /* c */
 #include <stdioh.>

 int main(void)
 {
   printf("Hello, World!\n");
   return 0;
 }

   --------------------------------------------------------------------

 // cpp
 #include <iostream.h>

 int main(void)
 {
   cout << "Hello, World!" << endl;
   return 0;
 }

 I guarentee you that the C code will always come out smaller than the C++
 equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can
 code in a proceedural fashion, the standard libs are designed to be
 used in OO programming and therefore carry the OO overhead. Is this
 a bad thing? Only if you don't feel that an OO approach is the best
 solution to your current task, but it does seem that the CIS community
 is moving toward OOP.

Re: Ada vs. C

[Robert Dewar]

Daniel said

" I guarentee you that the C code will always come out smaller than the C++
 equivalent will, due to OO overhead. Ada uses OO, even thouhgh you can
 code in a proceedural fashion, the standard libs are designed to be
 used in OO programming and therefore carry the OO overhead. Is this
 a bad thing? Only if you don't feel that an OO approach is the best
 solution to your current task, but it does seem that the CIS community
 is moving toward OOP."

I have no idea what this means. The standard libraries consist, at least
in GNAT, of hundreds of separate units, some of which use some features
of OO (not many), most of which do not. There is no inherent OO overhead.
Your guarantee with respect to C and C++ is also completely odd. Indeed
since C++ is largely a subset of C, the typical C++ code that corresponds
to the C code is identical to the C code, and in any reasonable compilation
environment generates exactly the same bits as the C code.

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3f5s92$3id@info.epfl.ch>,
Laurent Gasser <gasser@masg1.epfl.ch> wrote:
>
>The problem is in the language definition, not in the choic of symbols.
>C is one of the rare language I use to allow having an assignment after 
>the if statement.  All other languages only allow for a boolean test.
>
>I never saw a good reason for allowing this.
>

It's a question of who optimizes your code.  In the 60s,
when C was developed, compilers *couldn't* optimize code,
so the programmer had to.  Many apparently-bizarre C
capabilities are there to support optimization level -1
(programmer does the optimizations).

Consider the common C idiom to copy a null-terminated
array, usually a string [syntax may not be quite right]:

     while (*a++=*b++);

Recall that C considers 0 false, a null character is integer
0, and an assignment returns what was assigned.  This loop
condition copies the character at address b to address a,
increments both, and exits when a null was copied.  There is
no statement inside the loop.

This is more efficient, with a non-optimizing compiler, than

  while (*a)
    { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

because
* The operator ++ increments the value of while it's still
  in a register.  The second code reads a from memory to
  do the character assign, reads it again to increment it.

* ++ can use the assembler's increment instruction.  a=a+1
  could not.

* Using the assignment as the loop expression indirectly
  directs the compiler to keep the result of the assignment
  in a register for reuse in the expression, instead
  of writing it to memory, then reading it.

Thus, with a lot of man-hours, expertise and skull-sweat,
someone using a basic C compiler can come within an order
of magnitude of the efficiency of someone using a half-good
optimizing Ada compiler.  Often.

Of course, if you only *read* the code, and don't *run*
it, it looks like the C is more optimized, because you can
*see* the optimizations.

With Ada you write less-optimized-looking code, and trust
the compiler.  (But verify.)

>-- 
>Laurent Gasser (gasser@dma.epfl.ch)
>Computers do not solve problems, they execute solutions.
>
>I know very few ideas worth dying for, none is worth killing.

I dunno, I've killed quite a few ideas in my time :-)

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[David O'Brien]

In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote:
: It's a question of who optimizes your code.  In the 60s,
: when C was developed, compilers *couldn't* optimize code,
: so the programmer had to.  Many apparently-bizarre C
: capabilities are there to support optimization level -1
: (programmer does the optimizations).

C was designed in the 70's.  The earliest reference I could find to it
is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter
Century of Unix".  The language from which C developed, B, was created
in 1970.  And the only published document on the B language, "CSTR #8 -
The Programming Language B", is dated Jan 1973.  BCPL, which B came
from, is from 1969.

So, I think that "compilers *couldn't* optimize code" may be an over
generalization.  Is this _really_ the case for 1970's compiler
technology?

: Consider the common C idiom to copy a null-terminated
: array, usually a string [syntax may not be quite right]:

:      while (*a++=*b++);

I am curious about programming culture.  Notice that when someone writes
something in C they feel they have to remove all white space.  When they
write in Ada they put in plenty and use [very] long names for every
thing.  Why is that???  No wonder people say C is hard to read.


: This is more efficient, with a non-optimizing compiler, than

:   while (*a)
:     { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

: because
: * The operator ++ increments the value of while it's still
:   in a register.  The second code reads a from memory to
:   do the character assign, reads it again to increment it.

You are making a *major* assumption about the CPU this is running on.
On many smaller uP's there isn't that many registers.

: * ++ can use the assembler's increment instruction.  a=a+1
:   could not.

Since adding 1 to variable is so common place, it is trivial to add this
type of optimization (even in your parser).

: * Using the assignment as the loop expression indirectly
:   directs the compiler to keep the result of the assignment
:   in a register for reuse in the expression, instead
:   of writing it to memory, then reading it.

Again, you really are thinking with a preconceived notion of your
hardware.

-- David O'Brien	(dobrien@sea.gwu.edu)

Ada vs. C

[Martijn Bak]

>It all falls out of the design of the language. Constructs like "+="
>provide no benifit other than to save typing within a single
>statement. Take the statement:
>
>  Principle = Principle + (Interest * Time)
>
>The "+=" operator is MADE for this statement, but its ONLY benifit is
>to save me 11 characters in my source file. 

Nope, in general this is _not_ true! The statements
	expr1 += expr2;
and
	expr1 = expr1 + expr2;
are _not_ the same. In the former, expr1 is evaluated only once, in the
latter expr1 is evaluated twice. This is not only a matter of execution
speed. It is especially important if expr1 has side-effects.

There is also a conceptual benefit for the += (if expr1 is very complex).
Compare
	a[i->j(q,b)] = a[i->j(q,b)] + 2;
and
	a[i->j(q,b)] += 2;

In the latter case, neither the writer nor the reader of this code need
to check whether a[i->j(q,b)] and a[i->j(q,b)] realy are the same.

Yep, I _am_ a C programmer.

-- 
-- Martijn Bak -- AND Software -- Westersingel 108, 3015 LD  Rotterdam --
-- tel: +31-10-4367100 -- fax: +31-10-4367110 -- email: martijn@and.nl --