Thread: Unofficial extensions to C, structs with functions, does that exist?

Originally Posted by whiteflags

My favorite site, function-pointer.org, says that using the address of operator is the most compatible thing across compilers. Strangely, no such statement is made for the dereference operation.

If we are to believe this text is completely up to date with standards, then it appears that address of came first, and is the "evil backwards-compatibility feature" according to Elysia. Actually, I agree. Find me a compiler people actually use that doesn't call/assign by function name and I will eat this post. Implementations that can't do this simple thing ought to be broken.

But that's just me. & also happens to be the most erotic ASCII character. I don't have anything against it, but I will perhaps question why fubarc 2.1 was the best compiler around for the project.

To me, there is nothing confusing or contrary about function names being pointers. Think of it like having a pointer named after the function already in scope, and then assigning it to other function pointers becomes completely consistent with even C++ syntax. How about that?

Strange source that. It mixes global functions and member functions and C and C++.
It says almost nothing about C. And for C++ it is pretty much wrong. You must type &NameOfClass::NameOfFunction to create a pointer to a member function. Anything else isn't standard compliant.

Originally Posted by laserlight

I disagree. I think that it makes sense, if you can understand it as an exception for convenience, or possibly even my conjecture about the illusion of functions as first class objects in this context. The same thing applies to arrays: it does not make sense for an array to decay to a pointer to its first element, using your reasoning.

You are right that it doesn't make any sense at all for it to decay to a pointer to its first element. It is there for convenience only.
However, my point was, if we could similarly think of a function as an array of instructions, does it make sense for a the function name to decay into a pointer to the first instruction? It does not, because the standard doesn't deal with the code part of functions. You cannot access the instructions inside a function in any standard conformant way. Thus it makes no sense whatsoever for the name of a function to decay into anything. Unless you add another exception, but then we're again adding another exception, and it is in our best interests not to do that.

Knowing your preference of C++, allow me to cite a problem you have following your logic all the way to function pointers and function objects. Taking your reasoning to its logical conclusion, we should indeed call a function through a function pointer f as (*f)(args), because f(args) is inconsistent with pointer notation. Now, if we were to write a generic algorithm that is supposed to apply say, a predicate, we complicate matters: if the predicate is a function pointer, we should dereference it, but if it is a function object, we should not.

This is true, and while there are ways around that, it certainly would be a hassle. This is another convenience exception that would have to be solved. Shame that. I don't of any good solution to this

Originally Posted by Elysia

However, my point was, if we could similarly think of a function as an array of instructions, does it make sense for a the function name to decay into a pointer to the first instruction? It does not, because the standard doesn't deal with the code part of functions. You cannot access the instructions inside a function in any standard conformant way. Thus it makes no sense whatsoever for the name of a function to decay into anything. Unless you add another exception, but then we're again adding another exception, and it is in our best interests not to do that.

It is clear to me that they are different exceptions to the rule.

Originally Posted by Elysia

I don't of any good solution to this

There is a bad solution though: all function objects must overload unary operator* to return a reference to *this

Originally Posted by User Name:

I think w/o & is better because it fits with the pattern that when calling a location you don't put & in front of it.

Code:

void realfunc();
int main()
{
    ((void (*) ()) 10) ();
    ((void (*) ()) realfunc) (); // same as "realfunc();" not "&realfunc();"
    return 0;
}
void realfunc(){}

It's hard to explain what I mean, but I think you'll understand.

Why would it make sense? When you call a function, you specify its name. The compiler doesn't implicitly convert that to its address or anything. That is basic C syntax.
Using C methodology,

Code:

