By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,710 Members | 1,328 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,710 IT Pros & Developers. It's quick & easy.

header file question

P: n/a
I've got this small app , from 2 .c files. One file contains the main
and the other file contains functions used in the main. I compile this
using gcc like this: gcc -c *c && gcc -o app *o. But I want to do it in
an other way. I want to use header files I've googled but did not find
anything usefull expect that there should be prototypes in my header
file can anyone help me ?

Nov 13 '05 #1
Share this Question
Share on Google+
36 Replies


P: n/a
On Sat, 15 Nov 2003 11:52:28 +0000, Geiregat Jonas wrote:
I've got this small app , from 2 .c files. One file contains the main
and the other file contains functions used in the main. I compile this
using gcc like this: gcc -c *c && gcc -o app *o. But I want to do it in
an other way. I want to use header files I've googled but did not find
anything usefull expect that there should be prototypes in my header
file can anyone help me ?


It's not clear what you are talking about.
Try this:

gcc -o app *.c
Nov 13 '05 #2

P: n/a
Geiregat Jonas wrote:
I've got this small app , from 2 .c files. One file contains the main
and the other file contains functions used in the main. I compile this
using gcc like this: gcc -c *c && gcc -o app *o. But I want to do it in
an other way. I want to use header files I've googled but did not find
anything usefull expect that there should be prototypes in my header
file can anyone help me ?

I will do a small example.
main.c
------

#include <stdio.h>
#include "calc.h"

int main()
{
int x;
printf("Enter an integer: ");
scanf("%d", &x);
printf("The square of %d is %ld\n", x, square(x));
return (0);
}

calc.h
------
#ifndef CALC_H
#define CALC_H

long square(int);

#endif

calc.c
------
#include "calc.h"

long square(int x)
{
return ((long) x * x);
}

---------
NOTES
notice the quotes when including calc.h because it is in the same
directory as the source file

also, if you've never used preprocessor directives, the "#ifndef
CALC_H" may look confusing. You want this in the header file, though.
It prevents multiple inclusions of that header file. Just change CALC_H
to whatever.. I dont think it matters as long as its the same as the
#define statement below it.

HTH,
Aaron

Nov 13 '05 #3

P: n/a
Look at an article at this link.
It is good simple tutorial on C programming and also there detailed
instructions how to make library at 'libraries' link using gcc
compiler. (I've done that and it worked).

http://computer.howstuffworks.com/c.htm
tuchka
Nov 13 '05 #4

P: n/a
tuchka wrote:
Look at an article at this link.
It is good simple tutorial on C programming and also there detailed
instructions how to make library at 'libraries' link using gcc
compiler. (I've done that and it worked).

http://computer.howstuffworks.com/c.htm


The first incorrect statement I spotted was at

http://computer.howstuffworks.com/c1.htm

Here it is:

"C is what is called a compiled language. This means that once you write
your C program, you must run it through a C compiler to turn your program
into an executable that the computer can run (execute)."

The second, related error:

"...to write and run a C program, you must have access to a C compiler."

The third error:

"When you enter this program, position #include so that the pound sign is in
column 1 (the far left side). Otherwise, the spacing and indentation can be
any way you like it."

Counter-example:

#include<stdio.h>intmain(){p r i n t f("This is output from my first
program!\ n"); return0;}

When Mr Brain has fixed those errors, I'll find some more for him to do.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #5

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:
tuchka wrote:
Look at an article at this link.
It is good simple tutorial on C programming and also there detailed
instructions how to make library at 'libraries' link using gcc
compiler. (I've done that and it worked).

http://computer.howstuffworks.com/c.htm
The first incorrect statement I spotted was at http://computer.howstuffworks.com/c1.htm Here it is: "C is what is called a compiled language. This means that once you write
your C program, you must run it through a C compiler to turn your program
into an executable that the computer can run (execute)."
I don't see how that statement is incorrect.
The second, related error: "...to write and run a C program, you must have access to a C compiler."
Hmm, I can see two ways to parse that as erroneous.
1) If writing a program merely consists of writing the source code,
you don't need a compiler.
2) You don't need *any* programming tools to run programs.
But does "to write and run a C program" mean "to write a C program
and then to run the same C program" or "to write a C program, and
to run (possibly another) C program"?

(snip third error)
When Mr Brain has fixed those errors, I'll find some more for him to do.


--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You can pick your friends, you can pick your nose, but you can't pick your
relatives."
- MAD Magazine
Nov 13 '05 #6

P: n/a
Joona I Palaste wrote:
Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following:
The first incorrect statement I spotted was at

http://computer.howstuffworks.com/c1.htm

Here it is:

"C is what is called a compiled language. This means that once you write
your C program, you must run it through a C compiler to turn your program
into an executable that the computer can run (execute)."


I don't see how that statement is incorrect.


http://eic.sourceforge.net/ is one of several counter-examples.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #7

P: n/a
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.


This is most excellent ;) I didn't know they had C interpreters now.. heh.

