Function Overloading

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

zeus <zohar@sheernetworks.com> scribbled the following:[color=blue]
> 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?[/color]
[color=blue]
> I assume some of you will claim that there is no need in function
> overloading, so I would like to know your arguments too.[/color]

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

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"All that flower power is no match for my glower power!"
- Montgomery Burns

"zeus" <zohar@sheernetworks.com> wrote in message
news:f238fff9.0405010214.5c70e2d0@posting.google.c om...[color=blue]
> 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[/color]

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

Allan Bruce wrote:[color=blue]
> "zeus" <zohar@sheernetworks.com> wrote in message
>[color=green]
>> 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.[/color]
>
> 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 */[/color]

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.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:40939E8C.7CFED78F@yahoo.com...[color=blue]
> Allan Bruce wrote:[color=green]
> > "zeus" <zohar@sheernetworks.com> wrote in message
> >[color=darkred]
> >> 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.[/color]
> >
> > 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 */[/color]
>
> 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.
>[/color]

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

Allan Bruce <allanmb@takeawayf2s.com> scribbled the following:[color=blue]
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> news:40939E8C.7CFED78F@yahoo.com...[color=green]
>> Allan Bruce wrote:[color=darkred]
>> > "zeus" <zohar@sheernetworks.com> wrote in message
>> >> 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 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 */[/color]
>>
>> 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.[/color][/color]
[color=blue]
> my compiler must allow it in that case - I`ve never had a problem using
> overloading before[/color]

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

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- 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

In article <f238fff9.0405010214.5c70e2d0@posting.google.com >
zeus <zohar@sheernetworks.com> writes:[color=blue]
>I know function overloading is not supported in C.[/color]

Not in general, but C99 has <tgmath.h>.
[color=blue]
>I have a few questions about this:
>1. Why? is it from technical reasons? if so, which?[/color]

See <tgmath.h>. Since C (at least C99) *does* have function
overloading, it is impossible to say why it lacks it.
[color=blue]
>2. why wasn't it introduced to the ANSI?[/color]

See <tgmath.h>.
[color=blue]
>3. Is there any C implementation supporting this feature?[/color]

See <tgmath.h>. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

"Chris Torek" <nospam@torek.net> wrote in message
news:c710d405bv@news2.newsguy.com...[color=blue]
> In article <f238fff9.0405010214.5c70e2d0@posting.google.com >
> zeus <zohar@sheernetworks.com> writes:[color=green]
> >I know function overloading is not supported in C.[/color]
>
> Not in general, but C99 has <tgmath.h>.
>[color=green]
> >I have a few questions about this:
> >1. Why? is it from technical reasons? if so, which?[/color]
>
> See <tgmath.h>. Since C (at least C99) *does* have function
> overloading, it is impossible to say why it lacks it.[/color]

<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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

"Stephen Sprunk" <stephen@sprunk.org> writes:
[color=blue]
> <tgmath.h> uses a lot of trickery with macros to implement a very limited
> set of functions that accept variably-typed arguments.[/color]

You're probably referring to some particular implementation. The
C standard only specifies the <tgmath.h> interfaces, not how it
is implemented.
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton

"Ben Pfaff" <blp@cs.stanford.edu> wrote in message
news:87fzajyedi.fsf@blp.benpfaff.org...[color=blue]
> "Stephen Sprunk" <stephen@sprunk.org> writes:
>[color=green]
> > <tgmath.h> uses a lot of trickery with macros to implement a very[/color][/color]
limited[color=blue][color=green]
> > set of functions that accept variably-typed arguments.[/color]
>
> You're probably referring to some particular implementation. The
> C standard only specifies the <tgmath.h> interfaces, not how it
> is implemented.[/color]

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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

CBFalconer <cbfalconer@yahoo.com> writes:
[...][color=blue]
> Utter nonsense. You are thinking of C++, which is another
> language.[/color]

Agreed.
[color=blue]
> 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.[/color]

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

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Allan Bruce wrote:[color=blue]
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message[color=green]
>> Allan Bruce wrote:[color=darkred]
>>> "zeus" <zohar@sheernetworks.com> wrote in message
>>>
>>>> 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 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 */[/color]
>>
>> 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.
>>[/color]
>
> my compiler must allow it in that case - I`ve never had a problem
> using overloading before[/color]

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.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

