Function Overloading

[zeus]

I know function overloading is not supported in C.
I have a few questions about this:
1. Why? is it from technical reasons? if so, which?
2. why wasn't it introduced to the ANSI?
3. Is there any C implementation supporting this feature?

I assume some of you will claim that there is no need in function
overloading, so I would like to know your arguments too.

Thanks,
zeus

 

[Joona I Palaste]

I know function overloading is not supported in C.
I have a few questions about this:
1. Why? is it from technical reasons? if so, which?
2. why wasn't it introduced to the ANSI?
3. Is there any C implementation supporting this feature?

I assume some of you will claim that there is no need in function
overloading, so I would like to know your arguments too.

Function overloading is just compile-time syntactic sugar for functions
with different names. It does not add any computational power or ease
whatsoever.

 

[Allan Bruce]

I know function overloading is not supported in C.
I have a few questions about this:
1. Why? is it from technical reasons? if so, which?
2. why wasn't it introduced to the ANSI?
3. Is there any C implementation supporting this feature?

I assume some of you will claim that there is no need in function
overloading, so I would like to know your arguments too.

Thanks,
zeus

Function overloading is supported in C. Valid overloaded functions are
those that have different arguements, and possible different return types,
however an invalid overloaded set of functions is those that differ only by
return type, i.e.

/* Valid overlaoded functions */
int DoSomething(void);
int DoSomething(int);
double DoSomething(double);
void DoSomething(char, int, long);

/* invalid */
doulbe DoSomething(void); /* already have a void arg above but with int
returned */

HTH
Allan

 

[CBFalconer]

Function overloading is supported in C. Valid overloaded functions
are those that have different arguements, and possible different
return types, however an invalid overloaded set of functions is
those that differ only by return type, i.e.

/* Valid overlaoded functions */
int DoSomething(void);
int DoSomething(int);
double DoSomething(double);
void DoSomething(char, int, long);

/* invalid */
doulbe DoSomething(void); /* already have a void arg above but with
int returned */

Utter nonsense. You are thinking of C++, which is another
language. In point of fact C++ doesn't even have overloading;
what it has is a means of faking it by adorning function names
with something describing their parameters, and doing this behind
your back. By the time the C++ code reaches the linking stage all
overloading is resolved to distinct function names. This creates
headaches for symbolic debuggers and other things since the faking
mechanism is not standardized.

 

[Allan Bruce]

Utter nonsense. You are thinking of C++, which is another
language. In point of fact C++ doesn't even have overloading;
what it has is a means of faking it by adorning function names
with something describing their parameters, and doing this behind
your back. By the time the C++ code reaches the linking stage all
overloading is resolved to distinct function names. This creates
headaches for symbolic debuggers and other things since the faking
mechanism is not standardized.

my compiler must allow it in that case - I`ve never had a problem using
overloading before
Allan

 

[Joona I Palaste]

my compiler must allow it in that case - I`ve never had a problem using
overloading before

Then you are either compiling as C++ or with non-standard extensions.
What is your compiler and how are you invoking it?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
- Groucho Marx

 

[Chris Torek]

I know function overloading is not supported in C.

I have a few questions about this:
1. Why? is it from technical reasons? if so, which?

2. why wasn't it introduced to the ANSI?

3. Is there any C implementation supporting this feature?

See <tgmath.h>.

 

[Stephen Sprunk]

See <tgmath.h>. Since C (at least C99) *does* have function
overloading, it is impossible to say why it lacks it.

<tgmath.h> uses a lot of trickery with macros to implement a very limited
set of functions that accept variably-typed arguments. It is not
overloading in the sense that C++ people use the term.

S

 

[Ben Pfaff]

<tgmath.h> uses a lot of trickery with macros to implement a very limited
set of functions that accept variably-typed arguments.

You're probably referring to some particular implementation. The
C standard only specifies the <tgmath.h> interfaces, not how it
is implemented.

 

[Stephen Sprunk]

You're probably referring to some particular implementation. The
C standard only specifies the <tgmath.h> interfaces, not how it
is implemented.

True, the type-generic macros could be defined as calls to overloaded
built-in functions or such, but the point remains that this is not a general
example of Standard C supporting function overloading. Even macro
overloading is a stretch.

S

 

[Keith Thompson]