Nov 13 '05 #8

P: n/a
In <t%**********************@twister.tampabay.rr.co m> Aaron Walker <ka*****@REMOVETHIScfl.rr.com> writes:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.


This is most excellent ;) I didn't know they had C interpreters now.. heh.


They've been around for quite a while.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #9

P: n/a
Aaron Walker wrote:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.


This is most excellent ;) I didn't know they had C interpreters now.. heh.


The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #10

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:
Aaron Walker wrote:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.

This is most excellent ;) I didn't know they had C interpreters now.. heh.

The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)


Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?
Should I ask at comp.programming?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Nov 13 '05 #11

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?


In my limited experience with JavaScript (which is interpreted, yes?),
it seems to be dollars to dougnuts that any reported error messages
won't have a great deal to do with the actual error. Miss a
punctuation mark and you'll get one error in some bizarre place. At
least C will yell at you in a number of places, one of which is in the
ballpark of the actual error.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #12

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> spoke thus:
http://eic.sourceforge.net/ is one of several counter-examples.


I suppose this accepts a superset of ISO C?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #13

P: n/a
On Tue, 18 Nov 2003 20:28:15 +0000 (UTC), in comp.lang.c , Christopher
Benson-Manica <at***@nospam.cyberspace.org> wrote:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?
In my limited experience with JavaScript (which is interpreted, yes?),
it seems to be dollars to dougnuts that any reported error messages
won't have a great deal to do with the actual error. Miss a
punctuation mark and you'll get one error in some bizarre place.


hmm, sounds familiar - a bit like when in C you miss off a brace in a
header and get an "unexpected end of file" message from some random
place? :-)
At
least C will yell at you in a number of places, one of which is in the
ballpark of the actual error.


err.... :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #14

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bp**********@oravannahka.helsinki.fi>...
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:
Aaron Walker wrote:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.
This is most excellent ;) I didn't know they had C interpreters now.. heh.

The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)


Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?


Sure it is, see scheme/lisp for an example. karl m
Nov 13 '05 #15

P: n/a
Christopher Benson-Manica wrote:
Richard Heathfield <do******@address.co.uk.invalid> spoke thus:
http://eic.sourceforge.net/ is one of several counter-examples.


I suppose this accepts a superset of ISO C?


I haven't the faintest idea. I've never actually used it. I only know of its
existence, that's all. (Feel free to investigate and report back!)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #16

P: n/a
In <bp**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Aaron Walker wrote:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.


This is most excellent ;) I didn't know they had C interpreters now.. heh.


The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)


Are you sure it was not an incremental compiler? HiSoft C for the ZX
spectrum certainly was: you could type source code directly to the
compiler, but it wouldn't be executed until you typed the eof key and
the compiler finished the translation process.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #17

P: n/a
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:
Aaron Walker wrote:
Richard Heathfield wrote:

http://eic.sourceforge.net/ is one of several counter-examples.
This is most excellent ;) I didn't know they had C interpreters now.. heh.
The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)


Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler.


Are there? QBASIC (or was it QB?) was a compiler that created very
nicely the illusion of a BASIC interpreter on MSDOS.
I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?
It certainly is. Include an interpreter in the run-time and give it
access to the program's symbol tables. To a limited extent, this is
what most high level debuggers do when evaluating an expression.
Are there any things compilers can do that interpreters can't?
Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".
I'm fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?


No.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #18

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?


In my limited experience with JavaScript (which is interpreted, yes?),
it seems to be dollars to dougnuts that any reported error messages
won't have a great deal to do with the actual error. Miss a
punctuation mark and you'll get one error in some bizarre place. At
least C will yell at you in a number of places, one of which is in the
ballpark of the actual error.


This can easily be done by an interpreter. Many don't, perhaps, but that
doesn't make a syntax check before running impossible.

Richard
Nov 13 '05 #19