iD8DBQFAlEhqagVFX4UWr64RApHmAKD1ZpfWJBooQbpeq6tkuN JhaJYkzgCgrB9N
3FZ9dlkfXMDCjKpxgATN9/w=
=t1oI
-----END PGP SIGNATURE-----

>"Stephen Sprunk" <stephen@sprunk.org> writes:[color=blue][color=green]
>> <tgmath.h> uses a lot of trickery with macros to implement a very limited
>> set of functions that accept variably-typed arguments.[/color][/color]

In article <news:87fzajyedi.fsf@blp.benpfaff.org>
Ben Pfaff <blp@cs.stanford.edu> writes:[color=blue]
>You're probably referring to some particular implementation. The
>C standard only specifies the <tgmath.h> interfaces, not how it
>is implemented.[/color]

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek <nospam@torek.net> wrote:
[color=blue]
> 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.[/color]

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

In <c71hho0t71@news1.newsguy.com> Chris Torek <nospam@torek.net> writes:
[color=blue]
>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.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

On 2004-05-11, Dan Pop <Dan.Pop@cern.ch> wrote:
[color=blue]
> 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:[/color]
[color=blue]
> #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;})[/color]

This implementation doesn't handle integer arguments.

--
Stefan Farfeleder

In <40a0f08a$0$33210$3b214f66@tunews.univie.ac.at> Stefan Farfeleder <stefan@fafoe.narf.at> writes:
[color=blue]
>On 2004-05-11, Dan Pop <Dan.Pop@cern.ch> wrote:
>[color=green]
>> 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:[/color]
>[color=green]
>> #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;})[/color]
>
>This implementation doesn't handle integer arguments.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

>In <c71hho0t71@news1.newsguy.com> Chris Torek <nospam@torek.net> writes:[color=blue][color=green]
>>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.[/color][/color]

In article <news:c7qn2s$jrj$1@sunnews.cern.ch> Dan Pop <Dan.Pop@cern.ch>
replies:[color=blue]
>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.[/color]

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."
[color=blue]
>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?[/color]

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...)]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

>>> #define sin(x) ({typeof(x) res = 0; \[color=blue][color=green][color=darkred]
>>> 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;})[/color]
>>
>>This implementation doesn't handle integer arguments.[/color]
>
> 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.[/color]

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

Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
[color=blue][color=green][color=darkred]
>>>> #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.[/color]
>> 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.[/color]
>
> 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?).[/color]

Dan Pop was trying to make a point, not present standard C code.
The above is not standard C code.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman

In <c7rdc201iqo@news1.newsguy.com> Chris Torek <nospam@torek.net> writes:
[color=blue]
>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.)[/color]

Does __builtin_classify_type count as a GNU C feature, or is it merely
an undocumented gcc feature?

The documented builtin relevant here is __builtin_types_compatible_p
but I'm not sure if *any* builtin qualifies as a GNU C feature.
[color=blue]
>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*[/color]

Replace <tgmath.h> by <math.h> and the look is the same, with no
resemblance to function overloading.
[color=blue]
>(semantically) like an overloaded function -- so what should we
>call it?[/color]

Whatever Fortran calls it.
[color=blue]
>Overloaded functions are already just syntactic sugar.[/color]

But it's a syntactic sugar that works behinds the scenes in an
undocumented way (the functions that get overloaded have the same name,
which is not the case with <tgmath.h>) and is available to the user to
consume it as he sees fit.

