Talk:C++ Programming/Programming Languages/Comparisons/C

Function overloading in C99
I removed the the part in bold from the list of comparisons: "C++ supports function overloading (absent in C89, allowed only for some standard library code in C99)". As far as I know, the part in bold is not true (maybe some compilers support it, but it's not part of the C99 standard, AFAIK). C99 'overloads' the trig functions by providing different names for the different versions of the functions: e.g. pow, powf, powl. This is not function overloading in the C++ sense since the names are different.

If it is re-added to the page, please include a relevant reference to the C99 spec (or otherwise valid citation) to support the fact.

--Autumnfields (talk) 10:54, 30 November 2010 (UTC)

I see the removed text was re-added. I'm almost entirely certain the text is simply not true. Function overloading is not, and has never been, part of the C language.

For example, lcc-win32 (apparently) supports function overloading, but that's a compiler that's extending the C language.

Panic2k4, I strongly (but politely) suggest that reconsider this edit.

--Autumnfields (talk) 10:54, 4 December 2010 (UTC)


 * Yes and No. What a person considers to be function overloading has a direct affect on whether C is considered to have function overloading or not. What is true is the function overloading facilities used by C++ do not exist in any C standard. ISO C does provide some type-generic macros which some people may consider to be a type of function overloading. ISO C also has allowed function parameters to not be explicitly declared, which can be used to overload functions. I can see how what was stated could be considered misleading or wrong though. --dark lama  16:31, 9 December 2010 (UTC)


 * I addressed the concern. Please see if you agree with the solution, it is a bit verbose for my liking as this is not a C book but I think it addresses the issue. --Panic (talk) 19:14, 9 December 2010 (UTC)


 * Since Panic is an official admin of this wikibook, I'm happy with whatever he likes for the final text.
 * That said, it's still my opinion that C99 does not have "function overloading" as it is defined in C++ and it is potentially confusing to imply that it does. In the spirit of good-natured discussion, please bear with my last response for a moment...
 * That said, it's still my opinion that C99 does not have "function overloading" as it is defined in C++ and it is potentially confusing to imply that it does. In the spirit of good-natured discussion, please bear with my last response for a moment...


 * Computer programming languages do have strict, formal grammars with very precisely defined terms. Ambiguity in a programming language definition is usually a major problem (and it's also why specs are so hard to read: they're supposed to leave no room for misinterpretation).  So when we're talking about "function overloading" in the context of C++, we're talking about something very specific and well-defined. It is not a "Yes and No" issue; a person either chooses to use the C++ spec's definition or make up their own definition.  I'm making the assumption that a Wikibook entitled "C++ Programming" should adopt the definition of "function overloading" as the C++ spec defines it.
 * The pre-C++0x copy of the spec I have, defines "overloading" on p209: "When two or more different declarations are specified for a single name in the same scope, that name is said to be overloaded. By extension, two declarations in the same scope that declare the same name but with different types are called overloaded declarations. Only function declarations can be overloaded; object and type declarations cannot be overloaded."
 * With the above quote in mind, type-generic macros are not functions (in fact, they're not even declarations since they're part of the preprocessor stage) - therefore, while generic macro may look like function overloading and in some cases behave like function overloading, they are not function overloading because in many other ways they're very different from function overloading (part of prepreprocessor, no type checking, not exportable as symbols in libraries, etc.). This kind of ambiguity is the very reason programmers are told to avoid macros: they look similar to functions but don't always act like them (which can cause unexpected bugs).   (...And as a quick aside, "method overloading" is an instance of "function overloading" since the C++ spec technically doesn't use the word "method" but instead calls them "member functions".)
 * One reason the above might actually matter to someone learning C++ programming is name mangling - or specifically, what that weird extern "C" thing that shows up in a lot of header files means. It is specifically because C does not (and likely never will) support function overloading, that C can produce a unmangled symbol name (i.e. makes the name used in the source code).  There's never any ambiguity in C about which function that name refers to since function names cannot be overloaded.   In C++, on the hand, because there is overloading, the parameter types need to be encoded into the symbol names...which produces the weird "mangled" names that end up in libraries and binaries (and seem unnecessarily mysterious to new programmers).  Most intermediate programmers eventually run across name mangling, and the explanation for why C++ mangles names and C doesn't is simple:  C++ supports function overloading and C does not.   To say otherwise, in my opinion, is misleading and inaccurate.
 * With the above quote in mind, type-generic macros are not functions (in fact, they're not even declarations since they're part of the preprocessor stage) - therefore, while generic macro may look like function overloading and in some cases behave like function overloading, they are not function overloading because in many other ways they're very different from function overloading (part of prepreprocessor, no type checking, not exportable as symbols in libraries, etc.). This kind of ambiguity is the very reason programmers are told to avoid macros: they look similar to functions but don't always act like them (which can cause unexpected bugs).   (...And as a quick aside, "method overloading" is an instance of "function overloading" since the C++ spec technically doesn't use the word "method" but instead calls them "member functions".)
 * One reason the above might actually matter to someone learning C++ programming is name mangling - or specifically, what that weird extern "C" thing that shows up in a lot of header files means. It is specifically because C does not (and likely never will) support function overloading, that C can produce a unmangled symbol name (i.e. makes the name used in the source code).  There's never any ambiguity in C about which function that name refers to since function names cannot be overloaded.   In C++, on the hand, because there is overloading, the parameter types need to be encoded into the symbol names...which produces the weird "mangled" names that end up in libraries and binaries (and seem unnecessarily mysterious to new programmers).  Most intermediate programmers eventually run across name mangling, and the explanation for why C++ mangles names and C doesn't is simple:  C++ supports function overloading and C does not.   To say otherwise, in my opinion, is misleading and inaccurate.
 * One reason the above might actually matter to someone learning C++ programming is name mangling - or specifically, what that weird extern "C" thing that shows up in a lot of header files means. It is specifically because C does not (and likely never will) support function overloading, that C can produce a unmangled symbol name (i.e. makes the name used in the source code).  There's never any ambiguity in C about which function that name refers to since function names cannot be overloaded.   In C++, on the hand, because there is overloading, the parameter types need to be encoded into the symbol names...which produces the weird "mangled" names that end up in libraries and binaries (and seem unnecessarily mysterious to new programmers).  Most intermediate programmers eventually run across name mangling, and the explanation for why C++ mangles names and C doesn't is simple:  C++ supports function overloading and C does not.   To say otherwise, in my opinion, is misleading and inaccurate.


 * (And as for the new text now being too verbose, I agree! My original edit was solely to remove the misleading text and keep it simpler!)
 * Anyway, apologies if this was a bothersome diversion. I'm a bit of a stickler for using the formal definitions when there actually is a formal definition.  Hope this was all taken as a constructive discussion.  That said, I do understand the general point about type-generic macros, and also I'm perfectly fine with the wikibook text being left as Panic wants it since he's the admin.
 * -- Autumnfields (talk) 12:23, 11 December 2010 (UTC)
 * -- Autumnfields (talk) 12:23, 11 December 2010 (UTC)
 * -- Autumnfields (talk) 12:23, 11 December 2010 (UTC)


 * I'm not an admin, at best I'm the contributor that has worked the longer and in greater quantity to this project, because of that I claim authorship but no control on how it evolves, that is a community decision especially but not restricted for those working on it (a group that I often refer as the book community), and I hope you will be inclined in participating further. Constructive criticism is welcomed and you do have a say on the subject.
 * I fully understand your issue, but my view is similar to what Darklama describes above, in any case see if you can agree to the last change, it covers the valid points you make above, but also makes any C zealot happy without getting into much of the details.
 * If you still object, do remove the references to the C standards and make it strict negative as the purpose of the page is not to cover the minutiae of C. I can't even remember why or when that was added to the text but it has been there at least since I moved it from the parent page in 2007. In any case it would be great to cover the subject in the C Programming book in greater detail, my believe is that some of the functionalities of C++ can be (with work and added complexity) replicated with C, much of the changes in C have been just that a move to implement some of the C++ features... --Panic (talk) 13:13, 11 December 2010 (UTC)


 * I can think of one possible way C could be said to have function overloading capabilities by C++'s definition that I hadn't mentioned yet:
 * union callback { int (*c)(int); void (*d)(void); void (*e)(char*); } caller;
 * The above is two or more declarations with a single name.
 * I agree with you though Autumnfields, both for simplicity and avoiding the incredible nuisances of comparing ISO C++'s definition with C. There are many websites, newsgroup threads, and forum postings dedicated to the topic of how C can do anything that C++ can do. None of it is particularly relevant to learning C++ or C though. People who want to learn the similarities and differences between the two languages might benefit from such detailed knowledge, but it could fill an entire book. I've heard C++ programs were in the beginning, when C++ was still being referred to as "C with Classes", compiled with a C compiler without having had to hack or modify the compiler. --dark lama  14:01, 11 December 2010 (UTC)


 * Thanks for the discussion, guys. (And I never thought about using a union in C for that purpose...interesting, thought technically there is one memory address but there are still four compiler symbol names - each with a distinct data type: caller, caller.c, caller.d, caller.e; a single memory address is overloaded with multiple typed-names, but no single name refers to multiple distinct objects.  There's no way - that I can think of - to get a C compiler to 'choose' the right one for you.)
 * If it were up to me, I think this would be a great case for using a footnote. Simply make the bullet "C++ supports function overloading [1]" where the footnote is something like, "[1] C99 does support type-generic macros, etc., etc."...because as darklama noted, C is a generic system-programming language, so it's possible to do anything - it's just a matter of how "natively" it is supported (and, yup, the original C++ compiler was called C Front since it was just a front-end on a C compiler).  I don't know if that would fit the book stylistically, though - since there don't seem to be many other footnotes in the wikibook.   -- Autumnfields (talk) 14:51, 11 December 2010 (UTC)


 * I have made a real effort not to use footnotes, to defense of the option is simple, the software and the print versions to my understanding and experience do no respect "page" sizes, so the footnote is only a footnote on this specific web page version (complete), it also increases maintenance costs in text changes. My personal view, one that has been kept in the work, is that there are viable alternatives, if a note is relevant enough to be made (for instance we do have a NOTE template). In this specific case the information is important mostly to satisfy anyone that would see a full negation as an attempt belittle another language, or is more interested in C than C++. We have made an effort on these section of the book to pass the idea that there isn't a perfect language, that C++ is not superior by itself it depends in the context and way it is used, but going further than a few lines is detail about another language, without direct comparison to C++ would be outside of the scope of the book), for instance the Java comparison to me is a bit too extensive.
 * That is also the reason I think that covering the subject on the C Programming book would help as then we could just add a wikilink to the relevant section. IIRC that book started a similar section but I haven't examined it recently... --Panic (talk) 15:26, 11 December 2010 (UTC)


 * Probably could describe C++'s overloading in terms of one name, one scope, and different addresses? Using another C example can help to explain why I include one scope:
 * file_a.c: "static void callback(void) { ... }", file_b.c: "static int callback(int what) { ... }", and file_c.c: "static void callback(char *data) { ... }". Each use a function by the same name that will be have different addresses, but also each is within a different file scope.
 * BTW the type-generic macros are the only example I gave that are specific to C99. The rest is valid C89 AFAIK. I haven't looked at C99 lately, but there is also a chance that the not explicitly declaring a function's parameters approach is valid with C89 and is not any longer with C99. --dark lama  13:16, 12 December 2010 (UTC)

"C++ does not require use of macros..."
"C++ does not require use of macros and careful information-hiding and abstraction for code portability."

While I'm not exactly sure what this sentence is supposed to say, I think that in its current state it's not entirely correct. All the standard library functions of both languages work on every platform they've been ported to (I guess that's what makes them "standard") and macros are not required to use these capabilities in either language. Both languages are designed to be cross-platform. It is true that because C struct members can't be private, macros are one (the only?) way to implement information hiding in C, but this isn't required. One of the tenets of C++ is "careful information hiding", so perhaps it shouldn't be portrayed as a bad thing here. Also, isn't abstraction the only way to achieve portability? As an OOP language, C++ is more abstracted than C, and they both use layers of abstraction which build on the OS's abstraction of the hardware itself. So...is there some meaning to this sentence that I'm missing? Jfmantis (discuss • contribs) 03:57, 2 December 2011 (UTC)


 * It states that in comparison to C, C++ does not require the use of macros (for/and) information-hiding and abstraction for code portability.
 * It probably could have been better worded.
 * It does not refer to the standard language as you imply but in the normal and common use of the language. Macros are avoided in C++ on the other hand macros are extremely common in C, and specifically required to provide the C language the capability necessary both for information-hiding and abstraction, the last one a needed to make C code portable.
 * On the last part you get off the topic, the macro specific domain. C++ does not depend on macros for any abstraction, C++'s creator at some point in time, IIRC, even stated that if he could he would have removed the feature, but due to C heavy reliance of macros they had to stay in (something on these lines).
 * I notice that looking into the edit history that it was a contribution from me and had a misspell (I do sporadic edits, most times I get back to them and reread to see if they are ok other I completely forget about them, but you have found one edit that for the life of me I can't see or remember what was my intention (here), this one left me really puzzled, I have no explanation to it, the best thing I can come up with is some crossedit, I could have intended to edit another similar page.
 * I will give the rewording a shot, it will probably be a longer phrase. --Panic (discuss • contribs) 04:50, 2 December 2011 (UTC)


 * The odd parallel construction confused me: I read it as "C++ does not require use of macros", "C++ does not require use of careful information-hiding", and "C++ does not require use of abstraction". The way you've rewritten it makes much more sense. But I still have to disagree with the statement "C++ does not require use of macros". Choosing a file at random from the libstdc++ source, I see that the bitset header file is rife with macros. It might be safer to say that C++ doesn't rely on macros for OOP, which is certainly true. Jfmantis (discuss • contribs) 05:40, 2 December 2011 (UTC)


 * Implementation of the standards are "vendor" specific, if you look on your example you could come up with alternatives that do not use macros. In any case just because some prefer to use them does not make them an absolute necessity, like in C. Most C++ code that uses macros has a high probability of having been written by an programmer that is at home in C, especially today, the use of macros in C++ is generally accepted as a bad practice and are actively avoided (but in C++ you can use whatever you like and does the job, it all falls to fallowing conventions). --Panic (discuss • contribs) 05:53, 2 December 2011 (UTC)