P: n/a
Mark McIntyre <ma**********@spamcop.net> spoke thus:
At
least C will yell at you in a number of places, one of which is in the
ballpark of the actual error.
err.... :-)


Well, at least when you leave off a quote in C, the compiler is sure
to be upset - "Line 666: Unterminated string constant", and lo, on
line 666 will be an unterminated string. In Javascript, however, do
the same thing and you're likely to see something like "Line
123456789: Unterminated string constant" which, coincidentally, has
nothing to do with the *real* unterminated string constant on line
666. No, I don't get frustrated easily ;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 13 '05 #20

P: n/a
In <bp**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:
Mark McIntyre <ma**********@spamcop.net> spoke thus:
At
least C will yell at you in a number of places, one of which is in the
ballpark of the actual error.

err.... :-)


Well, at least when you leave off a quote in C, the compiler is sure
to be upset - "Line 666: Unterminated string constant", and lo, on
line 666 will be an unterminated string. In Javascript, however, do
the same thing and you're likely to see something like "Line
123456789: Unterminated string constant" which, coincidentally, has
nothing to do with the *real* unterminated string constant on line
666. No, I don't get frustrated easily ;)


This is not an interpreted vs compiled issue, but rather a string literal
definition issue. If Javascript used C's conventions for string literals
it could diagnose the unterminated string literal on the very line it
occurred.

Leave a C comment unterminated or generate a brace mismatch and the C
compiler's behaviour is no better than the Javascript interpreter's.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #21

P: n/a
Dan Pop wrote:
In <bp**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
The first time I used a C interpreter was in 1989. (HiSoft C for the Atari
ST.)


Are you sure it was not an incremental compiler?


Yes.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #22

P: n/a
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Are there any things compilers can do that interpreters can't?


Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".


Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.

karl m
Nov 13 '05 #23

P: n/a
In <7f**************************@posting.google.com > ka****@acm.org (karl malbrain) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

>Are there any things compilers can do that interpreters can't?


Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".


Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.


If you think that this is a counterargument to my statement, you're
a genuine idiot.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #24

P: n/a
On Wed, 19 Nov 2003 12:32:06 -0800, karl malbrain wrote:
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

>Are there any things compilers can do that interpreters can't?


Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".


Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.


It might even be the most useless.

Nov 13 '05 #25

P: n/a
Dan Pop <Da*****@cern.ch> scribbled the following:
In <7f**************************@posting.google.com > ka****@acm.org (karl malbrain) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
>Are there any things compilers can do that interpreters can't?

Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".
Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.

If you think that this is a counterargument to my statement, you're
a genuine idiot.


Dan, you're calling Karl Malbrain a genuine idiot? That's like calling
the Earth round, or the sky blue, or the grass green. There's no need
to state the obvious.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner
Nov 13 '05 #26

P: n/a
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <7f**************************@posting.google.com > ka****@acm.org (karl malbrain) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:Are there any things compilers can do that interpreters can't?

Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".


Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.


If you think that this is a counterargument to my statement, you're
a genuine idiot.


Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."

Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m
Nov 13 '05 #27

P: n/a
Joona I Palaste wrote:

(snip)
Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?
Are there any things compilers can do that interpreters can't?


(snip)

It is pretty rare to find a pure interpreter or pure compiler. At least
some people consider calling library routines means it is not a pure
compiler.

Most interpreters compile to an intermediate code that is at least
slightly easier to interpret than the original text. Keywords are
identified, for instance. Many will do syntax checking on the whole
program to avoid errors at run time that could easily be detected,
normally a compiler feature. I have seen interpreters that let you
modify the source while the program is running.

With sufficiently strict definition of interpreter, compilers can
generate cross reference listings, storage maps, and optimizations that
require analysis of the whole program unit. I know one Fortran 66
compiler where the optimizer can deduce the nesting structure that a
structured programming language would make explicit. With this level of
optimization, it can print a source listing with the appropriate
indentation to match the nesting levels.

Some of these one might say that an interpreter could do, but in that
case I would say that it is not an interpreter anymore. The name
incremental compiler is sometimes used for processors with some features
of both interpreter and compiler.

-- glen

Nov 13 '05 #28

P: n/a
In <7f************************@posting.google.com> ka****@acm.org (karl malbrain) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
In <7f**************************@posting.google.com > ka****@acm.org (karl malbrain) writes:
>Da*****@cern.ch (Dan Pop) wrote in message news:<bp***********@sunnews.cern.ch>...
>> In <bp**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