Along the same lines, C "supports" operator overloading, because
several operators perform multiple operations, according to the number
and type of their arguments.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

> Overloaded functions are already just syntactic sugar.

I agree, I think they also are syntactic sugar in C++.

I see in them more potential risks than benefits.

In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
Guillaume wrote:[color=blue][color=green]
>> Overloaded functions are already just syntactic sugar.[/color]
>
> I agree, I think they also are syntactic sugar in C++.
>
> I see in them more potential risks than benefits.[/color]

What risks do you see?

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
[color=blue]
>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>Guillaume wrote:[color=green][color=darkred]
>>> Overloaded functions are already just syntactic sugar.[/color]
>>
>> I agree, I think they also are syntactic sugar in C++.
>>
>> I see in them more potential risks than benefits.[/color]
>
>What risks do you see?[/color]

Code that becomes a hell to understand and maintain.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

In article <c7tofr$d6d$1@sunnews.cern.ch>, Dan Pop wrote:[color=blue]
> In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti
> <horpner@yahoo.com> writes:
>[color=green]
>>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>>Guillaume wrote:[color=darkred]
>>>> Overloaded functions are already just syntactic sugar.
>>>
>>> I agree, I think they also are syntactic sugar in C++.
>>>
>>> I see in them more potential risks than benefits.[/color]
>>
>>What risks do you see?[/color]
>
> Code that becomes a hell to understand and maintain.[/color]

There's no way to avoid risking that, apart from not programming.

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

> What risks do you see?

1. Code becomes quickly difficult to understand. Or worse: it makes you
think you understand it, when you actually don't.

2. As any other kind of superfluous facility, it's an incentive to use
and abuse it.

3. There can be some nasty "ambiguous overloading" bugs.
I've seen it many times in C++ code. Not all compilers are able to
catch them. It can especially happen with operator overloading.

4. It makes you "overload" functions that you think are functionnally
similar. It may later on turn out that they are not so similar, but
by the time you realize that, hundreds of other functions may depend
on them. A hell to maintain.

5. It's usually some overhead at run-time (although this point may not
qualify as a "risk"). And a huge overhead at compile time, which has
its importance when you work on very big projects (might not want
to wait for hours while your code compiles...)

6. Speaking of overhead, they often imply security issues through the
use of "v-tables". I'm not getting into details here, but many papers
have been written on the subject.

I can't think of anything else right now, but I may miss some other
potential risks. You may not agree with my views...

Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
[color=blue][color=green]
>> What risks do you see?[/color]
>
> 1. Code becomes quickly difficult to understand. Or worse: it makes you
> think you understand it, when you actually don't.[/color]

This depends on what the programmer is used to. The following statement
is just as equally valid: Function overloading makes the code easier to
understand.
[color=blue]
> 2. As any other kind of superfluous facility, it's an incentive to use
> and abuse it.[/color]

Most features in most programming languages are superfluous. If you
were to ban everything for C that is superfluous (so that in the
resulting language, everything can be done in just one way), not much of
C as we know it would remain.
[color=blue]
> 3. There can be some nasty "ambiguous overloading" bugs.
> I've seen it many times in C++ code. Not all compilers are able to
> catch them. It can especially happen with operator overloading.[/color]

I've seen buggy compilers too, but compiler bugs are hardly the fault of
the feature.

<OT>
C++ has complicated, but /well-defined/ overloading resolution rules.
See the C++ standard for details.
</OT>
[color=blue]
> 4. It makes you "overload" functions that you think are functionnally
> similar. It may later on turn out that they are not so similar, but
> by the time you realize that, hundreds of other functions may depend
> on them. A hell to maintain.[/color]

Almost all features can be abused, that's not specific to function
overloading.
[color=blue]
> 5. It's usually some overhead at run-time (although this point may not
> qualify as a "risk"). And a huge overhead at compile time, which has
> its importance when you work on very big projects (might not want
> to wait for hours while your code compiles...)[/color]

