Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!hpda!fortune!shah
From: shah@fortune.UUCP
Newsgroups: net.unix
Subject: Re: functions returning pionters to func - (nf)
Message-ID: <2038@fortune.UUCP>
Date: Sat, 17-Dec-83 11:05:02 EST
Article-I.D.: fortune.2038
Posted: Sat Dec 17 11:05:02 1983
Date-Received: Sun, 18-Dec-83 23:57:01 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 47

#R:azure:-243000:fortune:26900008:000:1551
fortune!shah    Dec 17 02:47:00 1983

+------
|    fortune:net.unix / rpw3 / 12:16 am  Dec 17, 1983
|                      ....
| I finally solved it using typedefs, but wasn't happy, since there seemed
| something inelegant about that. The following program does it WITHOUT
| typedefs (although the typedef version is easier to read, and was what
| was used in production).
|                      ....
|  struct foo      { struct foo (*(*dummy)())[];   } (*state)[];
|                      ....
+-------

    Something that makes reading (comprehension) easy seems
more elegant to me.  Coming up with the right struct
definition without using typedefs IS more challenging (even
reading it is challenging, every time!) but elegant it is not.

    Like routines typedefs are a factoring mechanism.  Unlike
routines they cost you nothing at runtime.  I recommend
everyone to use them where appropriate; they are free.

    The key concept in Rob's problem is how to define a
recursive type involving a routine ptr.  Here is a simpler
problem with that property:

        Let f be a pointer to a routine.  Define f so that the
    result of the routine pointed to by f can be assigned to
    f.  The assignment must be typesafe and must not use any
    casts.

    Try to solve this with typedefs and then without.  The
compiled code of a correct solution will be identical to code
of

    typedef char * (*fType)();
    fType f;

    f = (fType) (*f());

    Please do not post any solution(s) to net -- not too soon,
anyway.  Anyone else have REALLY tough C puzzles?

				    -- Bakul Shah