Live data from Hacker News

Function overloading in C

gist.github.com

11–20 of 57 posts

Re: Function overloading in C

#11
post #8

This whole _Generic stuff is a mistake. There is already a descendant dialect of C which has nice overloading, namely C++. Analogy: imagine some people aren't happy with the new Fortran. Fortran 66 is the best language ever, and the only flavor of Fortran anyone should use ... except: they like a couple of features from Fortran 2008 and Fortran 90. So, they whip out the Fortran 66 standard and fork it to create "Fort…

You comment is a basically a very good example of a strawman argument. Counterargument that destroys your entire premise: C's revisions( note that revisions are not flavors or separate languages ) don't fork.

> You comment is a basically a very good example of a strawman argument.

Is that so? My apologies. What argument have I reduced to a strawman, and what is the proper strong version?

> note that revisions are not flavors or separate languages

By what definition of "separate"?

C11 is in fact a different language that is very similar (and explicitly based upon) C99, and the same holds between C99 and C90.

These can be said to be dialects. But by the same token (no pun intended), C++ is also a C dialect.

Re: Function overloading in C

#12

This whole _Generic stuff is a mistake. There is already a descendant dialect of C which has nice overloading, namely C++. Analogy: imagine some people aren't happy with the new Fortran. Fortran 66 is the best language ever, and the only flavor of Fortran anyone should use ... except: they like a couple of features from Fortran 2008 and Fortran 90. So, they whip out the Fortran 66 standard and fork it to create "Fort…

But the OP title is misleading, this isn't function overloading at all. It's macro overloading. Subtle but important difference. For example, you can't pass the OP's "add" around as a function pointer. You can't declare its prototype in an outside file (leaving the linker to link it in) without putting its full definition in said outside file. Etc.

It also gives, IMO, better error messages than C++. If we take OP's code and change a and b from int to long, we get:

    test.c:20:24: error: controlling expression type 'long' not compatible with any generic association type
    printf("%d\n", add(a, b)); // 3
                       ^
    test.c:16:28: note: expanded from macro 'add'
    #define add(a, b) _Generic(a, int: addi, char*: adds)(a, b)
This is better than the situation in C++ where it would say the function does not exist, and then go through every function with that name (possibly quite a lot) and say why each one doesn't work.

Re: Function overloading in C

#13

Works with Clang and GCC. Obviously, Visual Studio doesn't work (they have almost complete support for C99 though, so maybe in a few years they will include C11 support).

Only library-wise: the reason for _Generic is missing, exists but can't be used. Some lesser used and sometimes useful C99 language features/changes are still unimplemented. Even excluding features C11 made optional (for good reasons) like VLA or complex.

Re: Function overloading in C

#14
post #4

I was expecting something interesting. Generic selection is built into the language: http://en.cppreference.com/w/c/language/generic

I recommend reading the notes section and better yet the following blog entry before one decides to use _Generic with less trivial types:

https://gustedt.wordpress.com/2015/05/11/the-controlling-exp...

Re: Function overloading in C

#16
post #12

This whole _Generic stuff is a mistake. There is already a descendant dialect of C which has nice overloading, namely C++. Analogy: imagine some people aren't happy with the new Fortran. Fortran 66 is the best language ever, and the only flavor of Fortran anyone should use ... except: they like a couple of features from Fortran 2008 and Fortran 90. So, they whip out the Fortran 66 standard and fork it to create "Fort…

But the OP title is misleading, this isn't function overloading at all. It's macro overloading. Subtle but important difference. For example, you can't pass the OP's "add" around as a function pointer. You can't declare its prototype in an outside file (leaving the linker to link it in) without putting its full definition in said outside file. Etc. It also gives, IMO, better error messages than C++. If we take OP's c…

I want to pass a function as a pointer even though it is overloaded. C++ supports that. For instance if we do:

   int (*p)(int, int) = add;
overload resolution kicks in there.

I want detailed error messages about overload resolution. Maybe not all the time: give me the executive summary ("no suitable overload of add was found") and the details if I specify some "-Woverload-detailed" option or whatever. That's a quality of implementation matter; neither ISO C nor ISO C++ spell out what diagnostics should look like and how detailed they should be.

Token-level macros are hacky cruft that shouldn't be used as the development bed for new features, period. All this stuff ignores 35 years of progress in the C dialect scene alone, not to mention 60 years of progress in general.

Above, add isn't even what is understood in computing as a "first class function". If we make it into some hacky macro, we are taking away even that second class status away from it.

Re: Function overloading in C

#17
post #8

Earlier quoted context omitted.

You comment is a basically a very good example of a strawman argument. Counterargument that destroys your entire premise: C's revisions( note that revisions are not flavors or separate languages ) don't fork.

> You comment is a basically a very good example of a strawman argument. Is that so? My apologies. What argument have I reduced to a strawman, and what is the proper strong version? > note that revisions are not flavors or separate languages By what definition of "separate"? C11 is in fact a different language that is very similar (and explicitly based upon) C99, and the same holds between C99 and C90. These can be s…

All of C's revisions retain a coherent philosophy that is incompatible with the philosophy of C++. When C is the right tool, C++ is no more a substitute than Java or C#.

Re: Function overloading in C

#18
This is a very simple example. It only checks the type of the first parameter. _Generic can operate on all parameters, it just leads to an exponential increase of mess for each additional parameter handled.

While I like _Generic in C11, there is no doubt that it is not as powerful or handy as Templates (this coming from someone who does not really enjoy Cxx templates).

Re: Function overloading in C

#19

Earlier quoted context omitted.

> You comment is a basically a very good example of a strawman argument. Is that so? My apologies. What argument have I reduced to a strawman, and what is the proper strong version? > note that revisions are not flavors or separate languages By what definition of "separate"? C11 is in fact a different language that is very similar (and explicitly based upon) C99, and the same holds between C99 and C90. These can be s…

All of C's revisions retain a coherent philosophy that is incompatible with the philosophy of C++. When C is the right tool, C++ is no more a substitute than Java or C#.

>When C is the right tool, C++ is no more a substitute than Java or C#

When C is the right tool, assuming that it ever truly is, C++ is a vastly better substitute than Java or C#. C++ uses the same machine model as C; Java and C# do not.

Re: Function overloading in C

#20

This whole _Generic stuff is a mistake. There is already a descendant dialect of C which has nice overloading, namely C++. Analogy: imagine some people aren't happy with the new Fortran. Fortran 66 is the best language ever, and the only flavor of Fortran anyone should use ... except: they like a couple of features from Fortran 2008 and Fortran 90. So, they whip out the Fortran 66 standard and fork it to create "Fort…

C++ is not just a newer version of C with newer features. It is a completely disparate language. That's not a bad thing (tradition is not always good), but to say that if you want generics, you should just leave C behind is a little misguided.
Post reply on HN