Function overloading can trivially be implemented using "name mangling",
which involves no run-time overhead.
[color=blue]
> 6. Speaking of overhead, they often imply security issues through the
> use of "v-tables". I'm not getting into details here, but many papers
> have been written on the subject.[/color]

"V-tables" are not required for function overloading.
[color=blue]
> I can't think of anything else right now, but I may miss some other
> potential risks. You may not agree with my views...[/color]

As is probably obvious by now, I don't. :)

Martin

--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

In <2gffifF29qjuU2@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
[color=blue]
>In article <c7tofr$d6d$1@sunnews.cern.ch>, Dan Pop wrote:[color=green]
>> In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti
>> <horpner@yahoo.com> writes:
>>[color=darkred]
>>>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>>>Guillaume wrote:
>>>>> Overloaded functions are already just syntactic sugar.
>>>>
>>>> I agree, I think they also are syntactic sugar in C++.
>>>>
>>>> I see in them more potential risks than benefits.
>>>
>>>What risks do you see?[/color]
>>
>> Code that becomes a hell to understand and maintain.[/color]
>
>There's no way to avoid risking that, apart from not programming.[/color]

Until now I've been quite successful at avoiding this risk while
programming in C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

In article <c7vj4o$js6$3@sunnews.cern.ch>, Dan Pop wrote:[color=blue]
> In <2gffifF29qjuU2@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
>[color=green]
>>In article <c7tofr$d6d$1@sunnews.cern.ch>, Dan Pop wrote:[color=darkred]
>>> In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti
>>> <horpner@yahoo.com> writes:
>>>
>>>>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>>>>Guillaume wrote:
>>>>>> Overloaded functions are already just syntactic sugar.
>>>>>
>>>>> I agree, I think they also are syntactic sugar in C++.
>>>>>
>>>>> I see in them more potential risks than benefits.
>>>>
>>>>What risks do you see?
>>>
>>> Code that becomes a hell to understand and maintain.[/color]
>>
>>There's no way to avoid risking that, apart from not
>>programming.[/color]
>
> Until now I've been quite successful at avoiding this risk
> while programming in C.[/color]

It depends how you define risk. I would say that, even though
you haven't yet written code that you believe has become a hell
to understand and maintain, you have still risked doing so by
writing programs. If you weren't risking it, there would be no
reason to follow good programming practice.

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

In article <40a2e150$0$306$7a628cd7@news.club-internet.fr>,
Guillaume wrote:[color=blue][color=green]
>> What risks do you see?[/color][/color]
[color=blue]
> 1. Code becomes quickly difficult to understand. Or worse: it
> makes you think you understand it, when you actually don't.
>
> 2. As any other kind of superfluous facility, it's an incentive
> to use and abuse it.
>
> 3. There can be some nasty "ambiguous overloading" bugs. I've
> seen it many times in C++ code. Not all compilers are able to
> catch them. It can especially happen with operator overloading.
>
> 4. It makes you "overload" functions that you think are
> functionnally similar. It may later on turn out that they are
> not so similar, but by the time you realize that, hundreds of
> other functions may depend on them. A hell to maintain.
>
> 5. It's usually some overhead at run-time (although this point
> may not qualify as a "risk"). And a huge overhead at compile
> time, which has its importance when you work on very big
> projects (might not want to wait for hours while your code
> compiles...)
>
> 6. Speaking of overhead, they often imply security issues
> through the use of "v-tables". I'm not getting into details
> here, but many papers have been written on the subject.[/color]

Based on that last point, I think we might have different things
in mind. The function overloading I thought you meant is static,
compile time polymorphism, like that used for C's operators.

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