typedef (void (realfunc_t) ();
realfunc_t ptr = &realfunc;

ptr is the address of the function and *ptr is the function. So to call the function you would have to call the "actual" function and not its address.

Originally Posted by laserlight

It is clear to me that they are different exceptions to the rule.

Absolutely. But we agree that exceptions are bad, yes?
They are circumventing "the proper" way of doing things by confuscating the syntax
Which basically is the problem...

There is a bad solution though: all function objects must overload unary operator* to return a reference to *this

o_O
Stay away from me, you evil object!

Originally Posted by Elysia

When you call a function, you specify its name. The compiler doesn't implicitly convert that to its address or anything. That is basic C syntax.

Actually, semantically, the function call operator is invoked on a function pointer. The function designator is implicitly converted to a function pointer in order for this to happen. Of course, in compiled code, this is just "imaginary" semantics.

Likewise, when we talk about array subscripting, the array is converted to a pointer to its first element, i.e, array subscripting is defined with respect to pointers, not arrays.

Originally Posted by whiteflags

It just wants to teach function pointers in both languages. You might as well complain about programming examples in general and how they are not usually complete programs. How is it wrong? The text does not argue this point and even supports your point of view. The examples follow proper C++ standards.

The source you quoted is confusing at best. It mentions putting the names of member functions only, for example, which clearly isn't standard.
That is kinda of what put me off there. I don't know if what it was trying to say is correct or not.
I couldn't see much reference to function pointers in C either.
That's all I'm saying.

It seems to me that people are not as inconsistent with the choices they make, as much as you would like to believe. I'm just not convinced that the syntax is confusing. It might be convenient, but I'd argue even that.

This makes no sense to me... what is it supposed to argue?

A subroutine in a compiled program is just a memory address: you refer to the area where the instructions are stored when you want the machine to do foo(). Feel free to blow me off though, you're doing a fine job of that already.

But C is an abstraction from the low-level stuff. If you to call functions by jumping to their address in memory, you'd use assembly. C has a standard way of calling functions that is independent on how the reality is.

Function pointers are a different beast all together -- function pointers want to be lambdas. Would you discuss lambda in pointer context? Absolutely not. You can't even really treat function pointers like normal pointers because you would never allocate or delete memory for them.

Are you referring to me specifically or generally?

Originally Posted by laserlight

Actually, semantically, the function call operator is invoked on a function pointer. The function designator is implicitly converted to a function pointer in order for this to happen. Of course, in compiled code, this is just "imaginary" semantics.

Likewise, when we talk about array subscripting, the array is converted to a pointer to its first element, i.e, array subscripting is defined with respect to pointers, not arrays.

Hmmm.
Does the standard say it is so? Or is it just some imaginary way of explaining how it might happen?

Originally Posted by Elysia

Does the standard say it is so? Or is it just some imaginary way of explaining how it might happen?

Read:

Originally Posted by C99 Section 6.5.2.2 Paragraph 1

The expression that denotes the called function (Note 77) shall have type pointer to function returning void or returning an object type other than an array type.

Originally Posted by C99 Section 6.5.2.2 Note 77

Most often, this is the result of converting an identifier that is a function designator.

Originally Posted by C99 Section 6.5.2.1 Array subscripting, Paragraph 1

One of the expressions shall have type "pointer to object type", the other expression shall have integer type, and the result has type "type".

That covers implicit declarations, but what about actual function calls? Does it mention anything explicit?

Originally Posted by Elysia

That covers implicit declarations, but what about actual function calls? Does it mention anything explicit?

You must have missed Note 77.

So we can conclude that it is an implicit conversion to a function pointer that makes this possible? That... just... sucks.

Originally Posted by Elysia

So we can conclude that it is an implicit conversion to a function pointer that makes this possible?

My guess is that it is simpler to define it that way. In reality, maybe the function might even be inlined.

But the problem with definitions is that they are what we live by. We can't complain that get_a decaying to a function pointer is alien C now that the very definition of a function calls says that it decays into a function pointer.
Now it's no longer a discussion of semantics but rather opinions.
One thing bothers me, though: is it still kept for backwards compatibility or is it an integral part of the standard?

Originally Posted by Elysia

The source you quoted is confusing at best. It mentions putting the names of member functions only, for example, which clearly isn't standard.
That is kinda of what put me off there. I don't know if what it was trying to say is correct or not.
I couldn't see much reference to function pointers in C either.
That's all I'm saying.

Perhaps you should write the author and correct him, but you seem to barely comprehend the text as it is, which is not my problem. Maybe you would sooner discuss topics you actually completely understand, if you are going to argue so fervently on minutae.

Originally Posted by Elysia

This makes no sense to me... what is it supposed to argue?

But C is an abstraction from the low-level stuff. If you to call functions by jumping to their address in memory, you'd use assembly. C has a standard way of calling functions that is independent on how the reality is.

The part that you found confusing should have followed to the part that you argued.

It seems to me that people are not as inconsistent with the choices they make, as much as you would like to believe. I'm just not convinced that the syntax is confusing. It might be convenient, but I'd argue even that.

IOW, people are being consistent with the reality when they choose to forego the dereference operator.

Further, if I'm not allowed to to support my opinion with reality, I am really unsure how to convey my point of view. You're dismissing it outright and basically telling me you don't want to talk. OK that's fine, but the way you put it smacks of stupidity. The build process in both languages involves drilling down to assembly.

I wonder if when you say "C has a standard way of calling functions" you mean the C calling convention, stdcall? If that's all you have to argue, then I can just say "well follow convention" and we're at an impasse. How is calling a regular function different from calling a function through a pointer? If you have an answer to that based in reality then we have something to talk about. The argument is completely different in that case, because it is not just about syntactic sugar.

Goukigenyou.

Originally Posted by CSaw

I guess I always use the get_a way because I learnt that the name of an array was the address of it's first element, so the name of the function would, not be the address of it's first instruction but, be the first address of the which the function appears ( if that makes sense? ).

How does that make sense? What do you imagine a function being a collection of?

Originally Posted by whiteflags

Further, if I'm not allowed to to support my opinion with reality, I am really unsure how to convey my point of view. You're dismissing it outright and basically telling me you don't want to talk. OK that's fine, but the way you put it smacks of stupidity. The build process in both languages involves drilling down to assembly.

No, what I meant was that how things appear in hardware or assembly is largely irrelevant to the discussion since it discusses the semantics of the standard.
C is an abstraction of the hardware and thus doesn't work exactly as it does. So using the real world as examples might not be the best idea.
But whatever, if you have an argument by using real world examples, by all means, go ahead.

I wonder if when you say "C has a standard way of calling functions" you mean the C calling convention, stdcall? If that's all you have to argue, then I can just say "well follow convention" and we're at an impasse. How is calling a regular function different from calling a function through a pointer? If you have an answer to that based in reality then we have something to talk about. The argument is completely different in that case, because it is not just about syntactic sugar.

What I meant was that C allowed you to call a function by its name and not its address.
But apparently that isn't a valid argument anymore because the standard is broken IMO. Some block-heads thought it was a good idea to define function calls as an expression that decays into a function pointer and then called through function pointer syntax.

I don't have much to add because of the broken standard.