functions

[Uno]

My C references spend most of their time on my dashboard.

Lately, I come back to functions. I have had little time to read
extensively, as acting is not a spectator sport for me. But, every now
and then, I get 60 seconds to read about C.

I wonder what the most-important C functions are in decreasing order.

I think you have to begin with fprintf, but once you say that, you
include printf.

Then I think you need to say malloc().

My question is this:

What do you think C's most-important functions are?

Tjas,

 

[Eric Sosman]

My C references spend most of their time on my dashboard.

Lately, I come back to functions. I have had little time to read
extensively, as acting is not a spectator sport for me. But, every now
and then, I get 60 seconds to read about C.

I wonder what the most-important C functions are in decreasing order.

I think you have to begin with fprintf, but once you say that, you
include printf.

Then I think you need to say malloc().

My question is this:

What do you think C's most-important functions are?

You're an actor? Something I've always wanted to know: What
are the most important lines in a role, in decreasing order? In
what's probably the most famous role of all there's that "to be"
thing, but once you say that you've got to finish the soliloquy
and the rest of it is boring, don't you think?

What do you think acting's most important lines are?

"Frankly, my dear, I don't give a damn," perhaps?

 

[Nick Keighley]

My C references spend most of their time on my dashboard.

Lately, I come back to functions.  I have had little time to read
extensively, as acting is not a spectator sport for me.  But, every now
and then, I get 60 seconds to read about C.

I wonder what the most-important C functions are in decreasing order.

I think you have to begin with fprintf, but once you say that, you
include printf.

Then I think you need to say malloc().

My question is this:

What do you think C's most-important functions are?

I don't think the question is too meaningful. K&R tackles the
different aspects of C in a fairly logical way.

 

[Vincenzo Mercuri]

Il 16/06/2010 11:40, Uno ha scritto:

My C references spend most of their time on my dashboard.

Lately, I come back to functions. I have had little time to read
extensively, as acting is not a spectator sport for me. But, every now
and then, I get 60 seconds to read about C.

I wonder what the most-important C functions are in decreasing order.

I think you have to begin with fprintf, but once you say that, you
include printf.

Then I think you need to say malloc().

My question is this:

What do you think C's most-important functions are?

Tjas,

"To C, or not to C: that is the question."

Anyway, the problem is that there is not the most important thing of the
C language. C is the most important thing. Here at least.

K&R second edition and King's "C Programming: A Modern Approach", 2nd
edition, are a must.

Hope you'll find them helpful,

Hamlet

 

[Malcolm McLean]

My C references spend most of their time on my dashboard.

Lately, I come back to functions.  I have had little time to read
extensively, as acting is not a spectator sport for me.  But, every now
and then, I get 60 seconds to read about C.

I wonder what the most-important C functions are in decreasing order.

I distinguish "functions" from "procedures". In this terminology (the
terms are also used in other ways) a "function" is something that maps
a set of input data to a set of output data, whilst a "procedure" is
somethign that carries out an action, that is, does IO.

All useful programs will need both functions and procedures. A
procedure can call a function, but a function can't call a procedure.
All functions* can be built with C's operator set and flow control
instructions, and malloc()/free(). So malloc() and free() are special
functions.

ANSI C doesn't provide much in the way of support for procedures, just
opening and closing files, reading and writing from and to them, and a
small amount of file read position manipulation. All the IO functions
can be built on top of fopen(), fclose() fputc() and fgetc(), with the
exception of a few oddballs like time(). However normally the platform
will provide a library of non-standard procedures, allowing yopu to do
everythign from drawing pixels on the screen to manipulating an
attached robot.

(*) variable argument list functions are a technical exception.

 

[Ben Bacarisse]

On Jun 16, 12:40 pm, Uno <[email protected]> wrote:
I distinguish "functions" from "procedures". In this terminology (the
terms are also used in other ways) a "function" is something that maps
a set of input data to a set of output data, whilst a "procedure" is
somethign that carries out an action, that is, does IO.

All useful programs will need both functions and procedures. A
procedure can call a function, but a function can't call a procedure.
All functions* can be built with C's operator set and flow control
instructions, and malloc()/free(). So malloc() and free() are special
functions.

(*) variable argument list functions are a technical exception.

I think some of the floating point functions can't be built using C's
operators and flow control. For example, fma and the nextafter family.
If you include function-like macros, the FP comparison and
classification macros are probably also in this category.

 

[Keith Thompson]

What do you think C's most-important functions are?

The most important C function is the one you need at the moment.

 

[Wolfgang.Draxinger]

I distinguish "functions" from "procedures". In this terminology (the
terms are also used in other ways) a "function" is something that maps
a set of input data to a set of output data, whilst a "procedure" is
somethign that carries out an action, that is, does IO.