In <2ghjabF2tts5U1@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
[color=blue]
>In article <c7vj4o$js6$3@sunnews.cern.ch>, Dan Pop wrote:[color=green]
>> In <2gffifF29qjuU2@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
>>[color=darkred]
>>>In article <c7tofr$d6d$1@sunnews.cern.ch>, Dan Pop wrote:
>>>> In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti
>>>> <horpner@yahoo.com> writes:
>>>>
>>>>>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>>>>>Guillaume wrote:
>>>>>>> Overloaded functions are already just syntactic sugar.
>>>>>>
>>>>>> I agree, I think they also are syntactic sugar in C++.
>>>>>>
>>>>>> I see in them more potential risks than benefits.
>>>>>
>>>>>What risks do you see?
>>>>
>>>> Code that becomes a hell to understand and maintain.
>>>
>>>There's no way to avoid risking that, apart from not
>>>programming.[/color]
>>
>> Until now I've been quite successful at avoiding this risk
>> while programming in C.[/color]
>
>It depends how you define risk. I would say that, even though
>you haven't yet written code that you believe has become a hell
>to understand and maintain, you have still risked doing so by
>writing programs. If you weren't risking it, there would be no
>reason to follow good programming practice.[/color]

That's the point: by following good programming practices I avoid the
risk.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

In article <c807hh$m3k$1@sunnews.cern.ch>, Dan Pop wrote:[color=blue]
> In <2ghjabF2tts5U1@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
>[color=green]
>>In article <c7vj4o$js6$3@sunnews.cern.ch>, Dan Pop wrote:[color=darkred]
>>> In <2gffifF29qjuU2@uni-berlin.de> Neil Cerutti <horpner@yahoo.com> writes:
>>>
>>>>In article <c7tofr$d6d$1@sunnews.cern.ch>, Dan Pop wrote:
>>>>> In <2gf68cF214cbU1@uni-berlin.de> Neil Cerutti
>>>>> <horpner@yahoo.com> writes:
>>>>>
>>>>>>In article <40a2332a$0$314$7a628cd7@news.club-internet.fr>,
>>>>>>Guillaume wrote:
>>>>>>>> Overloaded functions are already just syntactic sugar.
>>>>>>>
>>>>>>> I agree, I think they also are syntactic sugar in C++.
>>>>>>>
>>>>>>> I see in them more potential risks than benefits.
>>>>>>
>>>>>>What risks do you see?
>>>>>
>>>>> Code that becomes a hell to understand and maintain.
>>>>
>>>>There's no way to avoid risking that, apart from not
>>>>programming.
>>>
>>> Until now I've been quite successful at avoiding this risk
>>> while programming in C.[/color]
>>
>>It depends how you define risk. I would say that, even though
>>you haven't yet written code that you believe has become a hell
>>to understand and maintain, you have still risked doing so by
>>writing programs. If you weren't risking it, there would be no
>>reason to follow good programming practice.[/color]
>
> That's the point: by following good programming practices I
> avoid the risk.[/color]

I guess that about covers is. ;-)

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

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

Martin Dickopp wrote:
| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|
[snip]
|
| Function overloading can trivially be implemented using "name mangling",
| which involves no run-time overhead.
|

But leads to annoying link-time problems when used with libraries...

[snip]
|
| Martin
|
|

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAo+1S9bR4xmappRARAqz+AJ96zPp8HZlBByG30/LMOehSzy0cdACfRGGV
n01s6jTKPiF6tTGOfhbBuu4=
=/zzp
-----END PGP SIGNATURE-----

Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
[color=blue]
> Martin Dickopp wrote:
> | Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
> |
> | Function overloading can trivially be implemented using "name mangling",
> | which involves no run-time overhead.
>
> But leads to annoying link-time problems when used with libraries...[/color]

Not really. Name mangling is common among C++ implementations, yet no
annoying link-time problems arise with C++ programs.

Martin

--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

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

Martin Dickopp wrote:
| Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
|
|
|>Martin Dickopp wrote:
|>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|>|
|>| Function overloading can trivially be implemented using "name mangling",
|>| which involves no run-time overhead.
|>
|>But leads to annoying link-time problems when used with libraries...
|
|
| Not really. Name mangling is common among C++ implementations, yet no
| annoying link-time problems arise with C++ programs.
|
| Martin
|
|

