stream functions

[James Kuyper]

On 02/13/2012 05:14 AM, Nick Keighley wrote:
....

I think some functional languages manage without them. Certainly Lisp,
C++, Python programs can be written that don't use loops.

In C++ loops can be avoided, but for most non-trivial programs that
requires relying heavily on the <algorithms> portion of the C++ standard
library, which can be implemented in portable C++ code that necessarily
involves loops internally. Therefore, the absences of loops is only
skin-deep in such C++ code. I don't know those other languages well
enough to be sure, but I from what I've heard about Lisp the absence of
loops runs much deeper in that language.

 

[Nick Keighley]

On 02/13/2012 05:14 AM, Nick Keighley wrote:
...


In C++ loops can be avoided, but for most non-trivial programs that
requires relying heavily on the <algorithms> portion of the C++ standard
library, which can be implemented in portable C++ code that necessarily
involves loops internally. Therefore, the absences of loops is only
skin-deep in such C++ code. I don't know those other languages well
enough to be sure, but I from what I've heard about Lisp the absence of
loops runs much deeper in that language.

lisp has loop constructs as well, which is why I was careful in my
phrashing. Sometimes it isn't clear what is langauge and what is
library.

 

[Markus Wichmann]

I think some functional languages manage without them. Certainly Lisp,
C++, Python programs can be written that don't use loops.

Ah, functional languages! The next big hype after object oriented
languages. Just wait till they notice that functional languages also
aren't the answer to the universe and everything.

to put it mildly! Loops are absolutly fundamental to a language like C.

Theoretically, all loops can be replaced by recursive functions. But
that could become a PITA. For instance, finding x, y and z such that for
a 3D-array a you get a[x][y][z] == c. With loops:

int find_in(int*** a, int* x, int* y, int* z, int c)
{
for (*x = 0; *x < MAX_X; ++*x)
for (*y = 0; *y < MAX_Y; ++*y)
for (*z = 0; *z < MAX_Z; ++*z)
if (a[*x][*y][*z] == c)
return 1;
return 0;
}

Without loops:

int find_in_z(int*** a, int* x, int* y, int* z, int c)
{
if (*z >= MAX_Z) return 0;
if (a[*x][*y][*z] == c) return 1;
++*z;
return find_in_z(a, x, y, z, c);
}

int find_in_y(int*** a, int* x, int* y, int* z, int c)
{
if (*y >= MAX_Y) return 0;
if (find_in_z(a, x, y, z, c)) return 1;
++*y;
return find_in_y(a, x, y, z, c);
}

int find_in_x(int*** a, int* x, int* y, int* z, int c)
{
if (*x >= MAX_X) return 0;
if (find_in_y(a, x, y, z, c)) return 1;
++*x;
return find_in_x(a, x, y, z, c);
}

int find_in(int*** a, int* x, int* y, int* z, int c)
{
*x = *y = *z = 0;
return find_in_x(a, x, y, z, c);
}

 

[David Thompson]

These functions are new to C99.

Nope, fgetpos/fsetpos/fpos_t were new in C89.

POSIX ftello/fseeko/off_t were later, but still before C99 IIRC.
(And offtopic.)

The combination of ftell() and fseek() is useful to go back to a
position where you've been before, and for a large file it is likely
to be faster than just reading stuff and throwing out the data.

<snip example>

Yep. And for a large file that's very likely an understatement.

fseek() seeks to a *POSITION* in a (text or binary) file. It does
not look at the data in the file. <snip>
fseek() does not know of artificial constructs you might ascribe
to parts of a text or binary file like "line", "record", "column",
"paragraph", "chapter", "section", or "page".

Well, if you use fixed length records fseek(,rec*K,SEEK_SET) works, at
least in a binary stream. And some structures use metadata that points
to byte locations, such as a B-tree index. But for probably most of
the files most application programmers use nowadays, I agree.