functions

U

Uno

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

Well, I intend to answer it for myself. Since value is agent-relative,
one would think that many aspects of such a list depend on the
person-programmer.

I was thinking that I would put them on index cards and then set them in
a recipe box. I would put the function in prototype form on the front
and maybe a useful source snippet on the back.

Keith, what functions are mentioned in the standard with its exposition?
These certainly have to be more important than most others.
 
U

Uno

pete said:
For programs on hosted implementations,
the most important function is main.

Absolutely.

If you were going to put a small amount of source on the back of an
index card to illustrate this function, what would it be?

Your C idioms are nothing short of beautiful, btw.
 
U

Uno

Vincenzo said:
"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,

I'm always looking for my next C reference. I've never heard of King.
Do you possess the book?
 
M

Malcolm McLean

     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.
You can make a function into a pure function simply by passing a
parameter called "globals" to every function. This of course gains you
absolutely nothing in software engineering terms (some compilers do so
under the hood).

So the important distinction is between those that shuffle bits, and
those that perform actions.
 
V

Vincenzo Mercuri

Il 18/06/2010 04:57, Uno ha scritto:
I'm always looking for my next C reference. I've never heard of King. Do
you possess the book?

Hi,
yes i do possess it and i've read it from cover to cover.
I'll be honest with you. I'm far from being an expert
of the C language, but i ask you to trust me if i suggest you
that book. The "C programming: a modern approach", 2nd edition,
gives you the skills to start doing a good programming in C.
It also covers the C99 features.
Read a lot about C and above all, always refer to the ISO Standard
as your 100% trustworthy guide:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

That said, before going into too technical details, here are the
most suggested books about C:

1)The C Programming Language, 2nd Edition, by Kernighan and Ritchie
2)C Programming: A Modern Approach, 2nd Edition, by K. King
3)C: A Reference Manual, 5th Edition, by Harbison and Steele
4)The Standard C Library, by P.J.Plauger
5)C Programming FAQ, by Steve Summit
(in part made available online at http://c-faq.com/ )
6)C Traps and Pitfalls, by Andrew Koenig
7)Expert C Programming: Deep C Secrets, by Peter van der Linden
8)The C Puzzle Book, 2nd Edition, by Feuer

i also really suggest this one (unique in its genre):

9)C Interfaces and Implementations: Techniques for Creating Reusable
Software, by Hanson

I possess these books and i can tell you they are one of the most
important thing in my life ;-)

Cheers
 
E

Eric Sosman

Absolutely.

If you were going to put a small amount of source on the back of an
index card to illustrate this function, what would it be?

Taking a hint from another poster, I'd write

#include "defines.h"
#include S
I M(V){P("Hello, world!\n");R 0;}

W C B simpler?
 
N

Nick Keighley

You can make a function into a pure function simply by passing a
parameter called "globals" to every function.

not if it wrote to "globals". Because then it would have Side Effects
and would no longer be a pure function.

This of course gains you
absolutely nothing in software engineering terms (some compilers do so
under the hood).
C++?

So the important distinction is between those that shuffle bits, and
those that perform actions.

your slowly drifing towards the standard definition
 
K

Keith Thompson

Nick Keighley said:
not if it wrote to "globals". Because then it would have Side Effects
and would no longer be a pure function.

No, parameters are local to functions and any changes aren't visible to
the caller, remember?

Of course if "globals" is a pointer parameter and the function writes to
"*globals", then it's impure.

(I'm certain you know this.)
 
S

Seebs

I'm always looking for my next C reference. I've never heard of King.
Do you possess the book?

I have both 1st and 2nd editions -- I did tech review for the 2nd edition,
after sending in a couple of suggestions and possible errata for the 1st.

It is the book that I recommend to people trying to learn C; I consider it
a better introduction to C than K&R. K&R is a very good book compared to
most programming language books, but I think King's book does a better job
of teaching the language as opposed to merely describing it. (It also, I
think, does a better job of recognizing the now-standard boundaries between
library and user code, although this is pretty much stylistic.)

-s
 
U

Uno

Hi,
yes i do possess it and i've read it from cover to cover.
I'll be honest with you. I'm far from being an expert
of the C language, but i ask you to trust me if i suggest you
that book. The "C programming: a modern approach", 2nd edition,
gives you the skills to start doing a good programming in C.
It also covers the C99 features.
Read a lot about C and above all, always refer to the ISO Standard
as your 100% trustworthy guide:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

That said, before going into too technical details, here are the
most suggested books about C:

1)The C Programming Language, 2nd Edition, by Kernighan and Ritchie
2)C Programming: A Modern Approach, 2nd Edition, by K. King
3)C: A Reference Manual, 5th Edition, by Harbison and Steele
4)The Standard C Library, by P.J.Plauger
5)C Programming FAQ, by Steve Summit
(in part made available online at http://c-faq.com/ )
6)C Traps and Pitfalls, by Andrew Koenig
7)Expert C Programming: Deep C Secrets, by Peter van der Linden
8)The C Puzzle Book, 2nd Edition, by Feuer

i also really suggest this one (unique in its genre):

9)C Interfaces and Implementations: Techniques for Creating Reusable
Software, by Hanson

I possess these books and i can tell you they are one of the most
important thing in my life ;-)

Cheers

Alright, thx, vincenzo, I settled a the lawsuit for somebody running me
over, so my book budget will soon be flush. King will be next.
 
U

Uno

As an acamdemic exercise,
I rewrote part of the standard library as a toy library.

http://www.mindspring.com/~pfilandr/C/library/

The following code is snipped from there,
which is why you don't see
all 5 features mentioned in the comments being used here:

/* BEGIN std_io.h */