>> >Are there any things compilers can do that interpreters can't?
>>
>> Make your program run as fast as possible ;-) Genuine interpreters really
>> suck in terms of program execution speed. That's why code generation on
>> the fly is a technique more and more popular with interpreters. You
>> should be familiar with just-in-time Java bytecode "interpreters".
>
>Complete nonsense. Our tax preparation program is implemented
>completely in an interpreted language and is the fastest in the
>business. It's also the smallest.


If you think that this is a counterargument to my statement, you're
a genuine idiot.


Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."

Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m


Yeah, it seems that Joona was right about you...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #29

P: n/a
In <xFivb.202330$ao4.717314@attbi_s51> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
It is pretty rare to find a pure interpreter or pure compiler.
Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.
At least
some people consider calling library routines means it is not a pure
compiler.


That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #30

P: n/a
On 21 Nov 2003 13:42:43 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <xFivb.202330$ao4.717314@attbi_s51> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
It is pretty rare to find a pure interpreter or pure compiler.


Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.
At least
some people consider calling library routines means it is not a pure
compiler.


That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?


Perhaps what Glen was referring to, or a better example, is printf and

friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.

Oz
Nov 13 '05 #31

P: n/a
On 18 Nov 2003 18:38:09 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote:
<snip>
Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. <snip>
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?
Actually I would say any given functionality that can be implemented
both places is easier, or at least simpler, in an interpreter, since
it has strictly more information available about the program(s).

Compiled code almost always runs faster than interpreted, usually much
faster; this is a difference of degree rather than kind, although it
may have a qualitative effect -- classic number-crunching example: if
it takes 1.5 days to run a 1-day weather prediction it's useless, but
0.5 days becomes valuable. More generally, the interpreter also has
some overhead for things like file opens and buffers, etc., so at the
margins on a given machine compiled code can run problems/inputs
slightly larger by various measures than interpreted. OTOH on most
architectures compiled code is larger than source, so an interpreter
can probably load (at all, or with less swapping) a larger program.
(Although I guess you could claim conversely that compiled code
exercises VM/swapping mechanisms more extensively. <G>)

A compiler can in most cases, unless deliberately restricted by
licensing or configuration, produce a program that runs on another
machine or many other machines (without special software installed)
and for a cross-compiler even on a different type of machine. Compiled
code can be distributed without source, which except for obfuscated or
just really awful source makes it significantly harder though not
impossible to read and/or understand.

You can usually combine object code compiled from multiple languages
into a single executable, while it is at least very hard for two or
more interpreters to work together so closely; a single interpreter
can usually(?) call (pre)compiled code from other languages, but it is
often(?) more difficult to provide an interpreted entry or callback
that can be called *from* other-language code.
Should I ask at comp.programming?


Don't know.

- David.Thompson1 at worldnet.att.net
Nov 13 '05 #32

P: n/a
On 20 Nov 2003 12:16:14 -0800
ka****@acm.org (karl malbrain) wrote:
Da*****@cern.ch (Dan Pop) wrote in message
news:<bp***********@sunnews.cern.ch>...
In <7f**************************@posting.google.com > ka****@acm.org
(karl malbrain) writes:
Da*****@cern.ch (Dan Pop) wrote in message
news:<bp***********@sunnews.cern.ch>...> In
<bp**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:
> >Are there any things compilers can do that interpreters can't?
>
> Make your program run as fast as possible ;-) Genuine
> interpreters really suck in terms of program execution speed.
> That's why code generation on the fly is a technique more and
> more popular with interpreters. You should be familiar with
> just-in-time Java bytecode "interpreters".

Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.


If you think that this is a counterargument to my statement, you're
a genuine idiot.


Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."