Fair enough, I'll believe you :-) I don't use C++ personally, but I
heard there were problems sometimes, but it could just have been in a
theoretical sense.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFApAxh9bR4xmappRARAus/AJ44PDXYLKpLynbQW+ibj2vY9nJtEQCgmVNA
87aQ2Tqa0Fsz4hJ33pMisxQ=
=wy5x
-----END PGP SIGNATURE-----

Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
[color=blue]
> Martin Dickopp wrote:
> | Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
> |
> |
> |>Martin Dickopp wrote:
> |>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
> |>|
> |>| Function overloading can trivially be implemented using "name mangling",
> |>| which involves no run-time overhead.
> |>
> |>But leads to annoying link-time problems when used with libraries...
> |
> |
> | Not really. Name mangling is common among C++ implementations, yet no
> | annoying link-time problems arise with C++ programs.
>
> Fair enough, I'll believe you :-) I don't use C++ personally, but I
> heard there were problems sometimes, but it could just have been in a
> theoretical sense.[/color]

To be fair, there /were/ (maybe still are) problems, but they were not
related to the fact that name mangling was used, but that different
compilers used it in different ways. You could therefore not necessary
link together code compiled by two differernt C++ compilers, even on the
same system.

The same problem would arise with two C compilers if they (e.g.) passed
arguments to functions in different ways. So this is nothing specific
to C++ or name mangling.

Martin

--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

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

Martin Dickopp wrote:
| Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
|
|
|>Martin Dickopp wrote:
|>| Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:
|>|
|>|
|>|>Martin Dickopp wrote:
|>|>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|>|>|
|>|>| Function overloading can trivially be implemented using "name
mangling",
|>|>| which involves no run-time overhead.
|>|>
|>|>But leads to annoying link-time problems when used with libraries...
|>|
|>|
|>| Not really. Name mangling is common among C++ implementations, yet no
|>| annoying link-time problems arise with C++ programs.
|>
|>Fair enough, I'll believe you :-) I don't use C++ personally, but I
|>heard there were problems sometimes, but it could just have been in a
|>theoretical sense.
|
|
| To be fair, there /were/ (maybe still are) problems, but they were not
| related to the fact that name mangling was used, but that different
| compilers used it in different ways. You could therefore not necessary
| link together code compiled by two differernt C++ compilers, even on the
| same system.
|

Glad I wasn't imagining the C++ name mangling problem after all.

| The same problem would arise with two C compilers if they (e.g.) passed
| arguments to functions in different ways. So this is nothing specific
| to C++ or name mangling.

Quite true. Under Windows, for example, there are 2 popular calling
conventions, either caller pops the arguments off the stack or the
callee pops the arguments. Of course, you could also imagine args being
passed in registers as an optimisation, or any number of other
platform-specific methods. Indeed, Linux kernel modules compiled with
one version of gcc are not expected to work with a kernel compiled with
another version of gcc.

That said, I would say that C's simplicity make calling convetions much
easier to agree on, and function overloading (with it's associated name
~ mangling) exacerbates to problem.

|
| Martin
|
|

Having thought a bit more, I remember now that the linking problems I
was originally thinking of referred more to classes than overloaded
functions. Again, I'm sure that linking a class is *theoretically* not
much harder than linking standard C functions, but the complexity of the
problem means that there are many more plausible ways of doing it, thus
leading to disparities between different compilers.

However, with something as simple as a C function call, there are very
few obvious ways to do it.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFApWbN9bR4xmappRARAkX+AJ47O9P0uKS8ge/KSXiC8kr6i6k4ugCgrFpM
UPVEVryJJvyXUi+3RAMuPFc=
=CU20
-----END PGP SIGNATURE-----

Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:

|> > What risks do you see?