If you really want to get mathematical, then there are only functions
forming the set of functions F. We define the subset P of F, where
every element in P is a function which maps to the empty set and call
elements of this set procedures.

Thus by talking about elements of F (functions) you include the subset P
(procedures). So the distinction procedure/function is purely
artificial and gains nothing.

Just my 2 cents.

 

[Willem]

Wolfgang.Draxinger wrote:
) On Wed, 16 Jun 2010 08:09:03 -0700 (PDT)
)
)> I distinguish "functions" from "procedures". In this terminology (the
)> terms are also used in other ways) a "function" is something that maps
)> a set of input data to a set of output data, whilst a "procedure" is
)> somethign that carries out an action, that is, does IO.
)
) If you really want to get mathematical, then there are only functions
) forming the set of functions F. We define the subset P of F, where
) every element in P is a function which maps to the empty set and call
) elements of this set procedures.
)
) Thus by talking about elements of F (functions) you include the subset P
) (procedures). So the distinction procedure/function is purely
) artificial and gains nothing.
)
) Just my 2 cents.

You've got it backwards. Two words: side effects.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Nobody]

I wonder what the most-important C functions are in decreasing order.

None of the functions are important. If they were, freestanding
implementations wouldn't be of any use.

I think you have to begin with fprintf, but once you say that, you
include printf.

Neither printf() nor fprintf() are of any use on systems which lack files.
Such systems exist, are useful, and are often programmed in C.

Even on systems which do have files, fprintf() etc are often only useful
if you're willing to specify the behaviour of the program to accomodate
fprintf() etc. IOW, if the behaviour of fprintf() etc isn't exactly what
you want, do you just accept whatever fprintf() does, or implement
something which behaves as you would prefer?

A common reason for avoiding *printf() is that the behaviour depends upon
the current locale, and C's locale mechanism is often too crude for
programs which need "real" internationalisation.

Then I think you need to say malloc().

malloc() etc are only useful if you don't have to worry about heap
fragmentation, swapping behaviour, etc. More advanced allocators support
allocations from specific memory pools, specification of the access
pattern, relocation of allocated blocks, etc.

And sometimes, you just have to lay out the entire memory map by hand.

My question is this:

What do you think C's most-important functions are?

I'd be hard pressed to think of an environment where memcpy() wouldn't be
useful. I'm not sure the same can be said about any other standard
function.

 

[Keith Thompson]

None of the functions are important. If they were, freestanding
implementations wouldn't be of any use.

You seem to be using an unusual definition of the word "important".
It's not a synonym for "universally available".

[...]

 

[Nobody]

You seem to be using an unusual definition of the word "important".
It's not a synonym for "universally available".

It's not strictly a synonym for "essential" either, but that was what I
was getting at.

Interpreting "important" as "useful" is too subjective to be a useful
definition.

 

[Keith Thompson]

It's not strictly a synonym for "essential" either, but that was what I
was getting at.

Interpreting "important" as "useful" is too subjective to be a useful
definition.

I'd say that "important" and "useful" are equally subjective (which
means that the OP's question isn't really answerable).

 

[Peter Nilsson]

I wonder what the most-important C functions are in decreasing
order.

main
fputc

Others are useful, but not critical (to my needs.)

 

[Nick Keighley]

I distinguish "functions" from "procedures".

but C doesn't. And I'm not sure the distinction is very useful in this
case.

In this terminology (the
terms are also used in other ways) a "function" is something that maps
a set of input data to a set of output data, whilst a "procedure" is
somethign that carries out an action, that is, does IO.

this seems a rather non-standard definition. I thought a procedure was
something with side effects and function was without side effects.

All useful programs will need both functions and procedures. A
procedure can call a function, but a function can't call a procedure.
All functions* can be built with C's operator set and flow control
instructions, and malloc()/free(). So malloc() and free() are special
functions.

setjmp/longjmp, exit/abort, getenv, system, stdarg.h (technically they
are macros), time.h, maybe signal.h

ANSI C doesn't provide much in the way of support for procedures, just
opening and closing files, reading and writing from and to them, and a
small amount of file read position manipulation.

what else do you want?

All the IO functions
can be built on top of fopen(), fclose() fputc() and fgetc(), with the
exception of a few oddballs like time(). However normally the platform
will provide a library of non-standard procedures, allowing yopu to do
everythign from drawing pixels on the screen to manipulating an
attached robot.

they seem to have missed out the robot manipulation library on my
machine

(*) variable argument list functions are a technical exception.

what does the word "technical" add?


--

