"Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:eabhs0$2kkr$1@digitaldaemon.com...

> C has them? Where did you see that, I was under the impression that C only had function pointers, and they were all the same, such that the value a function was the same as the value of taking the address of the function: (func) == (&func)

I'm not sure, but I think that skipping the & on getting a function pointer in C is an "extension", or part of the newest standard that not all compilers support.

Function types are allowed in C; you can't have an array of functions.

> Similarly to what happens to arrays.

Mm?  I thought

char x[];
x is char*
&x is char**

"BCS" <BCS@pathlink.com> wrote in message news:eabg5b$1h47$6@digitaldaemon.com...

> I'd leave it. It would be more consistant.
>
> FunctionPointer ::= "&" FunctionSpecifier;
> FunctionSpecifier ::= FunctionIdentifier [ OverloadResolver ]
> OverloadResolver ::= ["." "(" TypeList ")" ]
>
> vs.
>
> // "&" befor OR resolver after,   Hmmm.
> FunctionPointer ::=
> "&" FunctionIdentifier |
> FunctionIdentifier OverloadResolver;
> OverloadResolver ::= ["." "(" TypeList ")" ]

I think we could just skip the "&ident" form and make it required to use the "ident.()" form instead.  So the only way to get a function pointer would be to use the overload resolve exp.

> It would still leave that problem.

Ah, I see; yeah, there'd be the problem if the "&ident" form were allowed, since it could be a property call (damn D "properties").  Get rid of that, though, and there's _no_ ambiguity ;)

> Thinking about it the "Ident . ( Types )" syntax looks good.

My rationale for it was that it's kind of selecting a member.  "ident" declares a sort of namespace of functions with the same name, and you select the correct overload as if it were a member of that namespace.

Jarrett Billingsley wrote:
> "Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:eabhs0$2kkr$1@digitaldaemon.com...
> 
>> C has them? Where did you see that, I was under the impression that C only had function pointers, and they were all the same, such that the value a function was the same as the value of taking the address of the function:
>> (func) == (&func)

Ok, I now realize they are subtly different: although the value is the same ( func) == (&func) ) , one can "&" a "func" but can't "&" a "&func" (ie, one can't indefinitely use operator "&") , so that's a small difference. :p

> 
> I'm not sure, but I think that skipping the & on getting a function pointer in C is an "extension", or part of the newest standard that not all compilers support.
> 

Nope, I think it's there since K&R ANSI C, although I don't have the book here with me to confirm.

> Function types are allowed in C; you can't have an array of functions.
> 
>> Similarly to what happens to arrays.
> 
> Mm?  I thought
> 
> char x[];
> x is char*
> &x is char** 
> 
> 

"char x[];" is not valid C. "char x[]" is only valid when there is an array initializer "char x[] = {...};", or as a function parameter type, but in this latter case it is not an array, it is a char pointer (char*).

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:eafnr8$e4c$1@digitaldaemon.com...

> Nope, I think it's there since K&R ANSI C, although I don't have the book here with me to confirm.

Hm.

> "char x[];" is not valid C. "char x[]" is only valid when there is an array initializer "char x[] = {...};", or as a function parameter type, but in this latter case it is not an array, it is a char pointer (char*).

Oh that's right; in C[++], arrays and pointers _are_ separate types, it's just that when you pass an array into a function, the type info is lost and it just becomes a pointer.  That's why:

char x[] = "hello";
printf("%d", sizeof(x));

Prints 6 (length of string + null char), but

void fork(char x[]) // old-fashioned, same as "char* x"
{
    printf("%d", sizeof(x));
}

..
char x[] = "hello";
fork(x);

prints 4 (the size of a char*).

This is why I like D.  Arrays are actually first-class types.

Bruno Medeiros wrote:
> Don Clugston wrote:
<snip>
>> Function types are just bizarre. I only recently discovered that C has them. Are you allowed to do anything with them, other than converting them to a function pointer by taking their address?
> 
> C has them? Where did you see that, I was under the impression that C only had function pointers, and they were all the same, such that the value a function was the same as the value of taking the address of the function:
> (func) == (&func)
> Similarly to what happens to arrays.

I discovered quite recently that C supports such oddities as

    typedef int qwert(char*);

(if I've got the syntax right), thereby defining qwert to be an alias for a function of type int(char*).  I've seen it in the LAM MPI headers.  But as you say, it seems useless - AFAIK the only thing you can do with it is declare something of type pointer to qwert.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Bruno Medeiros wrote:
>> Don Clugston wrote:
> <snip>
>>> Function types are just bizarre. I only recently discovered that C has them. Are you allowed to do anything with them, other than converting them to a function pointer by taking their address?
>>
>> C has them? Where did you see that, I was under the impression that C only had function pointers, and they were all the same, such that the value a function was the same as the value of taking the address of the function:
>> (func) == (&func)
>> Similarly to what happens to arrays.
> 
> I discovered quite recently that C supports such oddities as
> 
>     typedef int qwert(char*);
> 
> (if I've got the syntax right), thereby defining qwert to be an alias for a function of type int(char*).  I've seen it in the LAM MPI headers.  But as you say, it seems useless - AFAIK the only thing you can do with it is declare something of type pointer to qwert.
> 
> Stewart.
> 

I've quite recently discovered that D supports that as well!
-> http://d.puremagic.com/issues/show_bug.cgi?id=270
But ah... there is a use for such a typedef after all. I thought they could not be used in declarations at all, but forgot about declaring a pointer to it. But still I don't know if they are worth the strange syntax.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Stewart Gordon wrote:
<snip>
>> I discovered quite recently that C supports such oddities as
>>
>>     typedef int qwert(char*);
>>
>> (if I've got the syntax right), thereby defining qwert to be an alias for a function of type int(char*).  I've seen it in the LAM MPI headers.  But as you say, it seems useless - AFAIK the only thing you can do with it is declare something of type pointer to qwert.
> 
> I've quite recently discovered that D supports that as well!
> -> http://d.puremagic.com/issues/show_bug.cgi?id=270
> But ah... there is a use for such a typedef after all. I thought they could not be used in declarations at all, but forgot about declaring a pointer to it. But still I don't know if they are worth the strange syntax.

Can anyone think of a use case for this?  I can't.  Just declare a
typedef or alias of the function pointer type and be done with it.  UIMS there is nothing to be gained, besides empty complexity, by trying to support such things.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:eaoc0i$309e$2@digitaldaemon.com...

> Can anyone think of a use case for this?  I can't.  Just declare a typedef or alias of the function pointer type and be done with it.  UIMS there is nothing to be gained, besides empty complexity, by trying to support such things.

Don't get so worked up about it.  It'd probably be more complex to add in checking to make sure that you don't try to create an alias/typedef to a function type.  And there's already checking in place to make sure that you don't use function types incorrectly.