#ifndef H_STD_IO_H
#define H_STD_IO_H
/*
** 5 features from stdio.h are used in std_io.c and std_io.h
** 1 EOF
** 2 FILE
** 3 stdout
** 4 putc
** 5 ferror
*/
#include<stdio.h>

#define put_c(c, stream) putc((c), (stream))
#define put_char(c) put_c((c), stdout)

int fput_c (int c, FILE *stream);
int (put_c)(int c, FILE *stream);
int (put_char)(int c);

#endif

/* END std_io.h */




/* BEGIN std_io.c */

#include "std_io.h"

int fput_c(int c, FILE *stream)
{
return put_c(c, stream);
}

int (put_c)(int c, FILE *stream)
{
return put_c(c, stream);
}

int (put_char)(int c)
{
return put_char(c);
}

/* END std_io.c */

Shoot pete, I guessed wrong. I came to my girlfriend's and brought K&R
instead of Plauger. I'll have questions about this.
 
U

Uno

pete said:
> I like questions about code that I've posted.

Alright. I am surprised by how different Plauger's looks than yours:

/* fputc function */
#include "xstdio.h"

int (fputc)(int ci, FILE *str)
{ /* put a character to stream */
unsigned char c = ci;

if (str->_Next < str->_Wend)
;
else if (_Fwprep(str) < 0)
return (EOF);
*str->_Next++ = c;
if (str->_Mode & (_MLBF|_MNBF))
{ /* disable macros and drain */
str->_Wend = str->_Buf;
if ((str->_Mode & _MNBF || c == '\n') && fflush(str))
return (EOF);
}
return (c);
}

Back to your source, a couple questions

$ pwd
/media/disk/gcc_eq32
$ cat tem2.c
/* BEGIN std_io.h */

#ifndef H_STD_IO_H
#define H_STD_IO_H
/*
** 5 features from stdio.h are used in std_io.c and std_io.h
** 1 EOF
** 2 FILE
** 3 stdout
** 4 putc
** 5 ferror
*/
#include <stdio.h>

#define put_c(c, stream) putc((c), (stream))
#define put_char(c) put_c((c), stdout)

int fput_c (int c, FILE *stream);
int (put_c)(int c, FILE *stream);
int (put_char)(int c);

#endif

/* END std_io.h */




/* BEGIN std_io.c */

#include "std_io.h"

int fput_c(int c, FILE *stream)
{
return put_c(c, stream);
}

int (put_c)(int c, FILE *stream)
{
return put_c(c, stream);
}

int (put_char)(int c)
{
return put_char(c);
}

/* END std_io.c */



! gcc -Wall -Wextra tem2.c -o lib1
$

q1) Is the C standard library a compendium of the necessary functions?

q2) If you were going to compile this, how would you divide it into
translation units, and what is the makefile/command line instruction?

Hot !! Now I have to go back out in it. :-(
 
V

Vincenzo Mercuri

Il 19/06/2010 10.40, Uno ha scritto:
Alright, thx, vincenzo, I settled a the lawsuit for somebody running me
over, so my book budget will soon be flush. King will be next.


Good luck and enjoy your reading
 
M

Malcolm McLean

The fundamental difference between functions and procedures is
that functions return something and procedures return nothing.
It follows that functions can be "pure" though they need not be
whereas procedures (if they are to do anything at all) cannot be.
More subtly, functions can appear on the right side of an
assignment whereas procedures cannot.  IIANM these means that
functions can be rvalues whereas procedures cannot.
So
int getcursorx(GRAPHICS g);
int getcursory(GRAPHICS g);

are functions

void getcursorxy(GRAPHICS g, int *x, int *y)

is a procedure.

The problem is you're not really capturing anything interesting in
that distinction. It's relevant for the formal grammar of the
language, but it doesn't have any higher-level effects.
 
M

Malcolm McLean

Yes and no.  Functional languages and functional progamming is
quite different from procedural languages and procedural
programming.  The differences flow from that distinction.  
I'm not a Lisp programmer. However from what I understand there are
also keywords in Lisp which input and output lists. The main
difference is that the lists themselves may be executable. So the
distinction between doing something and shuffling bits would still
hold. Lisp probably makes in more obvious that most code can be
written as functions, however.
 
N

Nobody

I'm not a Lisp programmer. However from what I understand there are
also keywords in Lisp which input and output lists. The main
difference is that the lists themselves may be executable. So the
distinction between doing something and shuffling bits would still
hold. Lisp probably makes in more obvious that most code can be
written as functions, however.

Lisp isn't really a functional language. Although there's some wiggle
room in the definition, a functional language generally means one based
upon the mathematical notion of a function, i.e. a mapping from arguments
to results.

Such a definition doesn't have any notion of side effects or of mutable
state. The result is determined solely by the arguments, and a function
call whose return value isn't used is essentially a no-op.

In such a language, you can't write functions such as rand(), time(),
getc() etc which return different results for the same arguments. Although
it's legal for a function to have no arguments or to return no result
(technically, the argument or result would be a 0-tuple), there's no
point. A function with no arguments may as well be a constant, and a
function which returns no result may as well not be called.

"Impure" functional languages may include features which violate this rule
(e.g. for I/O). Such a language would still be considered "functional" if
it doesn't rely upon such features unnecessarily.
 
N

Nobody

C89 freestanding implementations are only required to have
the following headers available for programming:
<float.h>, <limits.h>, <stdarg.h>, and <stddef.h>.
You can do a lot of programming without using any of those.
C99 freestanding implementations are only required to have
the following headers available for programming:
<float.h>, <iso646.h>, <limits.h>,
<stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>.

I consider not all of but the vast majority of,
new features in C99 to be unnecessary.

Which ones don't you consider to be unnecessary?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,091
Messages
2,570,605
Members
47,225
Latest member
DarrinWhit

Latest Threads

Top