|> 1. Code becomes quickly difficult to understand. Or worse: it makes
|> you think you understand it, when you actually don't.

You don't need function overloading for that:-).

|> 2. As any other kind of superfluous facility, it's an incentive to
|> use and abuse it.

As you say, it is true for just about any facility. It's a negative
point; to justify any facility, you have to provide offsetting positive
points.

|> 3. There can be some nasty "ambiguous overloading" bugs. I've seen
|> it many times in C++ code. Not all compilers are able to catch them.
|> It can especially happen with operator overloading.

The answer to that is simple: don't use C++'s complex rules for overload
resolution.

|> 4. It makes you "overload" functions that you think are
|> functionnally similar. It may later on turn out that they are not so
|> similar, but by the time you realize that, hundreds of other
|> functions may depend on them. A hell to maintain.

See point 1. You can misname functions just as badly without
overloading.

|> 5. It's usually some overhead at run-time (although this point may
|> not qualify as a "risk"). And a huge overhead at compile time, which
|> has its importance when you work on very big projects (might not
|> want to wait for hours while your code compiles...)

Overloading is fully resolved at compile time. Runtime overhead is 0.

The amount of compile time overhead depends on the complexity of the
overload resolution rules (see point 3) -- although it is never totally
free, it doesn't have to be huge.

|> 6. Speaking of overhead, they often imply security issues through
|> the use of "v-tables". I'm not getting into details here, but many
|> papers have been written on the subject.

I think you're thinking of virtual functions, not overloading.
Overloading doesn't involve v-tables or any runtime mechanism.

In the end, like everything else, it is a tradeoff. Generally speaking,
concerning the positive aspects, I would say:

- It is almost essential to write good mathematical software (and some
business software). But for that, you need not only function
overloading, but full user defined types, with operator overloading
as well. What good is being able to write sin(aBigDecimal) if I have
to write bigDecimal1.add( bigDecimal2 ), rather than bigDecimal1 +
bigDecimal2?

- It can be very useful in certain cases of generic programming: C++
templates or perhaps some fancy macro generated code in C.

Offsetting those advantages is that the overloading rules almost have to
be complicated in C/C++, given the number of implicit conversions the
languages support. And it isn't so much overloading itself that costs,
it is the complexity of the overload resolution rules, which means that
1) the compiler has a lot of work to do, and 2) even more important, it
becomes a real guessing game for whoever reads to program to know what
function actually is going to be called.

I work mostly in C++, where I have overloaded functions. From
experience, I really only use them in the following cases:

- constructors -- C++ requires all constructors for a given class to
have the same name, so you don't have much choice,

- smart pointers -- this is a very C++ specific technic for resource
management, and totally irrelevant in C, and

- my BigDecimal class, which implements full the decimal arithmetic I
need for some commercial applications.

IMHO, only the last is in the least way relevant to C, and I'm not sure
that just simple function overloading is the best answer (in C).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Martin Dickopp <expires-2004-06-30@zero-based.org> writes:

|> Ross Kendall Axe <ross.axe@blueyonder.co.uk> writes:

|> > Martin Dickopp wrote:
|> > | Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:

|> > | Function overloading can trivially be implemented using "name
|> > | mangling", which involves no run-time overhead.

|> > But leads to annoying link-time problems when used with
|> > libraries...

|> Not really. Name mangling is common among C++ implementations, yet
|> no annoying link-time problems arise with C++ programs.

That's not really true. If I compile a function in C with gcc, I can
link it with an application compiled with Sun cc; if I compile a
function in C++ with g++, I cannot link it with an application compiled
with Sun CC. The linker complains.

In fact, there are many reasons for this, and the compilers use
different mangling schemes intentionally, so that I get the error at
link time, rather than some strange run-time error. There would be no
reason for C compilers to use different manglings. But they probably
would; gcc would use a mangling compatible with g++, and Sun cc a
mangling compatible with Sun CC.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

re: Function Overloading

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about