quik popularized by ANSI C

[celsius]

Hi all,

please forgive me if this already posted many times.
i was reading peter van der linden's book expert C programming.
on page number 188,he is discussing about implementing finite state
machine in C.

he explains as follows :-

there are several ways to implement finite state
machines in C,but the most common one is is array of pointers to
functions.an array of pointers to functions can be declared like this:

void (*state[MAX_STATES])(); if you function names,you can initialize
the array like so:

extern int a(),b(),c(),d();
int (*state[])() = {a,b,c,d};

a function can be called through a pointer to array like this

(*state[i])();.pointers to function can be funny.notice,too, how
the pointer can be dropped, so our call can be made equally be made as

state[i](); or even (******state[i])();

this is an unfortunate quirk popularized by ANSI C:calls to a function
and calls to a function through a pointer(or any level of pointer
indirection) can use same syntax
there is a corresponding quirk that applying to arrays.it further
undermines the flawed "declaration looks like use" philosophy.
now my question is

1)why this unfortunate quirk was made possible in ANSI C ?
2) there is a corresponding quirk that applying to arrays,i would
like to know what this quirk is ?

[Jack Klein]

On 13 Jun 2004 09:21:49 -0700, at*******@yahoo.co.uk (celsius) wrote
in comp.lang.c:

Hi all,

please forgive me if this already posted many times.
i was reading peter van der linden's book expert C programming.
on page number 188,he is discussing about implementing finite state
machine in C.

he explains as follows :-

there are several ways to implement finite state
machines in C,but the most common one is is array of pointers to
functions.an array of pointers to functions can be declared like this:

void (*state[MAX_STATES])(); if you function names,you can initialize
the array like so:

extern int a(),b(),c(),d();
int (*state[])() = {a,b,c,d};

a function can be called through a pointer to array like this

(*state[i])();.pointers to function can be funny.notice,too, how
the pointer can be dropped, so our call can be made equally be made as

state[i](); or even (******state[i])();

this is an unfortunate quirk popularized by ANSI C:calls to a function
What is unfortunate about it? Who says it is unfortunate? What are
their qualifications for making that statement? And why are you
talking about a "quirk", when your subject line mentions a "quik"?
For that matter, who says it is a "quirk" or "quik"? This is the way
the language is defined to work.

Does the use of the '+' character as an addition operator qualify as a
"quirk"? Why or why not? Because you, or some unnamed person you do
not cite, does or does not like it?
and calls to a function through a pointer(or any level of pointer
indirection) can use same syntax
there is a corresponding quirk that applying to arrays.it further
Who says there is a corresponding "quirk" (or "quik") that applies to
arrays.
undermines the flawed "declaration looks like use" philosophy.
Who says that this feature of the languages is either a "philosophy",
or "flawed"? Since neither term appears at all in the ISO/IEC
standard defining the language, they, like "quirk", have no meaning on
this forum. They are apparently matters of somebody's opinion, yet
you state them as fact.
now my question is

1)why this unfortunate quirk was made possible in ANSI C ?
Again, what "unfortunate quirk"? Since the standard does not define
it as such, where does this statement come from? What are the
credentials of the author of these terms, that we should take it
seriously?

More objectively, you have provided absolutely no foundation at all
for the adjective "unfortunate". What is "unfortunate" about this
defined feature of the language? In what way does it limit the use of
C programs or language features that would otherwise not be limited?

Can you cite any instance at all where this language syntax prevents
some program construct that would otherwise be available?

If you don't like the language syntax, feel free to join your national
standards body and volunteer for their C standards committee working
group. Then you may work to have it changed.
2) there is a corresponding quirk that applying to arrays,i would
like to know what this quirk is ?

Again, what "quirk"? You have posted a lot of rubbish loaded with
imprecise opinionated words like "quirk", "flawed", "unfortunate", and
"philosophy", none of which have any defined meaning at all in terms
of C.

I think your particular post is a "quirk", "flawed" by your
"unfortunate" "philosophy".

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Malcolm]

"Jack Klein" <ja*******@spamcop.net> wrote in message

What is unfortunate about it? Who says it is unfortunate? What > are their qualifications for making that statement? And why are you talking about a "quirk", when your subject line mentions a
"quik"?

It is a bit silly that

int (*fptr) (int);

fptr = afunction;

x = (*fptr) (1) ;
y = fptr(1);

as exactly the same effect. Of course a function is not a variable, so
dereferencing a function pointer is not exactly meaningful.

[Jack Klein]

On Sun, 13 Jun 2004 22:42:13 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote in comp.lang.c:

"Jack Klein" <ja*******@spamcop.net> wrote in message

What is unfortunate about it? Who says it is unfortunate? What > are

their qualifications for making that statement? And why are

you talking about a "quirk", when your subject line mentions a
"quik"?

It is a bit silly that

int (*fptr) (int);

fptr = afunction;

x = (*fptr) (1) ;
y = fptr(1);