Utter nonsense. You are thinking of C++, which is another
language.
Agreed.

In point of fact C++ doesn't even have overloading;
what it has is a means of faking it by adorning function names
with something describing their parameters, and doing this behind
your back. By the time the C++ code reaches the linking stage all
overloading is resolved to distinct function names. This creates
headaches for symbolic debuggers and other things since the faking
mechanism is not standardized.

<OT>
What you're describing is the manner in which overloading is
(typically) implemented. There's nothing more or less "fake" about
the described implementation technique than any other, as long as the
effect from the programmer's point of view is the same. (The behavior
of symbol debuggers is outside the scope of the language definition.)

I don't know (or much care) whether the common "name mangling"
implementation is actually required by the C++ standard.
</OT>

 

[CBFalconer]

my compiler must allow it in that case - I`ve never had a problem
using overloading before

Then you are not using a C compiler. However, as Chris Torek
pointed out elsethread, my statement is not strictly true, in that
C99 provides effectively overloaded macros in <tgmath.h>. These
are macros, not functions.

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Speaking for myself, and not having read any of the other responses, here's my
answers to your questions.

zeus wrote:
| I know function overloading is not supported in C.
| I have a few questions about this:
| 1. Why?
Why do you think that function overloading /should/ be supported in C?
My guess that function overloading is not supported in C for the same reasons
that they don't support roof racks for 747s; it's an unnecessary addition that
can have destructive impacts.

| is it from technical reasons? if so, which?
Probably, no technical reason other than "function overloading isn't seen to be
necessary in order to write C programs".

| 2. why wasn't it introduced to the ANSI?
See above.


| 3. Is there any C implementation supporting this feature?
If there are, then their conformance is "implementation defined".


| I assume some of you will claim that there is no need in function
| overloading, so I would like to know your arguments too.

Function overloading is unnecessary from the program pov, and can be overly
confusing from the developers pov. It is unnecessary.

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAlEhqagVFX4UWr64RApHmAKD1ZpfWJBooQbpeq6tkuNJhaJYkzgCgrB9N
3FZ9dlkfXMDCjKpxgATN9/w=
=t1oI
-----END PGP SIGNATURE-----

 

[Chris Torek]

You're probably referring to some particular implementation. The
C standard only specifies the <tgmath.h> interfaces, not how it
is implemented.

The C99 draft I use *does* say that the <tgmath.h> names (sin,
acos, etc.) are macros. As such, one could presumably #include
the header, then #undef them (or some of them) to un-do the
effect of including <tgmath.h>.

The principle, however, is still there: if <tgmath.h> can
overload a name like "sin", so that it actually calls sinf()
or sinl() if the provided parameter is a float or long double
-- or even fancier, call csin() when invoked on a complex
value -- then C99 does provide function overloading, however
limited.

It seems particularly odd (and typically committee-ish) to provide
a limited subset of some facility, rather than pursuing the idea
to its end, whittling it down to the useful nub, and providing
*that* instead. In other words, if the endpoint of the idea is to
allow a single "external name" of a function (or function-like
macro) to map to multiple "internal names" based on the parameter
types, it would make more sense to provide a method by which anyone
-- not just the implementor -- can do this. Only if there is
something inherently implementation-specific about it is there
sufficient justification for granting this ability only to the
implementor. That, however, is a topic for comp.std.c, not comp.lang.c.

 

[Richard Bos]

The principle, however, is still there: if <tgmath.h> can
overload a name like "sin", so that it actually calls sinf()
or sinl() if the provided parameter is a float or long double
-- or even fancier, call csin() when invoked on a complex
value -- then C99 does provide function overloading, however
limited.

Quibble: I would say that it provides some overloaded functions (ok,
some overloaded macros). What it does not provide is function
overloading - that is, it does not provide a standard mechanism for
overloading functions.

Richard

 

[Dan Pop]

It seems particularly odd (and typically committee-ish) to provide
a limited subset of some facility, rather than pursuing the idea
to its end, whittling it down to the useful nub, and providing
*that* instead.

It's obvious that <tgmath.h> was motivated by the desire to bring C
closer to Fortran for number crunching purposes (Fortran supported this
feature for ages). A large amount of the C99 additions serve this
purpose.

And I wouldn't call it function overloading, it's merely a well documented
source code transformation performed by the C99 preprocessor. Trivial to
implement using GNU C's typeof operator and block expressions, if we drop
the complex support:

#define sin(x) ({typeof(x) res = 0; \
switch (sizeof(typeof(x))) { \
case sizeof(long double): res = sinl(x); break; \
case sizeof(double): res = sin(x); break; \
case sizeof(float): res = sinf(x); break; \
} \
res;})

Does this mean that GNU C supports function overloading?

Dan

 

[Stefan Farfeleder]

And I wouldn't call it function overloading, it's merely a well documented
source code transformation performed by the C99 preprocessor. Trivial to
implement using GNU C's typeof operator and block expressions, if we drop
the complex support:

#define sin(x) ({typeof(x) res = 0; \
switch (sizeof(typeof(x))) { \
case sizeof(long double): res = sinl(x); break; \
case sizeof(double): res = sin(x); break; \
case sizeof(float): res = sinf(x); break; \
} \
res;})

This implementation doesn't handle integer arguments.

 

[Dan Pop]

This implementation doesn't handle integer arguments.

It doesn't handle complex arguments, either, but it makes the point it
was supposed to make: doing tricks with macros doesn't really count as
function overloading.

Dan

 

[Chris Torek]

It's obvious that <tgmath.h> was motivated by the desire to bring C
closer to Fortran for number crunching purposes (Fortran supported this
feature for ages). A large amount of the C99 additions serve this
purpose.

Indeed, this seems to be the not-very-well-hidden agenda behind
the <tgmath.h> monstrosities. My point with the aside was not so
much "these are bad" (although they are) but rather "these are an
ugly solution to a political problem, namely, pleasing some
sub-group."

And I wouldn't call it function overloading, it's merely a well documented
source code transformation performed by the C99 preprocessor. Trivial to
implement using GNU C's typeof operator and block expressions, if we drop
the complex [and integer] support:

#define sin(x) ({typeof(x) res = 0; \
switch (sizeof(typeof(x))) { \
case sizeof(long double): res = sinl(x); break; \
case sizeof(double): res = sin(x); break; \
case sizeof(float): res = sinf(x); break; \
} \
res;})

Does this mean that GNU C supports function overloading?

GNU C does indeed support "overloading" via macros, in a generalized
form that handles the specifics required for the ugly C99 version.
(The actual macro needs to use __builtin_classify_type so that it
can handle integers and complex arguments.)

Perhaps a better way to phrase it is this. Aside from the exposure
as a macro (which I grant is a very large "aside"), the sequence:

#include <tgmath.h>

float a; long double b; double complex c; int d;
...
a = sin(arg); b = sin(arg); c = sin(arg); d = sin(arg);

*looks* (syntactically) like an overloaded function, and *acts*
(semantically) like an overloaded function -- so what should we
call it? Overloaded functions are already just syntactic sugar.
C99's bizarre macros are perhaps more "syntactic cyclamates"[%],
and calling them "overloaded functions" might be a bit overreaching
-- they are really "overloaded macros" -- but their underlying idea
is the same.

[% see <http://www.foodcomm.org.uk/press_97_cyclams.htm> (the
studies are not conclusive, but still...)]

 

[Guillaume]

#define sin(x) ({typeof(x) res = 0; \

It doesn't handle complex arguments, either, but it makes the point it
was supposed to make: doing tricks with macros doesn't really count as
function overloading.

Indeed, but something worse is intriguing: the macro expands to an
instruction block. I don't see how a block (some instructions surrounded
by braces { }) can be an R-value? Seems to be a GCC trick, but
apparently forbidden by the standard (or did I miss anything here?).

I tried, and it works with GCC, but we still get a warning:
"warning: ISO C forbids braced-groups within expressions".

Anyway. Does it qualify as a form of function overloading? Not quite.
It's not the fact that it's a macro trick (and not even a standard one,
to begin with), but there is worse. The type of x is only checked
against its "size", which of course may lead to all kinds of errors.

If "long double" has the same size as "double", it won't compile.
And checking a type based only on size criteria is certainly not
sufficient to qualify the whole thing as proper function overloading.
(Not to mention that a macro isn't quite like a function and
nasty side-effects can occur if the argument is itself an expression
that may have side-effects.)