Does it mean an array of pointers to a function taking
two parameters(one a void pointer, another an integer)
and returning a void pointer?
Or am I missing something? Which would be a good book
to understand how to decode such declarations?
Sorry, if my question is naive, but I feel bad and think i should
improve my skills, if i have doubts
about my decoding a statement in a language which a lot of high school
students can
do easily these days :(
> I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
>
> Does it mean an array of pointers to a function taking
> two parameters(one a void pointer, another an integer)
> and returning a void pointer?
Yup. That's it.
> Or am I missing something? Which would be a good book
> to understand how to decode such declarations?
I don't know of a book, but you seem to have the hang of it. You read
inside out from the name (respecting brackets), moving left in
preference to moving right.
There's a utility -- cdecl that can turn them into text. I don't know
if it works for C++ (I just noticed the cross-post!).
<snip>
--
Ben.
Not naive at all. But a simpler solution is to take whoever wrote that
declaration out to the woodshed for a lesson in good coding style. A
typedef or two would make this much easier.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
>I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
>
> Does it mean an array of pointers to a function taking
> two parameters(one a void pointer, another an integer)
> and returning a void pointer?
>
> Or am I missing something? Which would be a good book
> to understand how to decode such declarations?
_Expert C Programming_ by Peter van der Linden is the best one I know of in
this area.
A trick that usually works is to start with the named object and then
"circle" it, alternately picking up descriptions from either side while
working out from the center. I.e., p is an array of pointers to
functions with the specified argument types which return pointers to
void.
--
Rich Webb Norfolk, VA
K&R?
> There are enough web pages on the subject, and there is the
> cdecl or gcc source code for a formal definition, but I'd
> like to add one idead of my own:
>
> The above starts with »void«, so this means:
>
> »void is the type of the expression *( *p[ 0 ])( 0, 0 ).«.
>
> From that, you can deduce the type of p.
I have the uneasy feeling you skipped a few stages...
> >Sorry, if my question is naive, but I feel bad and think i should
> >improve my skills, if i have doubts
>
> What ever happens, you must never feel bad,
but don't feel bad if you do
> because that
> will degrade your productivity. So, first of all, you need
> to reconstitute high spirits. The good mood must be upheld
> whatever your capabilities regarding C are.
this reminds me of the teacher who told me, when I was 6, not to be
afraid of dogs as they can smell your fear
And a C or C++ compiler really can smell your fear.
As soon as it does it starts playing all sorts of nasty tricks on you, reporting
errors where none are, even in the wrong files; for C++ burying the relevant
information in avalanches of template gobbledegook; fouling up and refusing to
understand your self-evidently correct pointer casts; etc., etc., even, when on
occasion it does find a real error, trying to trick you into believing that it's
not an error in the code, but instead reporting an Internal Compiler Error.
The cure is in all cases to feed it goodly portion of Pascal source code until
it understands who's master.
Cheers,
- Alf
> >> [What ever happens, you must never feel bad,]
I had always suspected this
cdecl> explain void *(*p[]) (void*, int)
declare p as array of pointer to function (pointer to void, int) returning pointer to void
Andrew.
It also helps to keep a copy of "The Art of Computer Programming" near
your workstation, to scare away any bugs...
I will read the suggested books and use cdecl.
Thanks again.
You posted the same followup 5 times. Please investigate what caused
that to happen.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
You've got it.
> Or am I missing something? Which would be a good book
> to understand how to decode such declarations?
>
Just about any good C reference should describe declarator syntax in
general, but the way I break it down is to find the leftmost
identifier, then work my way out, remembering that [] and () bind
before * (i.e., *a[] is an array of pointer, not a pointer to an
array):
p -- p
p[] -- is an array
*p[] -- of pointers
(*p[])(void *a, int n) -- to functions taking void *
and int parameters
*(*p[])(void *a, int n) -- returning pointers
void *(*p[])(void *a, int n) -- to void
Thanks again.
P.S. Don't understand why my reply did not show up earlier
though i was told by my newsreader that it posted properly.
> You posted the same followup 5 times. Please investigate what caused
> that to happen.
My apologies. I did not want to post 5 times. I am using Newsrover as the
newsreader software. When it did
not give me the message posting successfully and told me authentication
failed. I restarted Newsrover and tried to
do it again. After the same issue occurred, I gave up thinking i should try
tomorrow. This is what led to these five posts.
Sorry for that.
> "t" <t...@t.com> writes:
>
> > I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
> >
> > Does it mean an array of pointers to a function taking
> > two parameters(one a void pointer, another an integer)
> > and returning a void pointer?
>
> Yup. That's it.
>
> > Or am I missing something? Which would be a good book
> > to understand how to decode such declarations?
>
> I don't know of a book, but you seem to have the hang of it. You read
> inside out from the name (respecting brackets), moving left in
> preference to moving right.
>
Other way; array and function to the right must be taken before
pointer (or C++ reference) to the left.
Overridden by en_GB brackets = en_US parentheses, to be clear.
> On Tue, 16 Feb 2010 21:28:25 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>> "t" <t...@t.com> writes:
>>
>> > I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
>> >
>> > Does it mean an array of pointers to a function taking
>> > two parameters(one a void pointer, another an integer)
>> > and returning a void pointer?
>>
>> Yup. That's it.
>>
>> > Or am I missing something? Which would be a good book
>> > to understand how to decode such declarations?
>>
>> I don't know of a book, but you seem to have the hang of it. You read
>> inside out from the name (respecting brackets), moving left in
>> preference to moving right.
>>
> Other way;
Would you believe I get left and right confused? Extraordinary but
true. I usually pause and check multiple times when I write either
but even then this can happen. I don't confuse the /directions/ its
is their, to me, arbitrary names that cause the trouble!
--
Ben.
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >is their, to me, arbitrary names that cause the trouble!
>
> The names are not arbitrary.
>
> Look at the word �Left�.
> There's a vertical mark on the /left/ side of the rule: �L�.
> And what happens, when you write �left� and �right� in
> alphabetical order?
>
> left right
>
> When you then read this, the word �left� is left and
> the word �right� is right.
>
> So it all comes out right. (Even in this sentence, the
> word �right� is in the rightmost position.)
From this, I conclude that Frenchmen and Italians are looking-glass
creatures.
Richard