as exactly the same effect. Of course a function is not a variable, so
dereferencing a function pointer is not exactly meaningful.

Why is that any sillier than:

int some_func(const char*);

char ch [] = "Hello";

....when now:

some_func(ch);

....and:

some_func(&ch[0]);

....have exactly the same effect?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[J. J. Farrell]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:he********************************@4ax.com...

On 13 Jun 2004 09:21:49 -0700, at*******@yahoo.co.uk (celsius) wrote
in comp.lang.c:

please forgive me if this already posted many times.
i was reading peter van der linden's book expert C programming.
on page number 188,he is discussing about implementing finite state
machine in C.

he explains as follows :-

there are several ways to implement finite state
machines in C,but the most common one is is array of pointers to
functions.an array of pointers to functions can be declared like this:

void (*state[MAX_STATES])(); if you function names,you can initialize
the array like so:

extern int a(),b(),c(),d();
int (*state[])() = {a,b,c,d};

a function can be called through a pointer to array like this

(*state[i])();.pointers to function can be funny.notice,too, how
the pointer can be dropped, so our call can be made equally be made as

state[i](); or even (******state[i])();

this is an unfortunate quirk popularized by ANSI C:calls to a function
What is unfortunate about it? Who says it is unfortunate? What are
their qualifications for making that statement? And why are you
talking about a "quirk", when your subject line mentions a "quik"?
For that matter, who says it is a "quirk" or "quik"? This is the way
the language is defined to work.

Does the use of the '+' character as an addition operator qualify as a
"quirk"? Why or why not? Because you, or some unnamed person you do
not cite, does or does not like it?

In what ways does "peter van der linden's book expert C programming.
on page number 188" fail as a citation, other than a slight shortage
of punctuation?
Again, what "quirk"? You have posted a lot of rubbish loaded with
imprecise opinionated words like "quirk", "flawed", "unfortunate", and
"philosophy", none of which have any defined meaning at all in terms
of C.

I think your particular post is a "quirk", "flawed" by your
"unfortunate" "philosophy".

Please read more carefully before going over the top. The poster quoted
van der Linden's book, and effectively asked for a discussion of the
opinions that van der Linden expressed. It is unreasonable to lay into
the poster in this way, when he simply appears to be trying to understand
van der Linden's opinions and reasoning.

[Arthur J. O'Dwyer]

On Sun, 13 Jun 2004, Jack Klein wrote:

On Sun, 13 Jun 2004 22:42:13 +0100, "Malcolm" wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message

What is unfortunate about it?
It is a bit silly that

int (*fptr) (int);

fptr = afunction;

x = (*fptr) (1) ;
y = fptr(1);

as exactly the same effect. Of course a function is not a variable, so
dereferencing a function pointer is not exactly meaningful.

I think it's a quirk, but it has a very good purpose. I generally
try to keep "redirectable function pointer" and "immutable function" as
two separate concepts where useful; thus, I follow Declaration-Mimics-Use
with pointers

int (*fptr)(int);
x = (*fptr)(42);

and functions

int func(int);
y = func(42);

unless I have a darn good reason not to.

Why is that any sillier than:

int some_func(const char*);

char ch [] = "Hello";
some_func(ch);
some_func(&ch[0]);
...have exactly the same effect?

Count the levels of indirection.

ch --- 0 levels
&ch[0] --- 0 levels
fptr --- 0 levels
*fptr --- 1 level

The former pair (Jack's example) have the same effect because they
designate the same object with the same number of levels of indirection.
The latter pair (Malcolm's example) have the same effect *despite*
different levels of indirection. In fact, as van der Linden points
out,

*****fptr --- 5 levels

has --- almost --- exactly the same value and semantics as 'fptr'
(0 levels).

Now, why is this? Simple: like array names, function names "decay"
into function pointers in value contexts. Thus, while 'func' is a
function, '*func' is "the-function-pointed-to-by-the-decayed-function-
pointer-'func'." That is, it's exactly the same function. And then
since '*func' is a function, obviously we can recurse: '**func' is
the function pointed to by the pointer we get by decaying '*func';
'***func' and '****func' and '*********func' are exactly the same
function.

The "--- almost ---" above is a nod to the fact that when 'fptr'
is a function pointer, then 'sizeof fptr' yields the size of the
function pointer type; but 'sizeof *fptr' (and 'sizeof '*****fptr')
try to evaluate the size of an actual function type, which is not
allowed by the rules of the C language. Thus the expressions 'fptr'
and '*fptr' behave differently in the context of 'sizeof' (and also
in the context of '&', where '&*fptr' is 'fptr' itself, but '&fptr'
is the address of the pointer object 'fptr').

As array names do not decay to array pointers, but rather to pointers
to their first elements, there is no "corresponding quirk" with respect
to arrays. I don't know what van der Linden was talking about, there,
but perhaps you ought to read the next few pages; I bet he explains his
statement. I'll check next time I see the book.

HTH,
-Arthur