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

Yes, it is.

Yes, it is. It has caused problems before and is likely to do so again.
C++ should support C natively and not be backwards compatible. That would be the best things, but is unlikely to happen.

Not exactly. C++ is backwards compatible with C in a sense that any C code should be able to compile with a few modifications under C++. This is bad, because it means C++ must inherit whatever nonsense C has, such as void* pointers.
OTOH, if C++ supported C natively, it means that it would support low-level features that completely supports C++'s approach. No more void*. No more passing native arrays. Etc. Etc.
Plus there's no problems with features clashing, such as auto. It was delayed until the 0x standard due to problems with the C standard. It is much easier to change such things if it within the same standard.

Originally Posted by CSaw

Also with the function name being equal to the address of the function, I don't think it is evil at all. Why is it evil compared to &get_a?

Because a function is not a variable. You cannot copy the contents of a function into somewhere else. That is why get_a makes no sense.

( if you ask me &get_a confuses me because get_a is the address of the function so that would mean &get_a is the address of the address of the function, in a semantic sense, no?)

No, it doesn't. get_a is the contents of the function, similarly to a variable. And to take the address of something, you must the use the address of operator. Hence it makes perfect sense while get_a makes no sense at all.

I also disagree with the void pointers comment, sure if used incorrectly they cause problems but so could any language feature. I use void pointers to implement generics and I find it a rather useful language feature. Of course, I'm not an expert...

In C you will find it useful, but in C++ it is completely redundant and pretty much only supported for backwards compatibility. That is because templates can completely replace void*.
So having to support it is just a pain, extra baggage, so to speak, for C++. That is one area where backwards compatibility hurts the language.

Originally Posted by Elysia

Because a function is not a variable. You cannot copy the contents of a function into somewhere else. That is why get_a makes no sense.

I do not follow your reasoning. You are pretty much ignoring the fact that function designators are converted to function pointers.

Originally Posted by Elysia

No, it doesn't. get_a is the contents of the function, similarly to a variable.

I would say that get_a is the name of the function.

Originally Posted by Elysia

And to take the address of something, you must the use the address of operator.

No, that is not true. The C standard contradicts you on this point.

In a way, this is an illusion: functions are not really first class objects in C, but this syntax, along with the corresponding ability to call the function via the function pointer without explicitly dereferencing the pointer, makes it such that in this context of argument passing functions appear to be first class objects.

Consider variables. To create one, we use a declaration. Similarly, we create functions (though we must also define what they contain later).
To assign the contents of a variable somewhere else, we type the name of the variable. Example:

Code:

int x = my_other_var;

Imagine that my_other_var is now a function. What is the contents of a function? In the current C standard, you cannot copy an array, let alone a function, so this assignment would make no sense.
Now, how about we take the address of said variable?

Code:

int* x = &my_other_var;

This is intuitive. We use the address-of operator. apply similar logic to functions and we see it makes sense because functions have an address in memory where its code is placed.

This might be strict "standardese," but it follows the basic C syntax and principles.

We might also consider arrays. We can indeed create a pointer to an array. That is a pointer to an array. Incrementing it skips forward one array.
For some reason, probably convenience, it is also possible to omit the address-of operator when assigning or passing arrays. This gives us a pointer to its first element.
Does that make sense for a function? Not in the current standard.

Special syntax for things only serve to confuse people and make the language more difficult to learn and parse.

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.

2.3 Assign an address to a Function Pointer

It's quite easy to assign the address of a function to a function pointer. You simply take the name of a suitable and known function or member function. Although it's optional for most compilers you should use the address operator & infront of the function's name in order to write portable code. You may have got to use the complete name of the member function including class-name and scope-operator (::). Also you have got to ensure, that you are allowed to access the function right in scope where your assignment stands.

2.5 Calling a Function using a Function Pointer

In C you call a function using a function pointer by explicitly dereferencing it using the * operator. Alternatively you may also just use the function pointer's instead of the funtion's name. In C++ the two operators .* resp. ->* are used together with an instance of a class in order to call one of their (non-static) member functions. If the call takes place within another member function you may use the this-pointer.

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?

Originally Posted by Elysia

For some reason, probably convenience, it is also possible to omit the address-of operator when assigning or passing arrays. This gives us a pointer to its first element.
Does that make sense for a function? Not in the current standard.

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.

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.

Originally Posted by Elysia

Special syntax for things only serve to confuse people and make the language more difficult to learn and parse.

I can agree with this, but this special syntax is common and well understood. Trying to avoid it is futile.