Egon: Don't cross the streams.
Venkman: Why?
Egon: It would be bad.
Venkman: I'm fuzzy on the whole good-bad thing. Whattya mean "bad?"
Egon: Try to imagine all life as you know it stopping instantaneously
and every molecule in your body exploding at the speed of light.
Ray: Total protonic reversal....
Venkman: Right, that's bad...OK.. important safety tip. Thanks, Egon.
(Ghost Busters)

 

[Malcolm McLean]

but C doesn't. And I'm not sure the distinction is very useful in this
case.

In a sense it does. All functions (except the variable argument list
ones) can be written in standard C using no subroutines except
malloc() and free(). No procedure can be so written.

this seems a rather non-standard definition. I thought a procedure was
something with side effects and function was without side effects.

It's a slight twist on the standrad definition. In my definition, a
function shuffles about bits in the computer's memory, a procedure
performs IO.

setjmp/longjmp, exit/abort, getenv, system, stdarg.h (technically they
are macros), time.h, maybe signal.h

These are all procedures, except for stdarg. Ypu can argue about
whether flow control functions should really be called procedures -
really these should be keywords in the language.

what does the word "technical" add?

Because the technology of the compiler creates the special situation.
There's nothing special or inherent in sprintf() that means it can't
be written using just language keywords, and is therefore not a
"function". It's just a quirk of they way C builds argument lists.

 

[Nick Keighley]

On Jun 17, 10:39 am, Nick Keighley <[email protected]>



In a sense it does.

we'll have to agree to disagree

All functions (except the variable argument list
ones)

and all the other exceptions I listed

can be written in standard C using no subroutines except
malloc() and free(). No procedure can be so written.

just add getc and putc to your list and they can be written as well

It's a slight twist on the standrad definition. In my definition, a
function shuffles about bits in the computer's memory, a procedure
performs IO.



These are all procedures, except for stdarg.

but none of them do i/o so they aren't procedures by your own
definition! If you say getenv is i/o then I'll ask how you write it in
terms of the i/o primitives you specified.

Ypu can argue about
whether flow control functions should really be called procedures -
really these should be keywords in the language.

probably. I'm just makin the point that there's quite a bit of
compiler supported magic in the C library (though less than most
languages). Even malloc/free could have been language words (consider C
++'s new and delete). It would be stretching things a bit to make getc
and putc language words though...

Because the technology of the compiler creates the special situation.
There's nothing special or inherent in sprintf() that means it can't
be written using just language keywords, and is therefore not a
"function". It's just a quirk of they way C builds argument lists.

"in the early days everyone knew how Dennis Ritchie's compiler
constucted the argument list so a varargs function was simply an
excercise in pointer manipulation"
"The Standard C Library" PJPlauger

[apologies if I've misrememberd the quote]

 

[Malcolm McLean]

but none of them do i/o so they aren't procedures by your own
definition! If you say getenv is i/o then I'll ask how you write it in
terms of the i/o primitives you specified.

With time() it depends whether you regard the clock as part of the
computer or not. Same with the other routines.

When I say a procedure does IO, I'm simplifying. We wouldn't need a
special term otherwise, we could just say IO. A procedure does
something, a function shuffles bits. Or in other words, a function can
be implemented by a universal Turing machine, a procedure can't be.

 

[Keith Thompson]

I distinguish "functions" from "procedures". In this terminology (the
terms are also used in other ways) a "function" is something that maps
a set of input data to a set of output data, whilst a "procedure" is
somethign that carries out an action, that is, does IO.

As others have pointed out, C doesn't make this distinction. (No, it
really doesn't.)

Languages like Pascal and Ada that do distinguish between procedures
and functions usually don't make the same distinction you're making.
For example, a Pascal procedure is equivalent to a C void function,
and a Pascal procedure is equivalent to a C function that returns
something other than void. A Pascal function can perform I/O or
modify globals. I think it can also take modifiable parameters.

I think what you're referring to as "functions" are what I'd call
"pure functions". A pure function is one that has no (visible?) side
effects, that receives information only through its arguments,
and that sends data only through its return value.

[snip]

 

[Keith Thompson]

[...]
I think what you're referring to as "functions" are what I'd call
"pure functions". A pure function is one that has no (visible?) side
effects, that receives information only through its arguments,
and that sends data only through its return value.

Given the existence of `errno', I think one could argue that
no Standard library function is guaranteed "pure." Corollary: No
user-written function that calls a Standard library function,
directly or indirectly, can be guaranteed "pure."

In other words, I think your description of "pure function" is
too restrictive for C. However, I also feel that there's not much
point in assessing the purity of a C function; it's simply not a
matter C needs to worry about.

Optimizing compilers can take advantage of a given function being
"pure"; two or more calls to the same pure function with the same
argument values can be reduced to one. The possibility of setting
errno can make this a bit more difficult for standard library
functions, though two calls to sqrt(2.0) can still be collapsed
to one (or even to none).