Live data from Hacker News

Function overloading in C

gist.github.com

21–30 of 57 posts

Re: Function overloading in C

#21
post #12

Earlier quoted context omitted.

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…

> I want to pass a function as a pointer even though it is overloaded. C++ supports that.

That's his point: C _Generic and C++ are not the same. Which one is better was not his point, just that they're different.

Re: Function overloading in C

#22

Interesting approach, this is how I do it: cc -std=c++14 No preprocessor necessary! Also it checks the type of both arguments.

Indeed. No need to use "complex" features like RAII/RTTI/exceptions. Generally, I see features like classes, overloading and templates as "compatible" with C-style coding.

Re: Function overloading in C

#23

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).

It's hard to say what's more powerful. Certainly templates involve more computation, but _Generic can do some things templates can't (for good and for ill) and vice-versa.

Re: Function overloading in C

#24

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.

With a couple of minor exceptions, C++ is a superset of C.

Re: Function overloading in C

#25

    #define add(a, b) _Generic(a, int: addi, char*: adds)(a, b)
Just because you can doesn't mean you should. Someday, someone will have to read that code. Note that when "add" returns a string, it's done an allocation, but for the integer case, it hasn't called "malloc". Now you'll now need to know the type to get rid of it.

Back in C99, generic trig functions were put in to make the number-crunching people happy. After all, FORTRAN has them. Everybody was tired of different versions of math libraries for "float" and "double". Then in C11, the mechanism behind that, "_Generic", was exposed. Now, anybody can use it. But, probably, they shouldn't. [1]

[1] http://www.robertgamble.net/2012/01/c11-generic-selections.h...

Re: Function overloading in C

#26

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…

This is like going back to y2k and saying 'well if you want double-slash comments you should use the version of c that already has it, namely c++98, and it was a mistake to add it to c'

Re: Function overloading in C

#27

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 not a substitute, it's for some reasons having nothing to do with language or philosophy, such as not having a C++ compiler for the given chip.

Re: Function overloading in C

#28

Earlier quoted context omitted.

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…

> I want to pass a function as a pointer even though it is overloaded. C++ supports that. That's his point: C _Generic and C++ are not the same. Which one is better was not his point, just that they're different.

> Which one is better was not his point, ...

The comment is loaded with judgment, and the word "better" actually occurs.

Re: Function overloading in C

#29

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).

Unlikely, unless they need it for C++. Even C99 only gets better when they need parts of it for C++ anyways, and is not developed further.

Re: Function overloading in C

#30

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#.

C++ incorporates nearly all of C99 directly, save for VLAs, restrict, designated initializers, and a lot of small stuff that won't affect any modern-ish C code (e.g., no implicit int). VLAs and restrict are explicitly not in C++ because they're somewhat broken (C++14 did add "dynamic arrays" which are VLA-lite, and there's work on a better restrict-like functionality, cf. https://isocpp.org/files/papers/N3988.pdf), while designated initializers does not mesh well with C++ semantics.

In practice, then, C++ without RTTI, exceptions, or the standard library is basically a strict superset of C and C code compiled as such will tend to be legal and identical in semantics. The same cannot be said for C# or Java. Given that C++ has some rather useful features (most notably, the ability to guarantee cleanup even in the face of inattentive developers), the only real valid reason to not be using C++ instead of C is if there's no C++ compiler.

Post reply on HN