Walking completely sucks in terms of speed (you can't even go 30MPH).
However, it is still fast enough for a lot of things.
Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m


That just proves that there is nothing better not that yours is any
good.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #33

P: n/a
ozbear wrote:
On 21 Nov 2003 13:42:43 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <xFivb.202330$ao4.717314@attbi_s51> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
It is pretty rare to find a pure interpreter or pure compiler.
Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.
Some that I know of wouldn't even let you enter an invalid statement.
Others would tokenize the statement, though it might not have made any
sense as a BASIC statement. Then there was one that would let you enter
expressions, even using variables, for the BASIC INPUT statement. That
is a pretty wide range.

Command interpreters such as unix shells or DOS COMMAND.COM running
batch files are about as pure as I can think of. I don't think I ever
completely understood it, but once I modified a csh script while it was
running a loop, and the new change took effect immediately, without
crashing the loop.
At least some people consider calling library routines
means it is not a pure compiler.
That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?


That is what CS people would tell me. It took me a while to believe it,
but after a while it seems to make sense.
Perhaps what Glen was referring to, or a better example, is printf and
friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.


This is a more obvious example. I am always surprised when compilers
issue warnings from printf format strings. I expect it to be
interpreted only at run time, and if a variable is supplied it must be.

I agree that the floating point case is questionable, but I think it is
even true in that case.

I did once know of people who built a microcoded machine to execute
S/370 code. They "compiled" the S/370 code into microcode, instead of
interpreting it in microcode as is usually done. Most likely it
generated "tons of microcode" for floating point operations, though it
might be that they didn't need so many floating point operations.

So maybe I would call the compiled code that generates calls for
floating point 99% compiled and 1% interpreted. That doesn't seem so
bad to me.

Consider, though, what some have done in the past for floating point,
which is to either insert interrupt instructions or process the trap for
a non existent instruction, and then interpret that floating point
operation.

-- glen

Nov 13 '05 #34

P: n/a
Mark Gordon <sp******@flash-gordon.me.uk> wrote in message news:<20031123151523.65fc18bf.sp******@flash-gordon.me.uk>...
On 20 Nov 2003 12:16:14 -0800
ka****@acm.org (karl malbrain) wrote:
Da*****@cern.ch (Dan Pop) wrote in message
news:<bp***********@sunnews.cern.ch>...
In <7f**************************@posting.google.com > ka****@acm.org
(karl malbrain) writes:

>Da*****@cern.ch (Dan Pop) wrote in message
>news:<bp***********@sunnews.cern.ch>...> In
><bp**********@oravannahka.helsinki.fi> Joona I Palaste
><pa*****@cc.helsinki.fi> writes:> >Are there any things compilers can do that interpreters can't?
>>
>> Make your program run as fast as possible ;-) Genuine
>> interpreters really suck in terms of program execution speed.
>> That's why code generation on the fly is a technique more and
>> more popular with interpreters. You should be familiar with
>> just-in-time Java bytecode "interpreters".
>
>Complete nonsense. Our tax preparation program is implemented
>completely in an interpreted language and is the fastest in the
>business. It's also the smallest.

If you think that this is a counterargument to my statement, you're
a genuine idiot.


Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."


Walking completely sucks in terms of speed (you can't even go 30MPH).
However, it is still fast enough for a lot of things.


No it doesn't suck. It depends on the conditions: how and where it is
specified. It's still best in most transport applications.
Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m


That just proves that there is nothing better not that yours is any
good.


Yeah, I guess I should have spelled it out: the other packages being
compared are all compiled C and C++ applications. It's the
ORGANIZATION of the code and its function compositions, not whether
it's compiled or intrepreted, that determines whether it "sucks" or
not. karl m
Nov 13 '05 #35

P: n/a
In <3fbe832c.48674593@news-server> oz*****@yahoo.com (ozbear) writes:
On 21 Nov 2003 13:42:43 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <xFivb.202330$ao4.717314@attbi_s51> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
It is pretty rare to find a pure interpreter or pure compiler.


Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.
At least
some people consider calling library routines means it is not a pure
compiler.


That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?


Perhaps what Glen was referring to, or a better example, is printf and

friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.


Glen was talking about *compilers*, while this is a language library
issue.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #36

P: n/a
Dan Pop wrote:
In <3fbe832c.48674593@news-server> oz*****@yahoo.com (ozbear) writes:
(snip)
Perhaps what Glen was referring to, or a better example, is printf and

friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.

Glen was talking about *compilers*, while this is a language library
issue.


Well, it is close enough. There have been discussions here before about
the separation, or lack thereof, between the language and the library.

You could consider the Fortran formatted READ and WRITE statements which
are not written as function calls, but are always (that I know of)
implemented as function calls. The Fortran exponentiation operator is
also usually implemented as a function call. Fortran Complex
arithmetic operators, even on machines that do have floating point
hardware, are sometimes function calls. (Do any machines implement
complex arithmetic in hardware?)

It did take me a while to be convinced, and I agree that floating point
is one of the least obvious examples.

-- glen

Nov 13 '05 #37

This discussion thread is closed

Replies have been disabled for this discussion.